setting up the requirements gathering sessions - ITIL Configuration Management

Requirements management generally falls into two areas: what you do before you have requirements, and what you do after you have them.

Without a doubt one of the crucial parts of a Business Intelligence (BI) project is the requirements gathering session. Now at this point, I make the assumption that the client/customer has been through the product demos by the sales guys, the buzz is in the air, the necessary budget approvals have been set, and the department’s analysts are ready to rock and roll. Now it is time to figure out what everyone needs to get out of the tool selected for the job.

Next is setting up the requirements gathering sessions (RGS’s) which grabs all business sponsors of the project and the end users of the ultimate project into a same room for n days while the specifications of the BI implementation are hashed out.But as the Professional Services (Consultancy, etc.) team on the project walking into these sessions without a game plan would be a big no-no. I’ll discuss a few common techniques used in these sessions.One of the buzz words around RGS’s is the use of questionnaires which intend to sum-up and grasp the inner workings of the end-users needs in 20 questions or less. Another is the retrieval and presentation of existing business reports, which basically assumes something like taking a mainframe report as a starting template to create the same report in the new BI system.There are many more techniques and I’ll look deeper into them shortly.

Ultimately a successful requirements gathering session boils down to asking the right questions, knowing the capabilities and limitations of the BI system set to be implemented, and documenting the specifications that arise from the RGS.

From Brainstorming to Prototyping

So an RGS is really a brainstorming session with a focus on immediacy and factual accounts of reporting needs and experiences, right?So how do you get from an RGS to Prototyping?The answer to the latter questions is that it depends on how much bureaucracy exists within the client or customer’s department.Some organizations area ripping and ready to go right away.Other groups are driven by intense process development and granular specification documentation.As a side note, one should try to ascertain which approach the project will fall under. This will allow your group doing the effort to be better prepared on how much documentation you will need to prepare and develop and it also allows you to understand which approach to take regarding setting up the RGS’s documentation and so on.

Another aspect that I look at when discussing Prototyping is to relieve any ambiguity regarding what “Prototyping” means to the project. With my engineering background, I always look at prototyping in the BI world as a Proof-of-Concept (POC) that is a rough design that understandably has many more iterations and refinement before it is ready for prime-time.A POC to me means that a sandbox or development environment will be stood-up and the project based there as a quick approach to letting a focus group of users begin looking at some test data.And to me a POC has a different timeline structuring, no backup and recovery strategy, etc.

From Brainstorming to Prototyping

Requirements are distilled from stakeholder dreams.

The Need for Requirements

The need for good requirements should be obvious. It is necessary to have clear and crisp requirements about what the CMDB should do. If there are no good requirements it may lead to chaos between the implementation team and testing team .And validation of the final product also become a long process.

Without good requirements, the project manager will have to make up tasks in the project plan. A good plan should be based on meeting stated requirements, and fulfillment of each requirement should be documented as a deliverable in the plan.Good requirements will serve as a project measuring stick throughout all the stages.They serve as a boundary between what gets into the first release and what can wait until later releases.

Where to Look

So where do you go to get good requirements?

  • Talk to the stakeholders, schedule meetings to discuss regarding the requirements .
  • Look at the documents in addition to learn about the requirements.
  • Description of related processes is also a good source of requirements.
  • If you have been handed any project description or scope documentation for the configuration management project, those would be excellent sources of requirements.

The key thing to remember is that when looking for requirements, it is impossible to cast your net too broadly. Every corner you fail to examine has the potential to unleash a project crippling surprise later. Every person you fail to ask will come in at the eleventh hour with a completely new thought that needs to be implemented. Remember that the filters defined in Figure and explained earlier will help center these discussions and provide actual requirements.Skipping directly to the easy requirements without considering some of the less obvious sources will leave you with an incomplete picture of the project.

Techniques for Eliciting Requirements

The word "gather" does not truly communicate the nature of the Business Analyst's (BA) job.You do not gather requirements-they are not just lying around on the ground waiting to be picked up.

The word "elicit" more closely matches the job, because it connotes a more active role for both the BA and for those with whom the BA works. The dictionary defines elicit as:

  • To draw forth or bring out (something latent or potential)
  • To call forth or draw out (as information or a response)

There are many ways to elicit requirements from your stakeholders. A BA should be proficient in all of these: interviews, workshops, focus groups, brainstorming, observation, and surveys/questionnaires. While all of these methods involve three basic parts: preparation,conducting,and follow-up, they do have differences.


Interviews, either with an individual or with a group of people, offer the opportunity for rich, detailed communication.


Define interview goal: Determine exactly why you are holding the interview and what you want to achieve in it.

Select participants: Decide who needs to be involved in the interview in order to achieve that goal.

Determine logistics: When and where will the interview be held, and how will the interviewees be invited?

Design the interview: Decide on the format that is most appropriate for the interviewees and the goal. Should it be structured with a detailed agenda and formal set of questions, or unstructured with a looser agenda, depending more on ad hoc interaction? Should the questions be open-ended requiring sentences or paragraphs to answer, or closed-ended requiring short, even one-word answers?


