Agile Requirements Management

There are several reasons why some companies want to have a disciplined requirements management process:

  • The organization needs to comply with regulatory or quality management system standards, like ISO9001 or TL9000, and is subject to regular audits to verify compliance.
  • The organization builds software to contract and needs traceability mechanisms to ensure that every requirement has been delivered and validated.
  • The organization develops large scale software, and while embracing the principle of “working software over documentation”, is not confident that post-it notes are a reliable way of managing thousands of requirements.

Thus the organization needs a way of defining user requirements, tracing them through the development process, and managing changes. Documentation is certainly not the goal, but can be a necessary part of the process to achieve the goal of guaranteeing the needs of customers and stakeholders have been met. Just as doing iterations is not the same as being agile, there is no contradiction in being ISO9001-compliant and operating a highly agile development process – continuous integration, unit test automation with coverage measurement, and highly automated system and regression testing.

The process/tools we use to deliver an effective requirements management process must meet 2 key goals:

  1. Demonstrate Traceability
    • At minimum demonstrate upstream traceability between the customer-facing product requirements (“PRD”), or the customer contract, and the internal Epics and User Stories that the development team is building.
    • Ideally also show down-stream traceability between user stories and test cases (and software bugs) so that test coverage and delivered quality of the requirements can be measured and quantified
  2. Provide Structure
    • With many of the commercial agile tools it is very difficult to see the forest from the trees. When I look at the user story backlog for a product in a tool, I would like to see something that resembles the PRD, not an unstructured list of items that leaves me wondering if we have captured everything in the contract.

In Fig. 1 below we have (in a spreadsheet) the contents page from the PRD/Contract, with user stories created for each feature. This layout provides both traceability and structure.

Figure 1. Requirements Traceability and Structure

Print Friendly

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>