This content is part of the Essential Guide: Gathering and managing software project requirements
Get started Bring yourself up to speed with our introductory content.

Understanding the requirements process vs. requirements management

Requirements management and the requirements process are sometimes used to mean the same thing, but customers should be aware that there are differences, and that tools often do not perform all of the tasks in the requirements process.

How important is it to the testing process that requirements be managed properly? In what ways can team members gather and manage requirements that could facilitate testing?

Properly managing requirements is important to both development and testing, but it's not as important as certain -- primarily tool -- sources proclaim. Like so many buzzwords, requirements management is used by various folks to mean widely different things -- usually without recognizing the existence of said differences. Some use the term "requirements management" to refer to the requirements process as a whole; in my humble opinion, that's not accurate.

I find it more appropriate to restrict requirements management to the mechanical administrative activities of capturing, categorizing, tracking and controlling changes to requirements. The rest of the requirements process involves the far more difficult and important steps of identifying and evaluating the requirements content.

Like so many buzzwords, requirements management is used by various folks to mean widely different things -- usually without recognizing the existence of said differences.

Lest you think I'm alone in making these distinctions, be aware that most requirements management automated tools do only the former functions. Even those that do fit the complete requirements definition generally do so by structuring the requirements into use cases and confirming that various structural elements are present. It's also instructive to note that the original Capability Maturity Model had a level-2 key process area called "requirements management," whereas its successor, Capability Maturity Model Integrated, added a higher maturity level-3 "requirements development" key process area.

Probably the most common tool for the administrative area of requirements management is a traceability matrix. A traceability matrix shows where a requirement comes from and all the places where it was used, such as with various design components and tests. It is physically laborious to capture each cross-reference. All the automated tools aid in maintaining cross-references, but tools cannot help identify what the cross-references are that must be captured. The tools do save IT from some grunt work by generating current traceability matrix versions when cross-reference data has been manually updated in the tool, such as when a test has been passed or failed.

Tool vendors are especially prone to overstating the value of traceability matrices. Tracing forward from requirements can reveal ones that are not tested at all, and tracing backward from tests or components can reveal ones that seem not to relate to a requirement. To be practical, tools trace only high-level requirements, and one test related to each requirement is sufficient to generate a checkmark noting it has been tested. That in no way indicates the thoroughness or adequacy of those tests.

The key to more adequate requirements and tests is primarily in the definition, and only secondarily in the managing. Of course, knowing when things change is essential. This is another aspect of requirements management, as is limiting change. But the best way to control change is to make the requirements content more accurate initially.

Requirements provide value when a design of a product, system or software is implemented to meet them. Effective tests demonstrate that the designed and implemented product in fact satisfies the requirements. However, many tests merely demonstrate that the product was implemented as designed, which by itself provides no value.

Prioritizing requirements and defining them to the point where they are clear and testable increases the chance that the right product will be built correctly. It also provides more test points to confirm the product has been constructed correctly. Tracing tests to more detailed requirements can add confidence of coverage, but it still won't tell how adequate the tests are. Few trace in such detail because the greater the granularity, the more time-consuming it is to identify and capture cross-references.

Next Steps

Requirements management in collaboration with ALM tools

Trends in ALM: Requirements management tools

How to implement traceability into requirements management

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you distinguish between requirements management and the requirements process?
I might not be the world's best expert, but I see the whole "requirements process" as being in (basically) two parts. First you gather the requirements (by collaborating with the product owner or business/user reps) and then you manage them (by defining, refining, and incorporating ongoing feedback). I'm interested to hear how other folks think about requirements. 
I think that's a good way of putting it - and would add something about "translating" any requirements from the users into both business goals and actual development requirements. 
Ben, I think you’ll find that goals/objectives
have to precede defining requirements rather than being derived from the
  REAL business requirements
are deliverable
whats that provide
value by achieving goals/objectives and usually can be satisfied in many
possible ways.
  A product, system, or
software is one of those many possible ways
to satisfy the
whats; it is
high-level design and has product/system/software requirements in terms of
  Engineering/technical design
how to create the
product/system/software and its features; and it is what most people call “design,”
although sometimes it is referred to as “development or technical requirements.”

When I think of whats
I often think of solid items, but I don't think that's what you mean here. This
is a slightly silly example, but a business might think an answering machine is
what they need. The REAL business
requirement is probably a way to take phone messages when no one is available
to answer the phone. That means an answering machine would actually be
one potential how to take phone
messages (and not necessarily the best way to do it). Is that a clear way of describing what you mean by whats and hows?


Hi James, sorry for the delay
responding.  I’m not sure why it took until
today for the automated system to notify me of your discussion post.  Your example has the _what_ vs. _how_ distinction
exactly right.  Way to go!  Thank you.