Knowledge areas BABOK Guide v3, chapter 5
Requirements Life Cycle Management
In short This knowledge area covers how you look after requirements and designs once they exist: linking them, keeping them current, ordering them by importance, judging proposed changes, and getting agreement. It applies whatever methodology you use.
Based on: IIBA, BABOK® Guide v3, chapter 5 “Requirements Life Cycle Management”; business analysis training materials (task reference cards and course slides), which also present C. Moore’s conflict types from The Mediation Process.
On this page
Purpose#
A requirement has a life: it is proposed, refined, prioritized, approved, built, tested, changed, reused or retired. The BABOK® Guide separates this life cycle from any particular delivery method. A requirement can even be in several states at once, for example approved for one release but still being refined for another.
Through the lens of the Business Analysis Core Concept Model, you manage how proposed changes to requirements are evaluated, keep requirements traced and current so that they still address the need, show through traceability that the solution satisfies the need, maintain stakeholder understanding and approval, and extend the value of good requirements by reusing them beyond the current initiative.
Tasks#
The BABOK Guide defines five tasks.
5.1 Trace Requirements. You create and maintain links between requirements, designs, solution components and other work products, so you can see impact, coverage and allocation. You produce: traced requirements and designs.
5.2 Maintain Requirements. You keep requirements and designs correct and up to date over time, and in a form that can be reused later. You produce: maintained requirements and designs.
5.3 Prioritize Requirements. You rank requirements and designs by value, urgency, risk and other agreed factors so that the team works on the most important ones first. You produce: prioritized requirements and designs.
5.4 Assess Requirements Changes. You evaluate new or changed requests to decide whether and how they belong in the current change, and what their impact would be. You produce: a requirements change assessment.
5.5 Approve Requirements. You work with the right stakeholders to reach agreement on requirements and designs, and record that agreement. You produce: approved requirements and designs.
Key inputs and outputs#
| Task | What goes in (simplified) | What comes out |
|---|---|---|
| 5.1 Trace | Requirements and designs | Traced requirements and designs |
| 5.2 Maintain | Requirements and designs | Maintained, reusable requirements and designs |
| 5.3 Prioritize | Requirements and designs; the change strategy; the governance approach; the requirements architecture | Prioritized requirements and designs |
| 5.4 Assess changes | A proposed change; current requirements and designs | Change assessment with impact and recommendation |
| 5.5 Approve | Verified requirements; designs | Approved requirements and designs |
Techniques you will use most#
- Scope Modelling, Functional Decomposition and Process Modelling: give you a structure to trace against.
- Business Rules Analysis: rules are a frequent source of linked and reusable requirements.
- Data Modelling, Data Flow Diagrams, Use Cases and Scenarios and User Stories: the formats you will keep current.
- Prioritization and Backlog Management: order the work.
- Business Cases, Financial Analysis, Estimation and Decision Analysis: give priorities and change decisions a factual basis.
- Interface Analysis and Risk Analysis and Management: reveal the knock-on effects of a change.
- Acceptance and Evaluation Criteria, Item Tracking and Reviews: support approval.
Practical tips#
Use a small, fixed set of trace relationships#
The training materials describe four kinds of link, following the BABOK Guide:
- Derive: one requirement comes from another, for example a solution requirement derived from a business requirement.
- Depends: one requirement relies on another. Either it only makes sense if the other is built (necessity), or it is easier to build once the other exists (effort).
- Satisfy: links a requirement to the solution element that implements it.
- Validate: links a requirement to the test case that checks it.
Trace only as deep as someone will use. Tracing everything to everything is expensive and quickly goes stale.
Pick a prioritization method that fits the decision#
- MoSCoW (which the training materials take from the Agile Extension to the BABOK Guide): Must have, Should have, Could have, Won’t have this time. “Won’t” is an agreed exclusion, not a rejection forever.
- Time-boxing or budgeting: with a fixed budget or deadline, you either take everything and cut back (all in), start from nothing and add (all out), or start from the top priorities and add or remove until you hit the limit (selective).
- Voting: each participant gets a fixed number of votes or tokens to spread across requirements; the most votes win.
Whatever the method, agree the factors in advance: benefit, penalty for not doing it, cost, risk, dependencies, time sensitivity, stability and regulatory or policy compliance are the usual ones.
Expect conflict at approval, and name its type#
The training materials use five conflict types from C. Moore’s mediation model. Naming the type tells you what will help:
- Data conflict: missing or wrong information, or different readings of the same facts. Fix with shared evidence.
- Interest conflict: stakeholders want different outcomes, such as quality versus speed. Fix by negotiating trade-offs.
- Value conflict: different beliefs or cultural norms. Look for goals both sides can accept.
- Relationship conflict: strong emotions, stereotypes or personal history. Separate people from the issue; involve a neutral facilitator.
- Structural conflict: unequal authority, such as manager and subordinate. Use governance rules that define who decides.
Example: assessing a change at The Workshop#
At The Workshop (a fictional chain of 12 bike-repair shops), the owner asks to add text-message notifications on top of email. The analyst traces the request to the business requirement “reduce status calls to the front desk”, checks dependencies (the notification service, customer phone numbers in the booking form, consent wording), estimates the effort with the development team, and records a change assessment with options: include now, schedule for the next release, or decline. The sponsor decides using the governance approach agreed in planning.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Chapter 5 “Requirements Life Cycle Management”.
- Business analysis training materials (practice examples and templates): task reference cards for chapter 5; course slides on requirements life cycle management (trace relationships, prioritization methods, conflict types).
- C. Moore. The Mediation Process, 3rd ed., 2003 (five conflict types, as presented in the training materials).