What Is Requirements Management? Tips + Tactics | Perforce

September 21, 2020

How important is requirements management? And how do you get the most out of your process? In this article, I’ll share the basics as well as tips for success. Finally, we’ll cover what you should be looking for in a requirements management tool.

You can skip ahead by clicking a heading:

What Is Requirements Management?

Requirements management spans many steps to ensure a product or project succeeds. Steps include: gathering, understanding, refining, prioritizing, and planning everything a product or project needs to succeed.

The goal? To make sure your end product meets the needs of customers and stakeholders.

It demands:

• Clear communication between team and stakeholders.

• Constant adjustments to change throughout the project lifecycle.

Managing requirements is a continuous process throughout the product lifecycle. Requirements themselves can be generated by many stakeholders, including customers, partners, sales, support, management, engineering, operations, and product management.
 

What Is a Requirement? A Modern Definition

Requirements take many shapes these days. You might hear them called user stories, use cases, or features, but they all really boil down to a common denominator:

A requirement is simply “a condition or capability to which a system must conform.”

So, in reality, a requirement might be any of the following:

• A capability needed by a customer or user to solve a problem or achieve an objective.

• A capability that must be met or possessed by a system to satisfy a contract, standard,

  specification, regulation, or other formally imposed document.

• A restriction imposed by a stakeholder. Time and budget are common restrictions.

Yes, there are many ways to describe a requirement. But don’t let linguistics get in the way of understanding their goal: to build a great product — one that customers actually want — on time, on budget, and with few surprises.

Why Is Managing Requirements Important?

Managing requirements is crucial to a successful project. Because they set the stage for your entire project, getting them right is essential.

Requirements Can Break Your Project

Inadequate requirements are the #1 reason why projects fail! There are many reasons why a project gets off the rails, but a poor requirements development process is chief among them.

Requirements Are Cheap to Change

The cheapest time to change a project is during the requirements phase. The same change made further along in the development lifecycle costs more and more.
 

Error Discovered

Cost to Correct

Requirements Development

1x

Design

2–3x

Construction

5–10x

System/Acceptance Test

8–20X

Operation

68–110x

Requirements Are Your Future Product

To hammer home the importance of requirements, here’s a simple framework built around a phrase you may recognize: “Garbage In, Garbage Out.” When poorly defined, valueless requirements go into development, they transform into a poorly defined, valueless product.
 

Valuable products are a result of valuable inputs and processes.

There’s another variable to consider: your process. As the diagram above illustrates, even perfect requirements can’t withstand the damaging effects of a poor process. You need valuable requirements and processes if you want a valuable product!

With that in mind, let’s go into the process.

Requirements Management Process

Below, we’ll cover what a more-or-less traditional process includes. We treat each activity lightly in this article. In reality, each of these areas could have its own in-depth manual.

A typical process for managing requirements.

1. Requirements Planning

First, develop a plan for gathering and communicating requirements. You’ll want to include things like:

• Scope

• Assumptions, dependencies, and risks

• Team roles

• Stakeholder communication plan

• Project plan

2. Requirements Development

Next, you develop your requirements. Requirements development includes gathering (collecting as many known requirements as possible), defining (organizing and documenting requirements), and analyzing (discovering unknown requirements to mitigate risk).

3. Requirements Verification and Validation

During design verification, you check that you did everything you said you were going to do. You might also conduct design validation here, which is user testing and other activities that validate the product functions for the end users as intended.

4. Requirements Change Management

It does not end with product release! After release, incoming data about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Have a process for managing change!

[Related Webinar: Essential Tips for Modern Requirements Management]

8 Best Practices for Managing Requirements

There are many ways to ensure you’re managing your requirements as well as possible, but the following best are essential.

1. Make Sure You’re Well-Understood

Everyone needs to be on the same page before work begins. And then everyone that is working needs to be on the same page. That’s essentially the point of requirements and requirements documents.

If not, you risk having teams develop, test, or build the wrong project (or building the right project incorrectly). Both are bad. If you work with people whose first language isn’t your own (something that’s becoming more common as teams work from all over the world), being well-understand can take more time.

