Some use the term requirements management to mean the full requirements process, including identifying business...
requirements and evaluating their content. In my humble opinion, it is more appropriate to restrict the phrase requirements management to the mostly mechanical administrative activities of capturing, categorizing, keeping track of and controlling changes to requirements.
The two aspects do interact, and how they interact is especially relevant for the way Agile requirements are documented. In Agile, the product owner or customer representative typically defines requirements with user stories. A user story very briefly describes something of value to a user or customer and traditionally is written on an index card in the form introduced by Mike Cohn, "As a <type of user> I <want/can/am able to/need to/etc.> so that <some reason>." Some teams also include their user story acceptance criteria (brief descriptions written on the back of the index card of how to tell the user story has been met) in the user stories.
Non-Agile development also documents business requirements definitions. Non-Agile teams could, but usually don't, write them in a user story format yielding one requirement per index card. Initial business requirements documentation formats are not terribly critical for distinguishing between Agile and non-Agile. What happens afterward, though, tends to differ widely between Agile and non-Agile development.
A non-Agile group generally keeps track of all the written requirements throughout the duration of the project and captures written expansions/modifications of them. This process drives the business requirements document down to greater detail or otherwise clarifies them. Non-Agile often actively controls prospective changes to business requirements documents with a change control board or similar body. This body pre-approves requested changes and sometimes also confirms approved changes have been made as approved. Those non-Agile projects that use automated requirements management tools often cross-reference each requirement to where it is used in order to create a traceability matrix. Such a matrix helps confirm that each requirement has been addressed and that development is not creating artifacts that don't tie to requirements.
Have more software quality questions for our experts?
Check out our recent expert responses.
If your answer's not there, submit a new question.
Dig Deeper on Gathering Software Requirements Use Cases
Related Q&A from Robin F. Goldsmith
Using a WBS can help make a big task like requirements easier. Expert Robin Goldsmith explains how developers and testers can make the most of this ...continue reading
How do you engage high-level business executives in the process of writing business requirements?continue reading
Why don't users seem to appreciate typical software QA testing status reports?continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.