Requirements Gathering

What is Requirements Gathering?

Requirements Gathering is the collection and analysis of those specific functions and features that must be present in a technology solution to meet the stated business needs. These requirements are the basis for evaluating potential solutions as well as for the design/development/configuration of the chosen option.

Tip  Elicit requirements before scheduling product/system demos. Software vendors are trained to show lots of bells and whistles that can distract users from the important/required functionality.

Requirements Gathering StepsMeetingImage

  1. Identify Stakeholders and Subject Matter Experts (these are the people who you'll need to elicit requirements from).
  2. Facilitate Requirements Gathering 
  3. Document Requirements
  4. Circulate Requirements for Review and Feedback
  5. Make Updates and Seek Sponsor and Stakeholder Sign-off

Requirements Gathering Methods  

The BABOK (Business Analyst Body of Knowledge) lists nine methods for gathering requirements.

  1. Brainstorming - Brainstorming with a group of Stakeholders and Subject Matter Experts can be a good starting point for generating ideas on what the solution needs to look/act like.  After all the ideas are generated, the participants prioritize the ones they think are the best for this solution. The resulting consensus of best ideas is used for the initial requirements.
  2. Document Analysis - Review any relevant existing documentation (i.e. users guides of existing systems, other system related documentation, industry information, compliance etc.) to identify requirements. 
  3. Focus Group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs / opportunities / problems to identify requirements, or can be gathered to validate and refine requirements that you have gathered up to this point.  This is different from brainstorming in that it is a managed process with specific participants.
  4. Interface Analysis - Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. Interface analysis involves reviewing the touch points with other external systems.
  5. Interview - Interviewing Stakeholders, current system users and subject matter experts is probably the most common approach to gathering requirements. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs.  Interviewing management separate from other stakeholders often leads to a more open exchange of information.
  6. Observation - The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked.
  7. Prototyping - Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people cannot articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.
  8. Requirements Workshop - Also known as a joint application design (JAD) session, workshops can be very effective for gathering requirements. More structured than a brainstorming session, involved parties collaborate to document requirements. One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two analysts than with one, where a facilitator and a scribe work together. 
  9. Survey/Questionnaire - When collecting information from many people – too many to interview with budget and time constraints – a survey or questionnaire can be used. The survey can force users to select from choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can create a survey on your own, and get meaningful insight from the results. You should expect, from a well-designed survey, qualitative guidance for characterizing the market. It should not be used for prioritization of features or requirements.
     

Tools & Techniques for Eliciting Requirements

Using pictures and diagrams is a great way to elicit and document user requirements during your interviews and workshops.  Approximately 65% of US residents are visual learners so using pictures and diagrams works well for their creative process.  In addition, drawing allows you to capture the big picture ideas more quickly, making your limited time with users more productive.  You'll have time at your desk to flush those drawings out into written requirements later.

     Useful Diagrams
Interaction Context Diagram
Activity Diagram
Entity Relationship Diagram
State Transition Diagram

  
Interaction Context Diagrams

An interaction Context Diagram is a graphical representation depicting the interactions that occur between actors (end users and other systems) and the target system. 

Types of interactions Include
  1. End User to Target System: An interaction between an actor (end user) and the target system that is initiated by the actor. Example: A customer service agent enters a new transaction into the customer relationship management system (CRMS).
  2. Target System to End User: An interaction between an actor and the target system that is initiated by the target system. Example: CRMS notifies quality control manager of quality issue for product group. 
  3. Target System to Other System: An interaction between the target system and another system initiated by the target system. Example: CRMS adds a new email address to Listrack (Campaign Management System).
  4. Other System to Target System: An interaction between the target system and another system that is initiated by the other system. Example: Mail Order System enters Order transaction.
  5. Target System to Target System (i.e., itself):  An interaction between target system and itself. Example: CRMS merges duplicate records
    Interaction Context Diagram Example

TipDon't be afraid to ask a lot of questions when gathering requirements!

Use diagrams to elicit greater detail by asking qualifying questions when you’re interviewing subject matter experts (SME). For example, using the above diagram example, you could ask questions like:

• What are specifically do you mean by transactions, are there different types?
• What specifically do you mean by “quality issue”?
• What is a product type?  Maybe the manager considers each flavor of ice cream a product type or maybe it is ice cream vs. frozen yogurt.
• What is an order transaction?  Is it a copy of an order confirmation e-mail or just details of the order?
• How often does the system check for and merge duplicates, once a day, each time a new contact is being entered, etc.?
• What constitutes a duplicate?

Activity Diagram

An activity diagram is a business process flow for each activity that you identified when building your interaction context diagram.

Activity Diagram Example

 

Questions that may arise from doing the activity diagram are things like:
• What are required fields?
• What specific information is on a new contact form (see the annotation First Name, Last Name, etc.)?
• You may have questions about the level of detail they want to see, Name vs. First Name and Last Name, Cell Phone vs. Phone, etc.

Entity Relationship Diagram (ERD)

An ERD is a graphical depiction that defines the information that the business needs to know in order to operate and how those different pieces of information interact with each other. 

Relationship Cardinality expresses how many times a row in table A is associated to table B.  For example: A grant request must have one and only one program associate but the program could have zero to many request associated to it. Depending on the program you use to document the relationship the symbols used may be slightly different. 
                                                              

State Transition Diagram

The State Transition Diagram shows the different statuses that an entity (identified in the ERD) can be in.

Djiagram depicting the different states that and entity can go through

 

Documenting Requirements

Now that you have completed your analysis workshops, and interviews, it is time to document those requirements more formally. One useful way to document functional requirements is to create Use Cases for each. Non-functional requirements, or requirements of quality, system behavior, accessibility, etc., are often documented separately, as they apply to the system as a whole not a particular action. Non-Functional requirements also need to be documented, as they are equally as important as functional requirements, to the overall success of a project. For example: "The system must be accessible via the web", "The system must be able to support 5000 concurrent users" etc., are examples of non-functional requirements for a grants management application. If these requirements failed to be documented, you risk implementing a desktop application which does not meet your extensive list of requirements and the project would potentially fail. 
 

Tip  When looking to develop requirements for Commercial Off The Shelf (COTS) solutions you may find that not all of these tools are necessary. For instance, you may not use State Transition Diagram or Activity diagram as you are less concerned with the specific steps a user would take as long as the solution is user friendly.  You’re really trying to identify those things the software must be able to perform, and the types of data that must be captured.