Are you building a duck or a bunny? Make sure everyone is seeing the same thing when managing requirements.

2. Stay Lean & Concise

Requirements from what we might call “days of yore” were stored in massive binders. We’ve come a long way since then. One result of the Agile movement is we’ve seen a general trimming down of upfront requirements. One straightforward practice for keeping requirements lean? Leave out existing functionality.

3. Picture It

Your documentation—does it need to be text? What about a picture, or a table? Would that communicate your point without requiring that someone dive into blocks of text? Then, use them!

4. Use Templates

Save time and effort by creating templates for your requirements documents. The bonus is that templates also make it easier for teams to understand and read the document if they’ve encountered it before. Don’t reinvent the wheel with each new requirement.

5. Know Your Types

Not all requirements are equal. There are many different types of requirements (functional, non-functional, business), and should all be understood/handled appropriately. For example, you might restrict review of business requirements to a select group of stakeholders.

6. Be Complete

Now, we don’t want to write lean requirements (see “Stay Lean & Concise” above) that are incomplete. By complete, I mean, are you gathering requirements from a well-rounded list of customers, colleagues (sales and marketing teams, support), as well as researching what the market wants? Or is it the loudest customers and sales team members? In the end, you want a good, well-rounded, holistic set of requirements.

A second valuable path for thinking about being complete: Do your requirements provide the right amount of detail for everyone that touches them. Keep in mind that everyone has a different need and perspective. For example:

• Product Manager — Can I sell this?

• Marketing — Can we market this?

• Tech Writers — Can we document this?

• QA — Can I test this?

• CEO — What is this

Are your requirements serving each of them in valuable ways?

7. Take the Pain Out of Review

Part of the process is having relevant team members and stakeholders review. In fact, tracking down reviews can feel like a job all by itself. The best way to get those reviews is to make it as painless as possible. Have a clearly defined process.

Beyond process, make sure you’re giving clear direction to your reviewers. An example would be to ask a testing team to “Review section 2.1.2.1 [FR-25] for testability.” Otherwise, you may get unclear or incomplete reviews from stakeholders (which gives you more work to interpret and sort out.)

8. Structure for Better Traceability

Structuring requirements with good parent-to-child relationships, as shown here in Helix ALM, simplifies traceability.

If you structure your requirements with solid parent-child relationships, you make the later critical process of verification much easier on everyone. A requirements traceability matrix, like pictured above in Helix ALM, can show clear connections between requirements and their resulting tests and issues. The alternative is to have an ad hoc structure, in which every requirement lives independently — not good when traceability matters.
 

[Free Whitepaper: 9 Tips for Writing Useful Requirements]
 

If you’re undertaking a simple project, then you can likely manage requirements using rudimentary spreadsheets or Word documents. If, on the other hand, you’re in hardware or software development, then you are going to appreciate what dedicated tools bring to streamline your process. 

What Features Should You Look For in a Tool?

There is no single template for must-have features to have in a requirements management tool. It depends on your organization, what you’re building, your process, and many other aspects (such as culture, for example).

In light of that, here’s a checklist you can use in finding a good requirements management tool:

Y/NDesired Features Can quickly enter or import requirements. Can create detailed technical tasks from requirements for building the project development schedule. Can include acceptance criteria so features are adequately tested before development is complete. Includes visual tools, such as planning boards. Integrates with version control and history tracking of requirements. Supports real-time collaboration during requirements validation. Drills down from requirements to tests and issues. Offers personalized dashboards and customizable reporting. Provides for forward and backward impact analysis.With forward & backward impact analysis, you can understand the impacts of change and reduce risk.

 

Bringing It All Together

Whatever you call them — whether user stories, requirements, or something else — they serve as the critical foundation for your project in that they define what you’re going to build. Requirements are also, as I pointed out earlier, not only the cheapest place to make changes, but the number one cause of project failure. Requirements: manage them well—they’re not worth risking!

Improve Requirements Management

See how Helix ALM simplifies the entire development lifecycle. Try it free for 30 days.

Manage Requirements in Helix ALM I prefer to watch the demo