What is Requirements Gathering?

Requirements gathering is the process of understanding what you are trying to build and why you are building it. Requirements gathering is often regarded as a part of developing software applications or of cyber-physical systems like aircraft, spacecraft, and automobiles (where specifications cover both software and hardware). It can, however, be applied to any product or project, from designing a new sailboat to building a patio deck to remodeling a bathroom.

Three Main Subprocesses of Requirements Gathering

The key ingredients of the requirements gathering process are three overlapping subprocesses: requirements elicitation, requirements documentation, and requirements understanding.

Requirements elicitation is the process of asking for and collecting top-level requirements from all relevant stakeholders. Effort should be made to account for the needs of customers, their users, the internal stakeholders within your own company, and your key suppliers.

Requirements documentation organizes the input from the requirements elicitation process into whatever format is appropriate for your organization. This formatting may include:

User stories
Functional decompositions (especially for complex cyber-physical systems)
Feature descriptions

These will be collected in a top-level requirements specification like a product requirements document (PRD) or a system specification. The purpose of this top-level specification is to make those stories and descriptions available to all members of the project team.

Requirements confirmation is the process of making sure all stakeholders and team members have a common understanding of what you’re trying to build. This involves reviewing and refining the requirements. It will very likely require additional elicitation and revision of the documentation as well.

What are the Benefits of Requirements Gathering?

Beyond the obvious advantage of having requirements with which to work, a good requirements gathering process offers the following benefits:

Greatly improves the chances that customers and users will get what they wanted. Stakeholders often have difficulty putting into words exactly what it is that they need. You’re going to have to help them, and it’s going to take some digging.
Decreases the chances of a failed project. A frequently heard lament following unsuccessful projects is, “The requirements weren’t clear.”
Reduces the overall cost of the project by catching requirements problems before development begins. Requirements that are ambiguous or not fully understood often result in costly scrap and rework. Numerous studies have shown that the cost of fixing requirements errors rises exponentially over subsequent phases of development.

Some Key Challenges of Requirements Gathering

One of the reasons projects fail due to poor requirements is this: requirements gathering isn’t easy. Here are some of the main challenges:

Finding All the Right Stakeholders

Projects often have “hidden” stakeholders. It’s important to uncover them. The group you canvas should include more than just the obvious decision-makers. Don’t forget to talk to customer support reps, maintenance technicians, and others who come into direct contact with customers. They are themselves, in effect, users of your existing products.

“Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project,” says Jordan Hirsch, Director of Innovation at Phase2 Technology.

Understanding What Stakeholders Really Want

Your stakeholders may not have a clear vision of what they want. They may not be able to tell you a complete story. They may have hidden pain points or desires, unstated goals, or assumptions. You’re going to have to ask a lot of probing questions and compare answers. You’re also going to have to go through several iterations of your process to arrive at a consensus.

Planning for Change

Throughout the requirements gathering process, you’re going to come across questions you forgot to ask and things stakeholders forgot to tell you. You’ll come up against shifting priorities and problems encountered during implementation.

It’s wise to have a plan for dealing with those changes. You’ll need to allow time for addressing problems, documenting new requirements, and conducting additional reviews.

A 6-Step Requirements Gathering Process

The requirements gathering process consists of six steps. Three of those (steps three through five—the bulk of the process) we’ve already mentioned as the key subprocesses of requirements gathering. The full six steps are:

Identify the relevant stakeholders
Establish project goals and objectives
Elicit requirements from stakeholders
Document the requirements
Confirm the requirements
Prioritize the requirements

It is important to note that while these steps are typically initiated in the order listed, there is a great deal of overlap and iteration among them. It may, therefore, be better to think of them as subprocesses rather than steps as we look at each one individually.

Identify the Relevant Stakeholders

Find qualified representatives from each relevant stakeholder group. Depending on your project, these may include:

Customers stakeholders
Decision-makers
Users
System administrators
Other impacted customer departments
Internal stakeholders
Executives
Engineering
Marketing
Sales
Customer support (including on-site maintenance teams, if applicable)
Key suppliers
Distributers and other partners

Remember to search for “hidden stakeholders.” Ask probing questions in early meetings, before you begin eliciting requirements. Identify all stakeholder groups who need to be involved. Ideally, you want input from every group who has skin in the game; give them all the opportunity to state their needs.

Establish Project Goals and Objectives

What are you trying to achieve with this new product or project? What are the overall outcomes your customers want from the product? What are your company’s business goals? What are the actionable, measurable objectives you need to achieve to realize those goals and outcomes?

Write them down. State them clearly, and get all your stakeholders to sign off on them. Your goals and objectives will act as a framework for your decision-making.

Each requirement you write should help satisfy a project objective and accomplish a goal. If it doesn’t, you should either discard it or made it a candidate for a future release.

Elicit Requirements From Your Stakeholders

This is the first of three requirements gathering subprocesses which are highly iterative and overlapping. Even in an agile environment, you are likely to go through several cycles of elicitation, documentation, and review/confirmation before you achieve a workable specification to begin development.

Elicitation can be performed in several ways. Time-tested techniques include surveys, questionnaires, and interviews. Interviews and follow-up meetings will be prevalent during later iterations.

Be sure to listen actively during interviews. Ask probing questions and take copious notes. Afterward, organize your notes and follow up as necessary. Document each exercise or encounter thoroughly.

Document the Requirements

As soon as requirements begin to emerge from your elicitation process, begin documenting them.

