Overview
Requirements Life Cycle Management covers five tasks that keep requirements and designs usable over time. You trace them to each other and to their sources, maintain them and their attributes so they stay accurate and reusable, prioritize them on an agreed basis, assess the impact of proposed changes, and work with authorized stakeholders to approve them. The life cycle runs from the moment a need is represented until the requirement is retired, not just until a project ends.
This knowledge area puts Domain 1's planning into practice: the governance approach defines who approves and how changes are controlled, and the information management approach defines traceability and attributes. It works alongside Domain 5, which specifies and verifies the requirements this domain manages, and Domain 4, whose business objectives provide the basis for prioritization and for judging whether a change is worth it.
How it's tested
Expect scenario questions that ask what the business analyst should do FIRST when a change request arrives, how to resolve a priority conflict, or which traceability relationship or attribute applies. The reasoning pattern is to follow the agreed governance and information management approach, analyze before deciding, and leave decisions with authorized stakeholders.
-
Handle the change request
A stakeholder asks for a late change. You choose to assess impact through the agreed change control process before anyone accepts or rejects it.
-
Resolve the priority conflict
Stakeholders disagree about what matters most. You select a basis for prioritization such as benefit, penalty, cost, risk or dependencies and facilitate agreement.
-
Name the relationship
Two requirements or a requirement and a design are described. You identify whether they derive, depend, satisfy or validate.
A regional director asks a business analyst to add a new report two weeks before release, saying it is mandatory. Options include adding it immediately, rejecting it because scope is frozen, asking the sponsor to approve it, and assessing its benefit, cost, schedule impact and urgency through the change control process. Only the last applies the governance approach; acceptance, rejection or approval without impact analysis skips the decision information stakeholders need.
Tasks 5
Official tasks from the IIBA outline, in outline order.
3.1 Trace RequirementsBABOK Guide task 5.1: establish relationships between requirements, designs and other information.
- What it means
- The business analyst records relationships so that requirements and designs can be followed from their origin through to the solution components and tests. The BABOK names derive, depends (necessity and effort), satisfy and validate relationships. The outputs are requirements (traced) and designs (traced).
- What to understand
- Traceability supports impact analysis, coverage checks, scope control and reuse. Its formality should match the approach planned in Domain 1; tracing everything creates cost without proportional benefit.
- How it shows up
- You are told a requirement implements a business rule from a higher-level requirement, or a test case checks a requirement, and asked which relationship applies.
- Common confusion
- Confusing satisfy with validate. Satisfy links a requirement to the solution component that implements it; validate links a requirement to the test or evidence that checks it.
3.2 Maintain RequirementsBABOK Guide task 5.2: keep requirements and their attributes accurate, consistent and available for reuse.
- What it means
- The business analyst keeps requirements correct and current as changes are approved, maintains attributes such as status, source and priority, and identifies requirements that can be reused in other initiatives or by ongoing operations. The outputs are requirements (maintained) and designs (maintained).
- What to understand
- Maintenance continues beyond a single project; long-lived requirements such as regulations and business rules are valuable reusable assets when kept at the right level of abstraction.
- How it shows up
- An organization repeatedly re-elicits the same compliance requirements on every project. The answer is maintaining reusable requirements, not running more workshops.
- Common confusion
- Thinking maintenance means changing requirements. Changes are assessed and approved in other tasks; maintenance keeps the approved state accurate and accessible.
3.3 Prioritize RequirementsBABOK Guide task 5.3: rank requirements and designs by relative importance on an agreed basis.
- What it means
- The business analyst facilitates stakeholders in ranking requirements using a basis such as benefit, penalty, cost, risk, dependencies, time sensitivity, stability and regulatory or policy compliance, and manages challenges such as non-negotiable demands and unrealistic tradeoffs. The output is requirements (prioritized).
- What to understand
- Prioritization is ongoing and should reflect value to the business. Dependencies can force a low-value requirement ahead of a high-value one, and regulatory requirements carry a penalty if omitted.
- How it shows up
- Every stakeholder marks everything as high priority, and you choose how to proceed. The answer applies an agreed basis and technique such as MoSCoW or a backlog, not personal judgment.
- Common confusion
- Treating priority as the same as sequence. Something can be lower in value yet built first because another requirement depends on it.
3.4 Assess Requirements ChangesBABOK Guide task 5.4: evaluate the implications of proposed changes to requirements and designs.
- What it means
- The business analyst decides the formality of the assessment, analyzes the impact of the change on benefit, cost, schedule and urgency, and works toward resolution under the governance approach. The outputs are the requirements change assessment and designs change assessment.
- What to understand
- Traceability makes impact analysis possible by revealing which requirements, designs and components the change touches. Assessment informs a decision; it does not make it.
- How it shows up
- A senior stakeholder pushes a change late in delivery and you are asked what to do FIRST. Assess its impact through the change control process.
- Common confusion
- Assuming adaptive approaches skip change assessment. Changes are expected, but impact on value, cost and the backlog is still assessed, often with less formality.
3.5 Approve RequirementsBABOK Guide task 5.5: obtain agreement on requirements and designs from authorized stakeholders.
- What it means
- The business analyst understands stakeholder roles and authority, manages conflicts and issues, gains consensus, and tracks and communicates approval decisions. The outputs are requirements (approved) and designs (approved).
- What to understand
- Approval follows the governance approach and may be formal sign-off in predictive work or acceptance of backlog items in adaptive work. Recording who approved what, and when, protects against later disputes.
- How it shows up
- An approver later claims they never agreed, or two approvers disagree. The answer applies the governance approach, resolves the conflict and records decisions.
- Common confusion
- Thinking the business analyst grants approval. The business analyst facilitates and records it; authority belongs to designated stakeholders.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Derive relationship
Links a requirement to another requirement that was derived from it, such as a solution requirement derived from a business requirement.
- Remember
- Derive connects levels of abstraction, from more general to more detailed.
- Tested as
- Questions ask which relationship connects a business requirement to the stakeholder or solution requirement that elaborates it.
- Trap
- Choosing depends because one requirement 'needs' the other.
-
Depends relationship (necessity and effort)
Necessity means one requirement only makes sense if another is implemented; effort means one is easier to implement if the other is implemented.
- Remember
- Depends relationships affect sequencing and prioritization even when value is low.
- Tested as
- Prioritization stems often hide a dependency that changes the order.
- Trap
- Ignoring effort dependencies because they are not strict prerequisites.
-
Satisfy vs. validate relationships
Satisfy links an implementation element such as a solution component to the requirement it fulfills; validate links a requirement to a test case or other evidence that it is met.
- Remember
- Satisfy is about implementation, validate is about confirming the implementation works.
- Tested as
- Coverage questions test whether every requirement has both an implementing element and a test.
- Trap
- Using the everyday meaning of validation, which is tested elsewhere as value alignment.
-
Basis for prioritization
Factors the BABOK lists for ranking requirements: benefit, penalty, cost, risk, dependencies, time sensitivity, stability and regulatory or policy compliance.
- Remember
- The basis should be agreed with stakeholders before ranking, ideally in the governance approach.
- Tested as
- Priority conflict scenarios expect you to apply an agreed basis, not to decide yourself.
- Trap
- Prioritizing by who shouts loudest or by the highest-ranking requester.
-
MoSCoW
A prioritization technique that sorts items into Must have, Should have, Could have and Won't have this time.
- Remember
- 'Won't' means not in this release, not never; Musts are reserved for items without which the solution fails.
- Tested as
- Frequently the technique offered when stakeholders call everything critical.
- Trap
- Allowing too many Musts, which defeats the purpose.
-
Impact analysis
Assessment of a proposed change's effect on benefit, cost, schedule, urgency and related requirements, designs and components.
- Remember
- Traceability is what makes impact analysis fast and complete.
- Tested as
- The first action in most change scenarios.
- Trap
- Skipping it for small or senior-requested changes.
-
Change control process
The governance rules, defined in Domain 1, for requesting, analyzing, authorizing and recording changes.
- Remember
- Assess Requirements Changes operates within it; the business analyst does not invent a process mid-change.
- Tested as
- Correct answers in change scenarios reference the agreed process.
- Trap
- Accepting a change directly because the requester has authority over the budget.
-
Requirements reuse
Using maintained requirements, often at a higher level of abstraction, across initiatives or by ongoing operations.
- Remember
- Requirements must be identified, named, defined and stored so others can find them.
- Tested as
- Repeated re-elicitation of the same rules signals a reuse opportunity.
- Trap
- Assuming requirements end their life when a project closes.
-
Requirements states in the life cycle
BABOK outputs describe requirements moving through states such as traced, maintained, prioritized and approved, with change assessments along the way.
- Remember
- States describe what has happened to a requirement, not a fixed sequence of phases.
- Tested as
- Questions ask what state a requirement must reach before the next activity.
- Trap
- Believing approval freezes a requirement permanently.
-
Conflict and issue management
Part of Approve Requirements: resolving disagreements among stakeholders so approval can proceed.
- Remember
- Facilitate resolution and consensus first, and escalate through the governance approach only when needed.
- Tested as
- Approval-stall scenarios test whether you resolve conflict or bypass it.
- Trap
- Getting one approver to sign to move forward while the dispute remains open.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Derive vs. depends vs. satisfy vs. validate
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Derive | A requirement is elaborated from another requirement | Connects levels of abstraction | Calling it depends because one came from the other |
| Depends | One requirement relies on another, by necessity or effort | Affects implementation order and feasibility | Overlooking effort dependencies in sequencing |
| Satisfy | An implementation element fulfills a requirement | Links requirements to components or designs that implement them | Confusing it with test evidence |
| Validate | A test or other evidence confirms the requirement is met | Links requirements to verification evidence in the solution | Confusing it with the Validate Requirements task in Domain 5 |
Assess Requirements Changes vs. Approve Requirements
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Assess Requirements Changes | Analyze impact of a proposed change on benefit, cost, schedule and urgency | Produces information for a decision | Treating the assessment as the decision itself |
| Approve Requirements | Obtain agreement from authorized stakeholders and record it | Produces a decision under the governance approach | Expecting the business analyst to be the approver |
Priority vs. sequence
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Priority | Relative importance based on an agreed basis such as benefit or penalty | Reflects value to stakeholders | Assuming the highest-priority item is always built first |
| Sequence | Order of implementation | Driven by priority plus dependencies, risk and capacity | Ignoring a necessity dependency that forces a lower-value item earlier |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Implementing the senior request
- What candidates pick
- Adding a change immediately because the requester is an executive.
- Why it looks right
- Authority and urgency make it look like the decision is already made.
- Why it's wrong
- Changes are assessed under the governance approach; seniority does not replace impact analysis or authorized approval.
Clue to watch for A late change from a powerful stakeholder with no mention of analysis signals Assess Requirements Changes.
-
Rejecting because scope is frozen
- What candidates pick
- Declining any change after the baseline.
- Why it looks right
- Scope control sounds disciplined.
- Why it's wrong
- The business analyst does not reject changes unilaterally; impact is assessed and the authorized stakeholders decide.
Clue to watch for Answers that refuse without analysis are as wrong as answers that accept without analysis.
-
Letting the loudest voice prioritize
- What candidates pick
- Ranking requirements by the requester's rank or persistence.
- Why it looks right
- Senior stakeholders control funding.
- Why it's wrong
- Priority should follow an agreed basis such as benefit, penalty, cost, risk and dependencies.
Clue to watch for If stakeholders disagree and no basis is mentioned, the answer establishes or applies one.
-
Ignoring dependencies
- What candidates pick
- Building the highest-value requirement first even though it relies on another.
- Why it looks right
- Value first is the usual principle.
- Why it's wrong
- A necessity dependency means the high-value item cannot function without its prerequisite.
Clue to watch for Look for phrases like 'cannot work until' or 'relies on' in the stem.
-
Tracing for its own sake
- What candidates pick
- Establishing full traceability for every artifact on a small, low-risk initiative.
- Why it looks right
- Complete traceability sounds like best practice.
- Why it's wrong
- Traceability formality should be proportionate to value, complexity and regulatory need as planned in the information management approach.
Clue to watch for Small scope, low risk and no regulation point to lightweight tracing.
-
One signature solves conflict
- What candidates pick
- Getting the sponsor's sign-off while two departments still disagree.
- Why it looks right
- The sponsor has authority, so the dispute seems settled.
- Why it's wrong
- Approve Requirements includes conflict and issue management and gaining consensus; unresolved disputes resurface as rework or change requests.
Clue to watch for If the stem mentions ongoing disagreement, look for the option that resolves it.
Answer framework
Use these steps when a scenario involves changing, ranking, tracing or approving requirements.
- Identify which life cycle task the stem is really about: tracing, maintaining, prioritizing, assessing a proposed change or obtaining approval, and note the delivery approach in use.
- Check what the governance and information management approaches already define for this situation, and plan to follow them rather than improvising.
- For any proposed change, use traceability to analyze its impact on benefit, cost, schedule, urgency and related requirements and designs.
- For priorities, apply an agreed basis and surface dependencies, regulatory penalties, time sensitivity and risk before facilitating a ranking with the stakeholders involved.
- Leave decisions with the authorized stakeholders, resolve open conflicts before seeking sign-off, and record, maintain and communicate every outcome.
Practice question
Want more like this? The CBAP practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study Trace Requirements first, because the four relationships and the purpose of traceability underpin change assessment. Then learn Maintain Requirements, Prioritize Requirements, Assess Requirements Changes and Approve Requirements, always reading them alongside the governance and information management approaches from Domain 1.
The high-priority concepts are the traceability relationships, the bases for prioritization and the sequence of analysis before decision in change scenarios. Candidates commonly underestimate Maintain Requirements and reuse, and they overestimate how much latitude the business analyst has to decide. Adaptive-context questions are also tricky: backlog refinement is still prioritization, and story acceptance is still approval.
After reading, practice with change-request scenarios and force yourself to state the first step and who decides. Then drill relationship identification with short pairs of requirements until you can label them instantly. Finally, mix in Domain 5 questions, since many case-study items move between specifying a requirement and managing its approval or change.
FAQ
How much of the CBAP exam is Requirements Life Cycle Management?
IIBA's blueprint weights it at 15%. As a planning estimate that is about 18 of the 120 questions.
What are the four traceability relationships?
Derive, depends (with necessity and effort subtypes), satisfy and validate. Derive links levels of requirements, depends affects order, satisfy links implementation, and validate links test evidence.
Does Requirements Life Cycle Management end when the project ends?
No. The life cycle runs until a requirement is retired, and maintained requirements can be reused by later initiatives or ongoing operations.
Who decides whether a change is accepted?
The stakeholders authorized in the governance approach. The business analyst assesses the impact and facilitates the decision.
How is prioritization different in an adaptive approach?
It is continuous, usually through backlog management, and revisited as learning occurs. The bases for prioritization still apply.
Which other domains should I study with this one?
Domain 1 for the governance and information management approaches it executes, and Domain 5 for the specification and verification of the requirements it manages.
How much study time does this domain need?
As a planning estimate, about 25 to 30 hours within a 180-hour plan. Spend it on scenario practice rather than memorizing lists.
Other Business Analysis certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered tracing, maintaining, prioritizing, assessing changes and approving requirements under the governance approach. Practice questions will show whether you analyze before deciding when a senior stakeholder pushes a change.