Overview
Planning covers six tasks that set up the business analysis approach before detailed analysis begins: reviewing the business case and project goals for context, defining the requirements traceability strategy, developing the requirements management plan, selecting methods for requirements change control and for document control, and defining business metrics and acceptance criteria with stakeholders.
Candidates must understand that these are tailoring decisions, not paperwork. A regulated, predictive project might need full bidirectional traceability, a formal change control board and strict versioning, while an adaptive team might trace user stories to features in a backlog tool and handle change through backlog refinement. The plan names roles, approval authority and communication protocols. Domain 4 executes the traceability and change rules set here, Domain 3 follows the elicitation and approval methods, and Domain 5 uses the acceptance criteria and business metrics defined at this stage.
How it's tested
Planning questions describe a project context, such as its industry, regulation, team size or delivery approach, and ask which plan element, traceability level or control method is MOST appropriate. Others present a problem mid-project, such as unapproved changes or conflicting document versions, and ask which planning artifact should have prevented it or what the analyst should consult first.
-
Tailor to context
The stem gives clues such as a regulated medical device or a small internal agile team, and you choose the traceability depth or control formality that fits.
-
Which plan component
A recurring issue appears, such as nobody knowing who approves requirements, and you identify the requirements management plan element that defines it.
-
Consult the plan first
A change request or approval question arises, and the right first step is to follow the process already defined in the change control or requirements management plan.
A pharmaceutical company's lab system must pass regulatory audit. Options offer lightweight story mapping, forward-only tracing to design, full bidirectional tracing from business objectives through test cases, or no formal tracing until testing. Regulators need to see that each requirement was implemented and verified, and that each test traces to a need. Only bidirectional traceability across the lifecycle provides that evidence, so it is the best fit.
Tasks 6
Official tasks from the PMI outline, in outline order.
2.1 Review the business case, and the project goals and objectivesGround business analysis planning in why the project exists.
- What it means
- Before planning business analysis activities, the analyst reviews the business case and the project goals and objectives so the approach, effort and level of rigor fit the purpose of the initiative.
- What to understand
- The business case tells you the value proposition, constraints and risks, which shape how formal the requirements process must be. If the case or objectives have changed since Needs Assessment, planning must reflect the current version.
- How it shows up
- A new analyst joins mid-initiation and asks what to review before planning; the answer is the business case and project goals and objectives.
- Common confusion
- Treating this as re-doing needs assessment, when the purpose here is to set context for planning, not to re-analyze the problem.
2.2 Define strategy for requirements traceabilityDecide how much traceability the project needs.
- What it means
- The analyst uses traceability tools and techniques to decide what will be traced (objectives, requirements, design, tests), in which directions, and in what tool, to establish the level of traceability needed to monitor and validate requirements.
- What to understand
- Traceability can be forward (requirement to design, build and test), backward (requirement to its source and objective) or bidirectional. More traceability costs effort, so depth is set by regulation, risk, complexity and the delivery approach.
- How it shows up
- A scenario describes a regulated or high-risk project and asks for the appropriate traceability strategy.
- Common confusion
- Assuming maximum traceability is always best, or confusing the strategy (decided here) with the traceability matrix maintained in Domain 4.
2.3 Develop requirements management planSet the roadmap for how requirements are handled.
- What it means
- The plan identifies stakeholders, roles and responsibilities, communication protocols, and the methods for eliciting, analyzing, documenting, managing and approving requirements, to establish a roadmap for delivering the expected solution.
- What to understand
- Typical contents include the business analysis approach (predictive, adaptive or hybrid), RACI for requirements activities, approval authority, prioritization method, traceability approach, configuration and change management, and requirement attributes to capture. It is a component of the project management plan.
- How it shows up
- A question lists a problem, such as conflicting sign-off expectations, and asks which plan element should address it.
- Common confusion
- Confusing the requirements management plan with the requirements documentation itself, or with the project manager's scope management plan.
2.4 Select methods for requirements change controlDefine how requirement changes are requested, assessed and decided.
- What it means
- The analyst identifies channels for submitting change requests and the process for assessing and deciding them, establishing standard protocols that are incorporated into the project's change management plan.
- What to understand
- A sound method defines who may request a change, how impact is analyzed, who decides (often a change control board for baselined requirements), and how decisions are communicated and recorded. In adaptive approaches, new or changed items usually go to the product backlog and the product owner reprioritizes.
- How it shows up
- A stakeholder asks a developer directly to add a feature; the question asks what method should have been in place or what the analyst does now.
- Common confusion
- Thinking the analyst approves changes; the analyst assesses impact and facilitates, while the designated authority decides.
2.5 Select methods for document controlChoose versioning and storage standards for requirements artifacts.
- What it means
- The analyst selects documentation management tools and techniques, such as a repository, naming conventions, version numbering, access rights and check-in rules, to establish a standard for requirements traceability and versioning.
- What to understand
- Document control keeps one authoritative, versioned set of requirements so teams build and test against the same baseline. It is about managing the artifacts, while change control is about deciding whether the content may change.
- How it shows up
- Developers and testers are working from different versions of a specification, and you choose the control that prevents it.
- Common confusion
- Treating document control and change control as the same process.
2.6 Define business metrics and acceptance criteriaAgree up front how success will be judged.
- What it means
- In collaboration with stakeholders, the analyst defines business metrics (measures tied to objectives, such as order cycle time) and acceptance criteria that will be used to evaluate when the solution meets the requirements.
- What to understand
- Metrics and criteria defined during planning are high-level and tied to the business case; Domain 3 later elaborates them into detailed, testable criteria per requirement. Agreeing them early prevents disputes at sign-off.
- How it shows up
- A sponsor and users disagree at go-live about whether the solution succeeded; the question asks what should have been defined during planning.
- Common confusion
- Mixing this task with task 3.8, which elaborates detailed metrics and acceptance criteria during analysis.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Requirements management plan
A subsidiary of the project management plan that describes how requirements will be elicited, analyzed, documented, prioritized, approved, traced and changed, and by whom.
- Remember
- It defines roles, approval authority, communication protocols and the business analysis approach, so most process disputes are settled by checking it.
- Tested as
- Many questions describe confusion over who approves or how requirements are handled, and the answer points to this plan.
- Trap
- Mistaking it for the requirements document or for a project schedule.
-
Traceability strategy
The decision about what artifacts to link, in which directions, at what granularity, and with which tool.
- Remember
- Depth of traceability is chosen deliberately based on regulation, risk, complexity and approach, because every link costs effort to maintain.
- Tested as
- Stems give a context and ask for the right level of traceability.
- Trap
- Picking full traceability for a small, low-risk internal change where it adds cost without benefit.
-
Bidirectional traceability
Tracing backward from a requirement to its source and objective and forward to design, code and test cases.
- Remember
- Backward tracing proves every requirement has a business reason; forward tracing proves every requirement was built and tested.
- Tested as
- The expected choice when the stem mentions audits, regulation or safety.
- Trap
- Choosing forward-only tracing, which cannot reveal gold plating or orphan requirements.
-
Change control board (CCB)
A designated group that reviews and approves or rejects changes to baselined requirements and other controlled items.
- Remember
- The analyst analyzes impact and presents it, and the board or designated authority makes the decision.
- Tested as
- Questions ask who decides on a change or what the analyst does after receiving a request.
- Trap
- Choosing an answer where the analyst or developer approves the change on the spot.
-
Requirements change control vs. integrated change control
Requirements change protocols are defined by the analyst and incorporated into the project's overall change management plan.
- Remember
- Requirement changes that affect scope, schedule or cost go through the project's integrated change control.
- Tested as
- Tests whether you see the analyst's change methods as part of, not separate from, project change management.
- Trap
- Designing a separate, competing change process for requirements.
-
Document control and versioning
Standards for where requirements artifacts live, how they are named and versioned, who can edit them, and how releases are marked.
- Remember
- Version control prevents teams from working against different copies of the same requirements.
- Tested as
- Appears when testers or developers use outdated specifications.
- Trap
- Answering with a change control step when the problem is uncontrolled document versions.
-
Requirement attributes
Metadata recorded for each requirement, such as unique ID, source, owner, priority, status, version, complexity and acceptance criteria.
- Remember
- Attributes are chosen during planning so tracking and status reporting in Domain 4 are possible.
- Tested as
- Questions ask which attribute should be captured to support a later activity, such as source for backward tracing.
- Trap
- Forgetting that the source attribute is what lets you trace a requirement back to the stakeholder who raised it.
-
Predictive vs. adaptive planning
Predictive approaches baseline requirements early and control change formally; adaptive approaches elaborate requirements progressively in a backlog.
- Remember
- Both need planning, but adaptive plans are lighter and rely on backlog refinement and the product owner for change decisions.
- Tested as
- Stems mention sprints, a product owner or a fixed regulatory scope to signal which approach applies.
- Trap
- Applying a formal change control board to every backlog change in an adaptive team.
-
Business metrics
Measures linked to business objectives, such as cost per transaction or customer retention rate, used to judge whether the solution delivers value.
- Remember
- Metrics need a baseline and a target, set with stakeholders before the solution is built.
- Tested as
- Appear when the question asks how the organization will know whether the investment paid off.
- Trap
- Choosing technical measures such as server uptime when the question asks about business value.
-
Acceptance criteria
Conditions the solution must satisfy for stakeholders to accept it.
- Remember
- Planning defines them at a high level with stakeholders; analysis elaborates them per requirement into testable criteria.
- Tested as
- Questions about go-live disputes trace back to criteria that were never agreed.
- Trap
- Leaving acceptance criteria for testers to define after development.
-
RACI matrix
A chart that assigns who is responsible, accountable, consulted and informed for each requirements activity.
- Remember
- Only one person is accountable per activity, which is how approval authority is made clear.
- Tested as
- Used as the answer when confusion exists over who signs off or who must be consulted.
- Trap
- Assigning more than one accountable party to the same decision.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Change control vs. document control
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Requirements change control | Process for requesting, analyzing, deciding and communicating changes to requirements | Governs whether content may change and who decides | Using it to fix a versioning problem |
| Document control | Standards for storing, naming, versioning and accessing requirements artifacts | Governs which copy is authoritative | Assuming good versioning means changes are approved |
Forward vs. backward vs. bidirectional traceability
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Forward | From requirement to design, build and test | Shows every requirement was delivered and verified | Thinking it also justifies why the requirement exists |
| Backward | From requirement to its source, objective or business need | Shows every requirement has a business reason and reveals gold plating | Assuming it proves the requirement was tested |
| Bidirectional | Both directions across the lifecycle | Full coverage, highest effort; suits regulated or high-risk work | Choosing it for every project regardless of cost |
Requirements management plan vs. requirements documentation vs. traceability matrix
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Requirements management plan | How requirements work will be done and governed | Process and roles, written in Planning | Expecting it to list the requirements |
| Requirements documentation | The requirements themselves, in specifications or a backlog | Content, produced in Analysis | Treating it as the place where approval authority is defined |
| Traceability matrix | Grid or tool linking requirements to sources, design and tests | Relationships and status, maintained in Traceability and Monitoring | Confusing the matrix with the strategy that decides its depth |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Always trace everything
- What candidates pick
- Full bidirectional traceability at the finest level of detail for every project.
- Why it looks right
- More traceability sounds safer and more rigorous.
- Why it's wrong
- The task is to establish the level of traceability needed; on a small, low-risk internal change, exhaustive tracing costs more than it protects.
Clue to watch for The stem describes a short, low-risk, internal or adaptive effort with no audit requirement.
-
Analyst approves the change
- What candidates pick
- The analyst evaluates a change request and approves it because the impact is small.
- Why it looks right
- The analyst understands the requirement and the impact best.
- Why it's wrong
- The analyst assesses impact and facilitates; decisions on baselined requirements belong to the authority named in the change control process, such as a change control board or product owner.
Clue to watch for The requirement is already baselined, and the question asks who decides or what happens next.
-
Versioning problem solved with change control
- What candidates pick
- Submit a change request when testers are using an old specification.
- Why it looks right
- Anything involving requirement differences feels like a change issue.
- Why it's wrong
- Nothing changed in the approved content; the team lacks a single controlled version, which is a document control failure.
Clue to watch for The approved requirement is fine, but different groups hold different copies.
-
Separate requirements change process
- What candidates pick
- Create a standalone requirements change process run only by the analyst.
- Why it looks right
- It seems to give business analysis clear ownership.
- Why it's wrong
- The ECO says requirements change protocols are incorporated into the change management plan, so changes affecting cost, schedule or scope pass through integrated project change control.
Clue to watch for The change affects budget or schedule as well as requirements.
-
Acceptance criteria later
- What candidates pick
- Let the test team define acceptance criteria after the solution is built.
- Why it looks right
- Testers know how to write test conditions.
- Why it's wrong
- Business metrics and acceptance criteria are defined with stakeholders during planning so success is agreed before work starts; defining them afterward invites disputes.
Clue to watch for A sign-off disagreement where nobody agreed beforehand what success looked like.
-
Heavy controls in an adaptive team
- What candidates pick
- Route every backlog change through a formal change control board.
- Why it looks right
- Formal control feels like good governance.
- Why it's wrong
- In adaptive approaches the product owner reprioritizes the backlog as the change mechanism; formal boards are reserved for baselined, contractual or regulated items.
Clue to watch for The stem mentions sprints, a product owner and an evolving backlog.
Answer framework
When a Planning question asks what to set up or which control fits, work through these steps.
- Read the context clues first: regulation, risk, team size, contract type and whether the approach is predictive, adaptive or hybrid.
- Match traceability depth and direction to that context, choosing bidirectional tracing for audited or safety work and lighter links elsewhere.
- Identify which requirements management plan element covers the issue, such as roles, approval authority, communication protocols or prioritization method.
- Separate content changes, which go through change control and the designated decision authority, from version confusion, which document control solves.
- Confirm business metrics and acceptance criteria were agreed with stakeholders up front, and choose the answer that establishes them before building starts.
Practice question
Want more like this? The PMI-PBA practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study Planning right after Needs Assessment, because its first task reviews the business case you just learned to build. Begin with the requirements management plan: list its components from memory and, for each, name a project problem it prevents. That exercise is close to how the exam asks about the plan.
Next, master traceability strategy. Draw the forward, backward and bidirectional directions on paper and match each to the evidence it produces. Then practice tailoring: for a medical device, a marketing website and a sprint-based internal tool, decide how much traceability and change formality each needs and why.
Candidates commonly underestimate the difference between change control and document control, and between the planning-level acceptance criteria in task 2.6 and the detailed criteria in task 3.8. Write a one-line rule for each pair and test yourself until the distinction is automatic.
Afterward, practice scenario questions that ask which plan element was missing or which control fits. When you miss one, identify the context clue you overlooked. Then move to Domain 3, where the methods you planned are used to elicit, analyze and approve requirements.
FAQ
How much of the PMI-PBA exam is Planning?
Planning is 22% of the exam by PMI's weighting. That works out to roughly 44 of 200 items as a planning estimate; PMI does not publish exact per-domain counts.
What goes into a requirements management plan?
Roles and responsibilities, communication protocols, and the methods for eliciting, analyzing, documenting, prioritizing, approving, tracing and changing requirements. It usually also states the business analysis approach and the requirement attributes to capture.
Who owns the requirements management plan?
The business analyst typically develops it, and it becomes a subsidiary component of the project management plan that the project manager integrates. Approval follows the project's governance.
How do I decide how much traceability is enough?
Match it to regulation, risk, complexity and delivery approach. Audited or safety-critical work justifies bidirectional tracing to tests, while small, low-risk efforts can trace more lightly.
What is the difference between change control and document control?
Change control decides whether requirement content may change and who approves it. Document control makes sure everyone works from the same authoritative, versioned copy.
Are acceptance criteria defined in Planning or Analysis?
Both. Planning defines business metrics and high-level acceptance criteria with stakeholders, and Analysis elaborates them into detailed, measurable criteria for individual requirements.
Does Planning look different on agile projects?
The tasks still apply but are lighter. Traceability may live in the backlog tool, and change is handled by the product owner reprioritizing the backlog rather than by a formal board.
Other Business Analysis certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have covered the requirements management plan, traceability strategy, change and document control, and early acceptance criteria. Test whether you can match each control to the project context a question describes.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the PMI-PBA AI tutor Get any concept explained your way