Requirements Life Cycle Management
Requirements Life Cycle Management keeps requirements and designs usable from the moment they are created until the solution is retired. The exam tests whether you can trace, maintain, prioritise, change-control and approve requirements with the discipline an auditor would expect - and whether you know who is allowed to say yes.
The five tasks
- Trace Requirements - link requirements to their origin (business need, stakeholder, regulation), to each other (parent, derived, dependent), and to downstream work products (design components, test cases, training). Traceability answers impact questions and proves coverage in both directions.
- Maintain Requirements - keep the repository accurate and consistent, and reuse requirements across initiatives where they still hold.
- Prioritise Requirements - rank on value, risk, difficulty, dependency, regulatory obligation and time sensitivity; the basis must be agreed before ranking starts.
- Assess Requirements Changes - evaluate impact on value, cost, schedule, risk, interfaces and other requirements before accepting or rejecting.
- Approve Requirements - confirm with the right authority that requirements are complete and correct enough to proceed; establish baselines and manage later change against them.
Worked example
A change request proposes adding multi-currency pricing. Reasoning: trace forward from the price-display requirement to its test cases and to the invoice-printing design; trace backward to the pricing policy and the two stakeholder groups that signed it off. The impact assessment lists three interfaces, a currency-rate feed contract, VAT reporting rules, four test scripts and a training update - plus a dependency on the finance team’s rate source that nobody had documented. Priority is not raised because the request came from a senior manager; it is scored against the agreed basis (regulatory first, then revenue impact), and the sponsor approves the revised baseline.
Traps that cost marks
- Tracing only backwards: origin is captured, coverage is never proven.
- Prioritising by seniority or volume of voice instead of a stated, agreed basis.
- Treating approval as one final signature at project end; baselines are approved incrementally.
- Assessing a change on cost alone, missing risk, dependency and benefit effects.
- Maintaining requirements as a filing exercise while designs and tests drift out of step.