Take time at the beginning to ensure that the interviewee(s) knows the purpose of the interview, who you are, and what your role is.Wrap up the interview with questions like "Is there anything else you would like to add?" and a hearty "Thank you!"

FOLLOW UP:Like any other meeting, interview minutes should be published.This allows the interviewees to see what you learned in the interview and validate that what you heard is what they intended to say.


A workshop is a structured method for interacting with a group of people.Workshops can generate much information quickly if well facilitated and if participants are active.


Define purpose: Determine exactly why you are holding the workshop and what you want to achieve in it.

Select participants: Decide who needs to participate in the workshop in order to achieve that purpose.Make sure to consider the personality types involved and ensure that you'll get participation from the entire group, not just a few dominant people.

Determine logistics: When and where will the workshop be held, and how will the participants be invited?

Conduct preliminary interviews: Some workshop methods include collecting some information from the participants before the workshop to provide a starting point. Such methods provide specific guidance about what preliminary information should be collected.


Be sure to accurately capture all of the information that the workshop produces. Depending on the size of the group, you may want to assign a record-keeper so you can focus on facilitation

FOLLOW UP:Some types of workshops result in the assignment of action items to the facilitator or participants, in which case, they must be managed to closure.The workshop results should be published so the participants and other interested parties can see what you learned in the workshop.


A focus group is an interactive session with a carefully selected group of people designed to capitalize on the synergy of a group.


Select participants: Decide who needs to participate in the focus group in order to achieve its purpose.

Define roles, topics, and logistics: Define who (among the people running the focus group) must do what, and the specific topics that the participants will discuss. Also define the basic logistics such as when and where the focus group will be held, and how the participants will be invited.


Carefully facilitate the group to ensure free and open interaction among the participants.Participants must feel free to interact openly or the focus group could fail.

FOLLOW UP:The focus group report records what was learned, including both agreements and disagreements among the participants.


Brainstorming is a method of quickly generating many creative ideas from a group of people.


Define topics and time limits: Define precisely what will be the focus of the brainstorming session, and how long it will be allowed to go on.

Select participants: Decide who needs to participate in the brainstorming session in order to achieve its purpose.

Determine evaluation criteria: Decide how the ideas that come out of the brainstorming session will be judged afterward. Be sure that the evaluation does not go on during the brainstorming session.


Encourage a free flow of ideas. This requires careful facilitation to ensure that participants feel comfortable with adding any idea to the list, and that no criticism or even discussion of the ideas goes on during the brainstorming session.

FOLLOW UP:Apply the evaluation criteria to the ideas that were generated to reduce the list to only those ideas that are reasonable or viable.


Observation is watching people as they go about their jobs.Observation can be an effective way to gain a realistic and detailed understanding of how work is done in the production environment; however, it is time consuming and may disrupt work.


Define goals and individuals to be observed: Decide what you are trying to accomplish in the observation and who you should observe in order to achieve those goals

Decide on mode: Observation may be done in either of two ways:

Passive/invisible: Observing in a way that does not disturb the workers. "Invisible" refers to the fact that the workers are not even aware that observation is taking place.

Active/visible: Interacting with those who are being observed. For example, asking questions and having them describe what they are doing and why.


If people believe that they are being evaluated, they are likely to do the work "by the book," instead of the way they normally do it. So those who are being observed must be assured that the observation is not for the purpose of judging them. As the observation goes on, keep detailed records of what is observed and questions that must be answered later.

FOLLOW UP:After obtaining answers to any remaining questions, publish the results of the observation.


Surveys allow you to collect information from many people in a relatively short period. A survey can be an effective way to collect quantitative information; however, writing the questions requires great skill and care to avoid ambiguity that could compromise the utility of the results.


Define purpose, target people, and logistics: Decide what you are trying to learn from the survey, who you should target in order to achieve those goals,and how the survey should be distributed (for example, paper, e-mail, internet, telephone).

Choose survey type:

Open-ended questions vs. closed-ended questions: Open-ended surveys are more difficult to analyze, yet closed-ended surveys limit the responders' options.

Anonymous vs. signed vs. optional: People may be more forthcoming if they do not have to provide their names, but anonymity does not allow for any follow-up questioning.

With vs. without pre-survey or post-survey interviews: Pre-survey and post-survey interviews increase the valuable data that you can get from the survey, but add significant effort.

Define target response level and follow-up activities: Getting many people to respond to a survey is difficult. If you are expecting more than a small minority of the target people to respond, it will require follow-up work beyond merely distributing the survey.

Write questions: This step is more challenging than it sounds.Writing questions that cannot be misinterpreted (resulting in misleading results) requires great skill and concentrated effort.

Test the survey: Because it is so difficult to write questions well, it is advisable to test the survey to see if people misinterpret any of the questions, and to see if it provides the information that is sought.


Get the survey into the target people's hands, and encourage them to respond. If follow-up activities are planned to increase the response rates, do them.