Write them down and collect them in whatever format your organization has agreed upon. That could be a product requirements document (PRD) of your company’s design, a government-mandated system requirements specification, a vendor-supplied requirements management (RM) tool like Jama Connect, a spreadsheet, a database, or any other appropriate repository your entire team can access.

What’s most important is that the requirements documentation…

Can be easily navigated and understood by your team
Is available for review by all stakeholders
Provides a facility for traceability to other documentation.

Templates are extremely useful, both for the specification as a whole and for individual requirements. Solid, battle-tested templates and standardized formats help provide clarity and aid navigation.

Confirm the Requirements

Review the requirements with all stakeholders. Make sure the requirements clearly capture what was intended and that all parties have a common understanding of each of them. If you find any ambiguity in a requirement, revise it.

You should also validate your requirements through prototyping and testing, where possible. Modern prototyping tools make it fast and easy to create a working model of your specification. You can then use that model to perform feasibility, usability, and product concept testing.

Get stakeholder sign-off on individual requirements as you get them nailed down. Do the same for the specification as a whole during a final review.

Prioritize the Requirements

Most engineering development programs run into unexpected challenges along the way. Unanticipated obstacles are encountered. Schedules slip. Priorities change. It’s important to be able to adapt to those challenges and changes.

That’s why it is crucial to prioritize your requirements based on how each will impact your goals and objectives for your release.

Many product managers prioritize features by tagging them with labels, such as “must have,” “high want,” and “nice to have.” But it’s also important to rank order each requirement within those categories. There are two reasons for this.

The first is time to market. Schedules often slip. When they do, you may need to trim features and requirements to meet your release date. You don’t want your team implementing the easiest requirements first only to find that there’s not enough time to complete all your must-haves.

The second reason is that requirements evolve. During implementation, you’re likely to discover new needs. Some may be critically important and supersede existing requirements in terms of priority. You need to know where those new requirements fit in your pecking order. If you don’t, less important factors will determine what gets implemented first, which may have an adverse impact on your product’s success.

Common Requirements Gathering Pitfalls

Making Assumptions About What You’ve Heard

Beware of simple, broad requirements. Don’t assume you know exactly what they mean. Above all, don’t assume all your stakeholders interpret those requirements in the same way.

Broad statements like, “The site shall have a blog” can mask a host of underlying assumptions. Scrutinize such requirements. Ask lots of questions. How will posts be displayed? How should authors be managed? How about comments, categories, tagging? Should there be an RSS feed?… and so forth.

Cross-check the answers you receive. Then come up with a set of more specific, verifiable requirements that everyone can agree upon.

Focusing on HOW Instead of WHAT

Requirements address two things. The first is WHAT the product must do (the functional requirements). The second is the necessary constraints on how the product does what it does (the non-functional requirements).

Requirements should not address HOW the product does what it has to do. In other words, your specification should be as implementation-agnostic as possible, within the constraints of the non-functional requirements.

During requirements elicitation, try not to think about how you’re going to implement the product. Forget about the latest technology engineering is obsessed with, your software team’s tool du jour, and any features you think are missing from the product baseline. Focus instead on your stakeholders’ needs.

Listen to what your stakeholders are saying first. Then gather, review and refine your requirements. Finally, once you’ve done all that, find the gaps in your baseline, and determine which technologies will deliver what your customers and stakeholders really want.

Insufficient Consultation With Stakeholders

Perhaps the biggest mistake systems engineers and product managers make in gathering requirements is failing to adequately consult with their stakeholders. Stakeholder consultation has several facets.

First, it is critically important that you drill down (and follow up) with each stakeholder group to fully understand their needs. Failure to do so is one of the leading causes of requirements failures.

A second important facet is transparency. Clean up your notes and share them after every interview, meeting, and survey. The easiest way to do this is through a modern RM tool to which all team members have access. Tools like Jama Connect allow you to attach notes to the requirements themselves for traceability purposes. This greatly increases the speed of the process and simplifies the review task.

The third potential pitfall in this area is insufficient review. Be sure to hold reviews where stakeholders can review the requirements, provide feedback, voice objections, and defend their positions. Open discussions involving all concerned stakeholders can help uncover and correct requirements flaws and achieve consensus.

Finally, get all your stakeholders to sign off on the requirements to acknowledge that they understand them and that the requirements are sufficient for them to do their jobs. Be sure to make it clear to the stakeholder what his or her signature means.

Requirements Gathering for Agile Development

What’s different about requirements gathering for Agile?

First off, agile teams expect to move fast. So, their requirements management solutions must meet their developers’ need for speed.

Transparency is another priority. Requirements documentation must be constantly up-to-date, easily annotated, and provide clear traceability.

Both of these needs make Word documents and Excel spreadsheets poor RM choices for agile teams. Their static nature makes them tedious to update and cumbersome to share. Those drawbacks make it difficult to give everyone fast access to the latest configuration and keep them all on the same page. Plus, docs and spreadsheets don’t provide native features for annotation and traceability.

RM products like Jama Connect help Agile teams streamline requirements gathering and collaboratively manage requirements in real-time throughout the ALM product development process.

Are you working in an Agile development environment? See how Jama Connect can streamline requirements gathering and management by downloading our datasheet.

Author
Recent Posts

Jama Software

Subject matter experts from Jama Software provide guidance and best practices on requirements management, test management, compliance and regulation, risk management, and complex product and software development.

What is Requirements Gathering? A Process Guide for Product Teams