Requirements Gathering Techniques

It would be nice if requirements gathering was as simple as asking your customers and stakeholders what they want your system to do. Unfortunately, it’s never that straightforward.

In most cases, stakeholders are not aware of all the alternatives that exist when it comes to developing a specific product. Immersed in the current status quo, their vision tends to be limited. It’s hard for users to detach from the way they’re currently doing things—to imagine possibilities that are a significant departure from what they have now.

Furthermore, there’s no silver bullet. No single requirement gathering technique will help you elicit a complete set of requirements that will fill every gap and stand up to scrutiny during validation.

That’s why it’s a good idea to take a multi-faceted approach to requirements gathering. Requirements engineering best practices recommend using a variety of methods aimed at different phases of the process.

This article looks at eleven effective requirements gathering techniques. They will be presented roughly in the order in which they normally appear in the requirements gathering process. It is not necessary to use all of them for every project, but a healthy mix of these techniques, chosen based on the needs of your specific project, will likely improve your requirements coverage and help you reduce requirements-related problems during software development and afterward.

Interviews
Questionnaires or Surveys
User Observation
Document Analysis
Interface analysis
Workshops
Brainstorming
Role-play
Use Cases and Scenarios
Focus Groups
Prototyping

Requirements Gathering Technique #1: Interviews

Interviews are a great way to start the requirements elicitation process. They are invaluable for gathering background information on business needs, customers’ and users’ problems, and the concerns of support staff and other relevant stakeholders. Interviews can also be used in follow-up to gather more detailed information.

Interviews should cover a diverse and representative cross-section of the system’s stakeholders. You will want to include the full range of customer and user profiles. This is necessary to gain a proper perspective on competing needs, so your system requirements aren’t slanted in favor of one group.

When you conduct interviews, it is important to ask open-ended questions. Open-ended questions are those that cannot be answered with a simple “yes” or “no.” They draw out specific information. They require the interviewee to explain their thoughts and provide reasons, which in turn provides context for evaluating and validating the requirements.

You’ll also want to ask a lot of follow-up questions during the interview. Good follow-up questions either drill down for more detail or pull up to get an overview of the context. Some people will tend to talk specifics and exceptions. With them, you’ll need to pull up. Others will talk about context without ever getting into specifics. With those folks, you’ll need to drill down.

Requirements Gathering Technique #2: Questionnaires or Surveys

Individual interviews present several challenges. They can be tricky to schedule and time-consuming for the interviewers. Plus, the requirements you gather may only scratch the surface; not every interviewer is skilled at asking follow-up questions in real time.

Questionnaires (or surveys) can provide an efficient alternative. They allow follow-up with multiple stakeholders at the same time.

A well-thought-out questionnaire—one that asks probing questions—is a good tool for getting at those underlying requirements of which stakeholders may not be fully conscious, but which are essential to a successful design.

Technique #3: User Observation

One of the best ways to understand what users truly need is to observe them performing their daily tasks.

