Requirements Life Cycle Management: Traceability, Change, and Approval
This domain covers managing requirements and design information from inception to retirement: tracing it, maintaining it, prioritising it, judging changes to it, and getting it approved. BABOK Guide v3 lists five tasks - Trace Requirements, Maintain Requirements, Prioritize Requirements, Assess Requirements Changes, and Approve Requirements. The exam tests whether you can keep a requirement set coherent as the change unfolds.
Core rules
- Traceability uses specific relationships, including derive, depend, necessitate, satisfy, and validate. Requirements are traced from business requirement down to stakeholder, solution, and transition requirements, and across to design components and test cases.
- Requirement types matter: business, stakeholder, solution (functional and non-functional), and transition. Transition requirements are temporary - needed only to move from current to new state - and are a frequent exam gap.
- Maintenance keeps attributes accurate: source, owner, priority, status, and version, plus baselines for reuse.
- Prioritisation uses value, risk, difficulty, and regulatory obligation. Techniques include ranking, grouping (such as MoSCoW), time-boxing, budgeting, or a combination. Priorities are revisited, not frozen.
- Change assessment weighs cost, benefit, risk, and impact before routing the request through governance to be approved, deferred, or rejected.
- Approval happens at defined points and by defined authority; it can be formal sign-off or documented informal agreement.
Worked example
Mid-project, marketing requests single sign-on. The BA traces it to the business goal "cut login support calls by 30%" and to one stakeholder requirement, then finds it touches four solution requirements, two interfaces, and six test cases, with a security review attached. At the change board the BA recommends deferral to release two because a regulatory date is fixed. The reasoning: the trace proved the value, the impact analysis priced the disruption, and governance made the decision rather than the loudest stakeholder.
Traps that cost marks
- Assuming an approved priority stays fixed for the project.
- Omitting transition requirements such as data conversion, cutover, and training because they disappear afterwards.
- Approving or rejecting a change without tracing it to a business need.
- Confusing maintaining requirements with assessing changes to them.