Requirement management process

Requirements management is the process of understanding and controlling changes to system requirements throughout the project. It keeps track of individual requirements, maintains links between dependent requirements, design and code, and assesses the impact of each change before it is approved.

Requirements change as the business, laws, technology and users' understanding change. Sommerville divides them into enduring (stable, core business) and volatile (mutable, emergent, consequential, compatibility) requirements.

Requirements management planning

The plan decides:

1. Requirements identification: each requirement gets a unique ID (e.g. FR-12) so it can be referenced.
2. Change management process: the set of activities used to assess the impact and cost of changes.
3. Traceability policies: what links (traces) are recorded between requirements, sources and design, and how they are maintained.
4. CASE tool support: tools for storing requirements, managing changes and maintaining traceability (e.g. a requirements database or tracking tool).

Traceability types: source traceability (requirement to the stakeholder who proposed it), requirements traceability (between dependent requirements) and design traceability (requirement to design modules and code). A traceability matrix records these links:

Requirements change management process

 Identified problem / change request
             |
             v
 +---------------------------+
 | 1. Problem analysis and   |
 |    change specification   |
 +-------------+-------------+
               v
 +---------------------------+
 | 2. Change analysis and    |
 |    costing                |
 +-------------+-------------+
               v
 +---------------------------+
 | 3. Change implementation  |
 +-------------+-------------+
               v
      Revised requirements

1. Problem analysis and change specification: the requested change is analysed to check it is valid; feedback is given to the requester, who may give a more specific proposal or withdraw it.
2. Change analysis and costing: using traceability information, the effect of the change on other requirements, design, code and tests is assessed and its cost estimated. A decision is then made (often by a change control board) to accept or reject it.
3. Change implementation: the requirements document, then the design and implementation, are modified. The document should be organised so that changes can be made without extensive rewriting.

Example: in an online shop, the customer asks to add cash-on-delivery. Traceability shows it affects R3 (payment), the order module and test cases TC-05 and TC-09; the cost is estimated as 3 person-days, the change is approved, and the SRS, design and tests are updated together.