requirements gathering techniques Archives

Tag Archive for: requirements gathering techniques

Requirements Management Plan

Product success depends upon the successful project management of the product’s requirements. Effective requirements management, in turn, requires thoughtful planning.

A requirements management plan describes how you will gather, analyze, document and manage the requirements of the project. It should describe how you intend to gather the high-level project and product requirements from project stakeholders, industry standards and governmental regulations, as well as the more detailed product requirements you will collect and develop over the project lifecycle. Your requirements management plan should also specify how you will manage changes to requirements after they have been approved.

Your requirements management plan is a tool for communication. It provides all your project’s stakeholders with a common understanding of how the product’s requirements will be managed to ensure success.

In this article, we’ll describe the requirements management planning and the recommended components of a requirements management plan.

What is Requirements Management Planning

Requirements Management Planning is the process of documenting how you will gather, analyze, document and manage the requirements of a project, manage changes to requirements once they have been approved, manage the configuration of the requirements documentation, and track verification of the project’s requirements.

Components of a requirements management plan

A solid requirements management plan will be composed of several components. Here, we’ll describe our recommended sections. Depending upon your industry and organization, not all of these sections may be applicable to your situation.

Project overview

Briefly describe the purpose of the project. Explain the need the product will fill for the customer or target market and how its development will benefit your company. Mention important goals for the project and any notable constraints that may have been imposed upon it.

Roles and responsibilities

This section lists the roles of those who will be involved with managing the requirements through the rest of the project lifecycle, along with the responsibilities of each role.

Typical roles include:

Project manager
Lead analyst / lead requirements engineer
Analyst / requirements engineer
Stakeholder

The project manager typically has overall responsibility for managing the scope of the requirements for the project.

The lead analyst / lead requirements engineer may also be a lead systems engineer or lead developer. This role is generally given overall responsibility for requirements development and integrity.

Analysts and requirements engineers assist the lead analyst / lead requirements engineer and are typically tasked with following the specified procedures for managing the subset of the project’s requirements for which they have been given responsibility.

Other project stakeholders who provide input to the requirements base are generally given responsibility for reviewing the requirements at specified milestones.

Tools

In this section of your plan, describe any automated tools that will be used to manage the requirements. Provide a brief overview of how those tools will be used during the requirements management process, and reference any documented procedures governing the use of the tools.

More detailed descriptions of how the tools shall be used in the various steps of the process should be provided in the sections of the plan that describe those steps.

Requirements gathering

Describe the process that you will use to elicit, analyze and document the requirements. Then, describe the requirements gathering techniques you will use and with what groups you will use them.

Categorization and assignment

Here, you will describe your process and procedures for dealing with various types of requirements.

Describe how requirements will be categorized within your requirements management system. Typical categories include:

Functional
Non-functional
Internal
External
Regulatory
Performance
Quality
Training
Support
Maintenance

The difference between functional and non-functional requirements—what the product must do versus any constraints on how the product must be constructed—normally impacts how the requirement will be verified. For more information on non-functional requirements and their impact on product development, click here.

Internal requirements will generally be driven by the needs of stakeholders within your organization. External requirements will include those driven by customers, market forces, government regulations industry standards, etc.

A requirement’s category will dictate, in part, how it is assigned for development, implementation and verification. Your plan should describe your policies and procedures for assigning requirements to subsystems or components or by work breakdown structure (WBS).

Prioritization

Companies will prioritize the fulfillment of some requirements over others. Reasons for high prioritization may include market demand, regulatory compliance, contractual obligation, or internal stakeholder need.

That’s why it’s important to plan and document how you will prioritize requirements for development and release. Keep in mind that you will likely describe in detail your rules for prioritizing requirements in your Product Requirements Document.

Traceability

Describe your overall process for tracing requirements throughout the product lifecycle: from gathering, through decomposition, development, implementation and verification. Mention the tools to be used to accomplish the traceability process.

Requirements and their attributes need to be tracked throughout the project lifecycle to ensure fulfillment. Attributes to be tracked may include:

Name
Type
Project unique identifier
Source (stakeholder, document, parent requirement, etc.)
Children (lower level requirements derived from the requirement)
Assigned element of the WBS where it will be addressed
Verification method (if your project requires a variety of methods)
Verification reference (to the procedure that will verify the requirement)
Compliance reference (applicable regulations/paragraphs)

Change management

As a project evolves, requirements will need to be added or modified. Therefore, your requirements management plan should include a section that describes your policies and procedures for change control.

Change management (or change control) generally involves documenting each proposed requirements change in a change request. Once written, the change request is analyzed by affected stakeholders for any possible impact on project objectives or other requirements. The change request then goes before a change control board where it is either accepted (to be implemented) or rejected (and either revised or dropped). Your procedures for change control (raising, reviewing, tracking and approving change requests) should be described or referenced in this section.

Configuration management

Describe how you will monitor and control changes to your requirements documentation. Configuration management deals primarily with how documents will be revised and released during a project.

For many projects, depending upon your organization, this section may be combined with the Change Management section just described. For very large projects, you may want a separate Configuration Management section. If you have a separate Configuration Management Plan you’ll probably want to reference it and keep this section brief.

Verification

Finally, describe the methods and metrics you will use to verify requirements. Specify how their achievement will be measured, tested, etc.

If you use a variety of verification methods to verify different types of requirements, you will likely want to give a brief explanation of the procedures for each and how each type of verification is documented.

Benefits of requirements management planning

As mentioned earlier, your requirements management plan is a tool for communication. It helps your analysts, systems engineers and developers get up to speed and stay on the same page when it comes to managing your project’s requirements. Plus, it gives higher-level stakeholders a warm, fuzzy feeling that your product’s requirements will be properly managed to ensure your product’s success.

For more in-depth information…

Requirements management and requirements management planning can be greatly simplified through the use of a state-of-the-art requirements management tool like Jama Connect. For a deeper dive, visit our Essential Guide to Requirements Management!

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.