best practices requirements Archives

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.

There are many theories on how to write better requirements. Some suggest using or excluding certain words or limiting each requirement to one sentence.

However, there’s a danger in having too many rules around your requirement writing process because it can end up hamstringing your work. Writing excellent requirements, in my opinion, is both an art and a science. Instead of getting bogged down by strict rules, consider the Golden Rule of Requirements: Communicate clearly and effectively to your stakeholders.

In this case, your stakeholders may be testers, designers, developers, business analysts, customers, and more. In any case, the most important goal is to properly communicate the requirement— the need— to these stakeholders. Stay away from introducing the “how,” as that should be reserved for the product design.

Of course, clearly communicating requirements is not as easy as it sounds. Luckily, we have some recommendations that can drive quality and consistency when authoring your requirements.

Remember, don’t follow these like strict rules for rule’s sake. They are just meant to help you fulfill the key objective: communicate clearly and effectively to your stakeholders. Plus, you’re likely to come up with your own recommendations specific to your company or industry when aiming for this Golden Rule of Requirements.

Use A Template
When you’re authoring new requirements from a blank canvas, start with a sort of free-form writing method. After all, everyone writes and thinks in different ways. When readying requirements to review with your stakeholders, using convoluted vocabulary and inconsistent sentence construction may muddy your requirements.

That’s why creating templates for writing requirements can be a great way to maintain both consistency and quality. Even if you start authoring in free form, you can normalize your requirements into a templated version once you’re ready to share them with others.

Examples:

In terms of a requirements template, teams can choose what works best for them, but the overall goal is to keep the construction uniform. For instance, if a team is writing requirements in the form of user stories, it may be more meaningful to refer to the affected user by an actual name rather than simply “user.” However they’re utilized, templates help maintain quality control and coherence in requirements.

Avoid Adverbs
In casual conversation, words like “significantly,” “quickly,” and “powerfully” can be a great way to emphasize a point. However, in terms of requirements, these types of words make it difficult to test a qualifier. For example, instead of saying something needs to work “quickly,” it’s better to get more granular and quantitative. Maybe you want it to perform an average of five seconds better per customer statement, which would be a 15% improvement on the current average. Giving more direct, specific goals to the team will help them understand exactly the target they’re working towards.

Review and Discuss the Requirements
Lastly, one of the best strategies to ensure you’re communicating requirements clearly is simply by reviewing them with stakeholders. You’ll get feedback which helps improve the requirements and increase shared understanding within your team.

Beyond that, though, reviewing and talking about the requirements will also assist with defining the criteria for acceptance and ensuring they’re testable. Plus, you’ll reduce the number of surprises and missed requirements in the product management cycle.

Figuring out how to facilitate this process can be the real challenge. Live, in-person group meetings aren’t always the most effective method for utilizing resources and ensuring individual clarity. On the other hand, a series of one-on-one meetings can be time-consuming and tough to wrangle with busy schedules. That’s why you want to think about a platform like Jama Software where you can provide comments on the requirements and have formal reviews on the collections of requirements.

Jama isn’t meant to replace face-to-face collaboration, but it can make it much more efficient. For instance, forget organizing an expensive, all-day meeting with multiple engineers to go through each requirement. Instead, start a Jama review a few days prior to give engineers time to digest and provide feedback on their own schedule. Then, any face-to-face meetings can be shorter and concentrate on the smaller set of requirements that need more clarity and conversation. This can eliminate hours spent in meetings and ensure the team stays aligned throughout the process. Whatever your preference is for completing reviews, the important thing is to make sure they get done.

There are many ways to follow the Golden Rule of Requirements and these recommendations are just a few that’ll make a positive impact on your requirements. Let us know what other tips and recommendations you have for communicating requirements clearly and effectively with your stakeholders!

Learn more about writing better requirements by watching our webinar, “Best Practices for Writing Requirements.”

RELATED: Download this information-packed ebook, Best Practices Guide for Writing Requirements

To learn more on the topic of requirements management, we’ve compiled a handy list of additional valuable resources for you!

SEE MORE RESOURCES

Tag Archive for: best practices requirements