The Essential Guide to Requirements Management and Traceability
11 Requirements Gathering Techniques for Agile Product Teams
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
#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.
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.
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 Requirement Gathering 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.
In This Webinar, We Discuss Requirements Engineering as a Path to Project Success
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!