FOLLOW UP:After the response period has ended, analyze the data, and summarize and report it to the appropriate people.

How to Document Requirements

To support their communication and understanding, requirements must be documented. This has usually meant that they are written down. Because that prose was always too ambiguous for easy understanding, many different structured formats and diagrams have been used over the decades in attempt to capture the elusive system requirement. Much energy has been spent over those years by gurus and vendors trying to prove that their approach was the best way to document requirements. In fact, "religious" arguments have often erupted between competing camps as to why "my way" is better than "your way."

This history, combined with the above definition of system requirements, supports my thinking that no one format or diagram is sufficient to represent all requirements. Since systems are asked to do a variety of things, how requirements are documented needs to vary as well.

Using multiple formats (or deliverables) to support different types of requirements can lead to overlap and potential redundancy, so it is vital that the multiple deliverables be integrated in such a way that as a whole they present one overall view of the requirements.

Levels and Categories

Functional requirements (often also referred to as Conceptual Requirements) address the needs of a user that interacts with the business environment (business, department etc and their systems.). System requirements address the needs of a user that interacts with the computer systems, ONLY. In one instance the business is the boundary and another instance the system is the boundary. Therefore an oversimplified equation is Functional Requirement = Workflow + System Requirements. What is key to this definition is the boundary.

To illustrate: let’s say you want to join a library. As a prospective member you interact with the library where the boundary includes all systems, books, librarians etc. However, after you’ve filled in and submitted your application forms, the librarian enters your details into the computer system. Back to our little equation: Functional Requirement (Member must be able to join library) = Workflow (member fills in form) + Systems requirement (Librarian enters details from form into computer/our system must be able to maintain member details).

Let’s say you work in the account receivable department (which is one boundary) and you have a debtor system (which is the other boundary). Therefore paying an invoice becomes: Functional Requirement (Clerk must be able to record invoice payments) = Workflow (clerk prepares remittance advice and cheques) + System Requirements (Clerk enters remittance information/our system must be able to accept invoice payment).

The reason why you get different answers from different people is, the boundaries are unclear. For those of us who work with use-cases, the difference is obvious, because the square box we draw illustrates the boundary. Sometimes the square box represents the business, sometimes the department, and sometimes the systems. For the use case aficionados, it’s a box within a box within a box. This has smacks of the old Venn diagrams that we did at school. It’s a circle within a circle within a circle.

For those of us familiar with DFDs. We would draw bubbles for the workflow and the entry of details (as in the library case above). At some point we would draw an automation boundary around those areas we deem as system requirements.

Boundaries are important things. One of the questions to ask your colleagues and your supervisor, is, “please define the boundary for each of the columns on the traceability matrix”

In documenting system requirements, you might decide that one or more pieces of the overall architecture need to be defined at a still lower level of detail. This can lead to the third level of requirements, often called component requirements. Not every project will have component requirements, and even when you choose to use component requirements, not every component will require them. Component requirements are most often useful for components that must interface with people or tools outside of your configuration management team. User interfaces and external tool integration points are examples of situations that frequently require component level requirements.

Documentation Techniques

There are a couple of special purpose requirements documentation techniques that deserve special attention.


Prototypes are Mockups of an application, allowing users to visualize an application that has not yet been constructed. Prototypes help people get an idea of what the system will look like, and make it easier for projects to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.

Prototypes can be flat diagrams (often referred to as wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a grey scale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion as to whether the prototype represents the final visual look and feel of the application.

Use cases

A use case is a structure for documenting the functional requirements for a system, usually involving software, whether that is new or being changed. Each use case provides a set ofscenariosthat convey how the system should interact with a human user or another system, to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end-user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of the ways in which users are intended to work with the software or system. Use cases should not describe internal workings of the system, nor should they explain how that system will be implemented. Instead, they show the steps needed to perform a task.

When to Stop Gathering Requirements

The simplest answer is that when you’ve asked everyone you can think of and none of them have new ideas, you’re finished getting requirements. But we all know that someone who ran out of ideas yesterday might think of something new tomorrow. Requirements can’t be a boundless process. If the requirements gathering phase lasts too long, your stakeholders will get the impression that your project will take too long to return significant value, and may even decide that there are higher priorities than endless requirements gathering. On the other hand, if you cut off the requirements gathering too soon, you run the risk of significant stakeholders feeling their voice wasn’t heard and thus withholding support from the project. A delicate balance is clearly required.

The best practice is to gather the requirements by level, and let each level mature appropriately. Make sure to include reporting, administration of tools, data sources, procedures, organizational roles, and everything else mentioned in this book to cover the entire waterfront. When you’re convinced that you’ve achieved the full breadth of coverage and have all the business requirements documented, go through a few reviews. First, review with the project team and see whether any new ideas emerge. Then review with your project sponsors—the people who are funding your project and making key decisions about whether to go on. Finally, review with the widest possible list of interested and affected stakeholders. At each stage of the review, look for new requirements.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

ITIL Configuration Management Topics