User observation can be either passive or active. Active observation—asking questions of users while observing them—is the best approach for gaining an understanding of an existing process. Passive observation is more effective when gathering user feedback on a design prototype (see technique #11).

When observing users, record the actions and activities that take place. What already works well? What causes users difficulty? Note the obstacles users must routinely overcome.

By observing end users in the real context in which they perform their tasks, you’ll gain a true understanding of what they are up against and what improvements they need so they can perform better. You’ll then be better able to specify a system that successfully reinvents users’ processes and grants them far greater productivity and usability, rather than simply providing them an incremental improvement.

Technique #4: Document Analysis

Frequently overlooked, document analysis is another highly effective technique for gathering requirements.

Reviewing the documentation of the current system you’re seeking to replace can help you in performing AS-IS process analysis and gap analysis. The former helps you see where you can improve the user’s process. The latter will aid you in determining where the business needs revealed earlier—through your interviews, questionnaires, and user observation—are not being met.

Naturally, you’ll want to analyze the system’s requirements documents, if available, but you should also look at other system-level documentation, such as users’ manuals and problem reports.

Nuggets of information on why the existing system works as it does are often buried within the specifications and design documentation. The insights gained from document analysis can help you formulate further questions and evaluate the completeness of your requirement set.

Requirements Gathering Technique #5: Interface Analysis

Analyzing a system’s interfaces, both human and machine, is vitally important to ensure requirements are complete and the system will be usable.

Interfaces for a software product will include those with:

End users
System components the software interacts with (e.g., sensors or other peripherals)
External systems the software interacts with

Thorough interface analysis—really understanding the interactive context of the system— will frequently uncover requirements not readily visible to users.

Technique #6: Brainstorming

Brainstorming can be performed as part of a workshop (see technique #7, which follows) or on its own, in either large or small groups.

In your brainstorming session, consider different parts of the system individually. Explore various what-if scenarios and blue-sky ideas. The general idea is to break away from existing conventions. Consider visionary ideas for pushing current boundaries.

Useful tools for brainstorming sessions include whiteboards, mind mapping software, and empathy maps (the latter for exploring user needs).

Technique #7: Workshops

When gathering requirements from a broad spectrum of stakeholders, it’s only natural that you’ll get conflicting opinions. You will need to resolve these issues, however, before implementation begins.

Requirements workshops are a good method for resolving such conflicts.

Once you have a broad set of candidate requirements defined and organized, convene your stakeholders and hash through these candidates together. Gather additional detail. Give a fair hearing to opposing views. Grant everyone ample opportunity to provide the rationale for their positions.

Seek to resolve discrepancies and conflicts, gain consensus, and validate your requirements. These activities are vital to ensuring your system will best meet the needs of all users and stakeholders, not just the most vocal groups.

Technique #8: Role-play

Some systems—certain kinds of enterprise software, like ERP, for example—must meet the needs of a variety of user types. Role-play can help to ensure that the needs of all users are being met.

In a role-play session, different people take the roles of the different user types. Having the various roles interact with one another helps examine individual system requirements from different perspectives and generates discussions and new ideas.

In effect, role-play is an additional brainstorming technique. It is a good way to gain a solid understanding of how the various parts of the system need to function to support the overall process.

Requirements Gathering Technique #9: Use Cases and Scenarios

Once you have high-level functional requirements in place, it is a good idea to explore a variety of use cases and scenarios.

Use cases are the specific, individual business objectives the system must accomplish and the various situations in which a given feature or functionality will be used. They describe the various external entities that act on the system and the specific interactions they have with the system to accomplish the business objective. Use cases are expressed as step-by-step lists of tasks performed during a process.

Scenarios, also called user stories, are similar to use cases in that they describe how the system will carry out a process to fulfill a business objective. Their form, however, is a narrative, rather than an enumerated list. They are essentially short stories with the user in the role of the protagonist. Scenarios describe:

Tasks users perform
Information users see
How users interact with the system

Use cases and scenarios can be used to validate the features and functional requirements of the system across a wide range of situations. They can also help you discover exceptions and boundary cases that need consideration.

Requirements Gathering Technique #10: Focus Groups

A focus group (or user group) is a gathering of customers or user representatives who meet with you to

Provide feedback on your product
Express their needs
Help guide your software development

Focus groups can be convened to either:

Gather information for the development of requirements, or
Gain feedback aimed at validated previously elicited requirements

Focus groups are different from brainstorming. Brainstorming is a managed process that generally involves internal stakeholders. Focus groups typically involve external stakeholders.

Many systems engineers and business analysts are skeptical of using focus groups to gather requirements. Meetings can be dominated by vocal individuals with narrow agendas. Strong disagreements on needs and features can make these meetings unproductive. Focus groups can, however, be extremely useful in certain situations. One of these is the evaluation of design prototypes (see technique #11) to help validate and finalize requirements.

Requirements Gathering Technique #11: Prototyping

There’s an old joke among systems engineers that the discussion with a user group following a design presentation often goes something like this…

System engineer: “So, what do you think?”

User group: “We hate it.”

System engineer: “Ah… okay, well… what is it you want, then?”

User group: “Well… we don’t know… BUT IT AIN’T THAT!”

Often, end users and other stakeholders don’t have a clear idea of what they truly want. In most cases, they don’t have a good grasp of what’s possible. If you can give them something to try, however, they can usually tell you what they like and don’t like about it.

That’s where prototyping comes in.

Prototyping gives users a chance to try out ideas on what their next solution could look like. Today’s rapid prototyping tools allow developers to quickly put together any number of interactive mock-ups for users to try.

Once the initial mock-up is built, the process is an iterative one:

Trial of the prototype by users
Feedback from users
Modification of the prototype

Modern prototyping tools make it easy for developers to modify the prototype on the fly, so users can help you quickly discover what will satisfy them. From that working model, it’s then a relatively simple matter to reverse engineer the requirements that describe the accepted functionality.

Automating the Requirements Gathering Techniques Process

As you gather and develop requirements, it is beneficial to have a flexible, user-friendly system for collecting them, organizing them, and making them available to relevant stakeholders. This is especially true in agile development where documents and spreadsheets can prove especially cumbersome.

To see how Jama Connect can streamline requirements gathering and management for Agile teams, click here.

Author
Recent Posts

Jama Software

11 Requirements Gathering Techniques for Agile Product Teams