Most BA work focuses on getting requirements right. Requirements Life Cycle Management (BABOK KA 3) is about keeping them right — from the moment they're identified through to when the solution is decommissioned.
Five tasks:
- Trace Requirements — linking requirements to their sources and to downstream artifacts (design, test cases)
- Maintain Requirements — keeping requirements accurate as the project evolves and new information arrives
- Prioritize Requirements — ordering requirements by value, risk, dependencies, and stakeholder need
- Assess Requirements Changes — evaluating the impact of proposed changes before approving them
- Approve Requirements — getting formal stakeholder sign-off at appropriate project gates
In practice, the tasks that most BAs underinvest in are maintenance and change assessment. Requirements that nobody maintains become stale — and stale requirements mislead the team. Change assessment prevents scope from expanding without consequence: every proposed change should trigger "what does this affect, and what does accepting it cost?"
On the LPT project, there was no change control process when I joined. Clients would add requirements informally, developers would pick them up, and nobody tracked the cumulative impact. One of the first things I introduced was a lightweight change request process — not bureaucracy, just: "if you want to change requirements, here's the conversation we need to have first."
Exam tip: Prioritization in BABOK is not the same as backlog ordering in Scrum. BABOK describes multiple techniques — MoSCoW, Kano, risk-based — and expects the BA to select based on context. CBAP questions test judgment, not technique memorization.