PMI-PBA — PMI Professional in Business Analysis Quick Reference

Last revised: June 29, 2026

Compact PMI-PBA business analysis reference for exam preparation: roles, artifacts, elicitation, requirements, traceability, change control, and solution evaluation.

Exam Identity and How to Use This Page

This Quick Reference supports candidates preparing for the PMI Professional in Business Analysis (PMI-PBA) exam from PMI, exam code PMI-PBA. It is independent review support focused on practical scenario reasoning: what a business analyst should produce, analyze, validate, trace, escalate, or recommend.

Use it to review:

Business analysis lifecycle flow.
Requirements elicitation, analysis, validation, and management.
Stakeholder and governance decisions.
Traceability, change control, prioritization, and solution evaluation.
Common PMI-PBA scenario traps.

Business Analysis Lifecycle Map

    flowchart LR
	    A[Needs assessment] --> B[BA planning]
	    B --> C[Elicitation]
	    C --> D[Analysis and modeling]
	    D --> E[Validation and approval]
	    E --> F[Traceability and monitoring]
	    F --> G[Solution evaluation]
	    G --> H[Benefits and lessons learned]
	    F --> C
	    E --> D
	    G --> A

High-yield exam idea: business analysis is iterative even on predictive projects. A PMI-PBA scenario rarely rewards “write the requirements once and move on.” Expect ongoing clarification, validation, change assessment, and traceability.

PMI-PBA Domain Reference

Area	Core question	Typical BA outputs	Exam focus
Needs assessment	Why is a change needed?	Business case inputs, problem/opportunity statement, current-state assessment, recommended solution approach	Link solution to business need and value
Planning	How will BA work be performed?	BA plan, stakeholder engagement approach, elicitation plan, requirements management plan, traceability approach	Tailoring, governance, roles, approvals
Analysis	What does the solution need to do?	Requirements, models, acceptance criteria, assumptions, constraints, prioritization results	Quality, completeness, conflicts, feasibility
Traceability and monitoring	Are requirements controlled and aligned?	Requirements traceability matrix, change impact analysis, status reporting	Scope control, change control, dependency management
Evaluation	Did the solution deliver value?	Evaluation results, performance metrics, lessons learned, transition feedback	Benefits realization, acceptance, operational fit

Role	Primary concern	Typical decisions	Common trap
Business analyst	Needs, requirements, stakeholder value, solution fit	Elicitation method, requirements quality, traceability, impact analysis	Acting as the sponsor or project manager
Project manager	Delivery constraints, schedule, cost, resources, risks	Project plan, team coordination, issue escalation	Treating requirements decisions as purely schedule decisions
Sponsor	Business authority, funding, strategic alignment	Approve business case, resolve major business conflicts	BA approves benefits or funding alone
Product owner	Product value, backlog ordering, user acceptance direction	Prioritize backlog, accept increments	BA bypasses product owner in agile prioritization
Subject matter expert	Domain knowledge	Validate facts, rules, process details	SME preference treated as enterprise requirement
End user	Usability and operational need	Provide feedback, validate workflow fit	One user’s opinion becomes the full user requirement
Architect/technical lead	Technical feasibility and design constraints	Solution design options, nonfunctional feasibility	BA dictates technical design instead of requirements

Requirements Hierarchy

Level	Meaning	Example	Exam clue
Business requirement	High-level business objective or outcome	Reduce claims processing time	Connected to strategy, benefits, or business case
Stakeholder requirement	Need of a stakeholder group	Claims adjusters need to see missing documents	Often elicited from groups or personas
Solution requirement	Capability or quality of the solution	System shall flag incomplete claims	Functional or nonfunctional specification
Functional requirement	Behavior or function	Generate approval notification	Verb-based capability
Nonfunctional requirement	Quality, constraint, or performance attribute	Response time under defined load	Often missed, testable with metrics
Transition requirement	Temporary capability needed to move to future state	Migrate open claims to new system	Exists only during transition
Assumption	Believed true for planning	Vendor API will remain available	Must be monitored or validated
Constraint	Limitation or boundary	Must comply with existing platform standards	Restricts solution options

Requirements Quality Checklist

A strong requirement is:

Attribute	Test question
Clear	Would two readers interpret it the same way?
Concise	Is unnecessary wording removed?
Feasible	Can it be delivered within known constraints?
Necessary	Does it support a business or stakeholder need?
Testable	Can acceptance or verification be objectively shown?
Unambiguous	Are vague words like fast, easy, robust, and user-friendly quantified?
Consistent	Does it conflict with another requirement?
Traceable	Can it be linked to source, objective, design, test, and release?
Prioritized	Is relative importance known?
Approved	Has the correct authority accepted it?

Elicitation Technique Selection

Situation	Best-fit technique	Why it fits	Watch for
Many stakeholders need shared understanding	Facilitated workshop	Builds consensus quickly	Dominant voices, unclear agenda
Need deep knowledge from one expert	Interview	Allows probing and clarification	SME bias, incomplete perspective
Need broad input from many people	Survey/questionnaire	Efficient for dispersed groups	Poor question design, low response rate
Need to understand actual work	Observation/job shadowing	Reveals workarounds and tacit knowledge	Hawthorne effect: behavior changes when observed
Need to evaluate user interface ideas	Prototype	Makes abstract needs concrete	Stakeholders mistake prototype for final design
Need creative solution ideas	Brainstorming	Encourages divergent thinking	Jumping to evaluation too soon
Need process details and handoffs	Document analysis + process modeling	Uses existing evidence	Existing documents may be outdated
Need root cause of a business problem	Root cause analysis	Separates symptoms from causes	Solving the symptom
Need interface or system behavior	Interface analysis	Clarifies data exchange and boundaries	Ignoring error handling and nonfunctional needs
Need agile backlog refinement	Collaborative backlog workshop	Aligns product owner, team, and stakeholders	Skipping acceptance criteria

Stakeholder Analysis and Engagement

Tool or concept	Use it to answer	Key output
Stakeholder register	Who is affected or influential?	Names, roles, interests, influence, expectations
Power/interest grid	How should stakeholders be engaged?	Engagement strategy by stakeholder group
RACI or responsibility matrix	Who does, approves, consults, or receives information?	Reduced role ambiguity
Personas	What are user goals and behaviors?	User-centered requirements
Journey map	What does the user experience across steps?	Pain points and improvement opportunities
Stakeholder engagement assessment	Is current engagement sufficient?	Engagement gaps and actions
Communication plan	What information goes to whom and when?	Consistent BA communication

Stakeholder Engagement Decision Table

Scenario clue	What the BA should usually do next
Stakeholder conflict over requirement priority	Facilitate decision using agreed prioritization criteria; escalate only if governance threshold is reached
Key stakeholder unavailable	Follow engagement plan, use alternate sources, document risk, and escalate if decisions are blocked
Stakeholder requests solution before problem is understood	Return to needs assessment and define the problem/opportunity
One department dominates requirements	Validate with other impacted groups and analyze enterprise impact
Sponsor asks to skip user validation	Explain risk, recommend appropriate validation, and document decision if authority overrides
Users reject delivered feature	Compare feature to validated requirements and acceptance criteria; assess gap and change need

Planning Artifacts

Artifact	Purpose	High-yield contents
Business analysis plan	Defines how BA work will be performed	Approach, activities, timing, deliverables, roles
Requirements management plan	Defines how requirements are handled	Attributes, approval, baselines, change process, traceability
Elicitation plan	Prepares elicitation activities	Objectives, participants, techniques, questions, logistics
Stakeholder engagement plan	Guides stakeholder involvement	Engagement needs, communication, influence, resistance
Traceability approach	Defines how links are maintained	Traceability levels, tools, attributes, reporting
Communication approach	Structures BA information flow	Audience, format, frequency, escalation
Governance approach	Clarifies decisions and authority	Approval bodies, thresholds, change control, escalation

Exam trap: planning does not mean creating excessive documentation. PMI-PBA questions often reward tailoring the BA approach to project complexity, risk, stakeholder distribution, compliance needs, and lifecycle.

Analysis and Modeling Reference

Model	Best used for	Key exam distinction
Process flow	Activities, decisions, handoffs	Shows how work moves through a process
Data flow diagram	Movement of data between processes/entities	Focuses on data movement, not timing
Entity relationship diagram	Data entities and relationships	Supports data requirements
Context diagram	System boundary and external actors	Good early scope clarification tool
Use case	Actor-system interaction to achieve goal	Captures user-visible behavior
User story	Agile expression of user need	Should include acceptance criteria
State diagram	Object lifecycle and state transitions	Useful when status changes drive behavior
Decision table	Complex business rules	Clarifies combinations of conditions/actions
Decision tree	Sequential decisions or branches	Useful for rule paths and outcomes
Interface model	System-to-system or user interface needs	Defines inputs, outputs, protocols, constraints
Business capability model	What the business must be able to do	Stable view, less tied to process details
SWOT analysis	Strengths, weaknesses, opportunities, threats	Strategic context, not detailed requirements
Root cause analysis	Underlying cause of problem	Prevents treating symptoms as requirements

Requirements Documentation Formats

Format	Use when	Strength	Limitation
Formal requirements specification	Predictive, regulated, contractual, high-risk work	Detailed baseline and approval control	Can be slow and hard to adapt
User stories	Agile or iterative delivery	Lightweight and value-focused	Incomplete without conversations and acceptance criteria
Use cases	Interaction-heavy systems	Captures flows, alternatives, exceptions	Can become too detailed if misused
Backlog	Incremental product delivery	Enables ordering and refinement	Needs active product ownership
Models plus notes	Complex process/data/rule situations	Improves shared understanding	Must be maintained with requirements
Prototype annotations	UI/UX-heavy work	Makes needs visible	Prototype may be mistaken for final design

User Story and Acceptance Criteria Quick Check

Typical user story structure:

As a [role], I want [capability], so that [business value].

Acceptance criteria should define objective conditions for acceptance.

Weak criterion	Better criterion
System is fast	Search results display within the agreed response-time threshold under defined load
User can upload files	User can upload permitted file types up to the approved size limit and receives an error for invalid files
Report is accurate	Report totals match approved calculation rules and source data for the selected period
Screen is easy to use	User completes the defined task without assistance during usability validation

Validation vs Verification

Concept	Core question	Performed on	Example
Requirements validation	Are these the right requirements?	Requirements and models	Stakeholders confirm requirements meet business need
Requirements verification	Are the requirements well formed?	Requirement statements	BA checks clarity, consistency, testability
Solution validation	Does the solution meet stakeholder/business needs?	Built or configured solution	Users validate workflow supports work
Solution verification	Was the solution built according to specification?	Deliverable or increment	Test confirms feature matches requirement

Common trap: testing a completed solution does not replace validating requirements earlier.

Prioritization Methods

Method	Best use	How it works	Watch for
MoSCoW	Fast stakeholder sorting	Must, Should, Could, Won’t	Too many items labeled Must
Weighted scoring	Compare options objectively	Score options against weighted criteria	Weights must be agreed first
Kano model	Understand customer satisfaction	Basic, performance, excitement attributes	Basic needs may not delight but are essential
100-point allocation	Force trade-offs	Stakeholders distribute limited points	Dominant stakeholder influence
Pairwise comparison	Rank many items	Compare two at a time	Time-consuming for large sets
Cost of delay	Sequence by economic impact of delay	Higher delay cost gets attention	Requires credible value assumptions
Risk/value matrix	Balance value against uncertainty	Prioritize high-value, risk-aware items	Do not ignore dependencies
Minimum viable product thinking	Identify smallest valuable release	Focus on validated learning/value	MVP is not low quality or incomplete work

Useful Business Value Formulas

Use calculations when a scenario provides numbers and asks for a financially or risk-informed recommendation.

\[ ROI = \frac{Total\ Benefits - Total\ Costs}{Total\ Costs} \times 100 \]\[ Benefit\text{-}Cost\ Ratio = \frac{Total\ Benefits}{Total\ Costs} \]\[ Expected\ Monetary\ Value = Probability \times Impact \]\[ Weighted\ Score = \sum_{i=1}^{n}(Weight_i \times Rating_i) \]

Formula	Use for	Interpretation
ROI	Compare return relative to cost	Higher positive ROI is generally better
Benefit-cost ratio	Compare benefits to costs	Greater than 1 means benefits exceed costs
EMV	Quantify risk or opportunity exposure	Sum EMVs to compare alternatives
Weighted score	Compare options across multiple criteria	Highest score wins only if criteria and weights are valid

Traceability and Monitoring

Traceability links requirements backward to business need and forward to design, build, test, release, and benefits.

Trace link	Purpose
Requirement to business objective	Confirms business alignment
Requirement to stakeholder/source	Supports clarification and approval
Requirement to model	Keeps analysis artifacts consistent
Requirement to design component	Supports impact analysis
Requirement to test case	Confirms verifiability
Requirement to defect	Shows quality and readiness issues
Requirement to release/increment	Supports scope and delivery planning
Requirement to benefit/metric	Supports evaluation after delivery

Requirements Traceability Matrix Fields

Field	Why it matters
Requirement ID	Unique reference for control
Description	Requirement summary
Type	Business, stakeholder, functional, nonfunctional, transition
Source	Stakeholder, document, regulation, strategy, process
Priority	Supports sequencing and trade-offs
Status	Draft, validated, approved, implemented, deferred, rejected
Owner	Accountability for clarification or approval
Acceptance criteria	Objective completion basis
Related requirement/dependency	Impact and sequencing
Test case link	Verification coverage
Change history	Control and audit trail

Change Control Decision Table

Scenario	Best BA response
Requested change affects approved/baselined requirements	Perform impact analysis and submit through change control
Requested change is clarification with no scope, cost, schedule, risk, or value impact	Update requirement documentation according to governance rules
Stakeholder bypasses the agreed process	Acknowledge request, document it, and route through the approved process
Change improves business value but affects schedule	Provide impact analysis; decision authority weighs trade-off
Change conflicts with business objective	Identify misalignment and recommend rejection or redefinition
Technical team says a requirement is infeasible	Analyze alternatives with technical input; update requirement or escalate decision
Product owner reprioritizes backlog in agile	Update backlog and communicate impacts; ensure acceptance criteria and dependencies remain clear
Regulatory or mandatory constraint changes	Assess impact immediately and escalate according to governance

High-yield principle: the BA usually does not unilaterally approve significant requirement changes. The BA analyzes impact, maintains traceability, and supports the authorized decision process.

Agile, Predictive, and Hybrid BA Distinctions

Topic	Predictive emphasis	Agile emphasis	Hybrid exam point
Requirements timing	More upfront elaboration and baseline	Progressive refinement	Tailor detail by risk and decision need
Change	Formal change control after baseline	Backlog reprioritization within governance	Impact analysis still matters
Documentation	Specifications, models, approvals	Stories, acceptance criteria, conversations	Enough documentation for shared understanding
Stakeholder feedback	Stage gates, reviews, sign-offs	Frequent demos and feedback loops	Feedback cadence should fit uncertainty
Traceability	Formal matrix often used	Lightweight links may be used	Regulated/high-risk work may need stronger traceability
Prioritization	Business case, scope baseline, governance	Product owner/backlog value	Decision authority must be clear
Validation	Formal reviews and approvals	Continuous validation	Validation is needed in both

What Should the BA Do Next?

Prompt clue	Likely best next action
Problem is unclear	Conduct needs assessment/root cause analysis
Solution requested before need is validated	Define business need and objectives first
Requirements conflict	Facilitate analysis with stakeholders and use agreed decision criteria
Missing stakeholder group discovered	Update stakeholder analysis and engagement approach
Requirement is vague	Clarify and make it measurable/testable
Requirement is not feasible	Analyze alternatives and constraints with appropriate experts
Requirement lacks business value	Trace to objective; consider deprioritizing or removing
Scope creep appears	Assess impact and follow change control
Testing finds a defect	Trace to requirement/test case and support defect resolution
Users reject solution	Compare to validated requirements and evaluate gap
Benefits not achieved	Analyze performance data, adoption, assumptions, and solution fit
Stakeholders disagree on acceptance	Refer to approved acceptance criteria; facilitate resolution

Solution Evaluation

Evaluation focus	Questions to ask	Evidence
Business objective achievement	Did the solution solve the original problem?	KPI results, benefit measures
Requirements satisfaction	Were approved requirements met?	Test results, acceptance results
User adoption	Are intended users using the solution effectively?	Usage metrics, surveys, observation
Operational readiness	Can the organization sustain the solution?	Training, support, process readiness
Defect and issue trends	Are quality problems affecting value?	Defect reports, incident data
Process performance	Did cycle time, error rate, cost, or throughput improve?	Baseline vs actual metrics
Transition success	Were migration, training, and rollout effective?	Cutover results, support tickets
Unintended consequences	Did the solution create new problems?	Stakeholder feedback, performance analysis

Common Artifacts by Purpose

Purpose	Artifacts
Understand need	Problem statement, opportunity statement, current-state assessment, business case inputs
Plan BA work	BA plan, elicitation plan, requirements management plan, stakeholder engagement plan
Elicit information	Interview notes, workshop outputs, survey results, observation notes
Analyze requirements	Requirements specification, backlog, user stories, use cases, models, business rules
Validate agreement	Review records, approvals, acceptance criteria, sign-off evidence
Manage traceability	Traceability matrix, requirements attributes, change log
Control change	Change request, impact analysis, decision record
Support delivery	Prioritized backlog, release scope, test traceability
Evaluate solution	Metrics report, benefits assessment, lessons learned

High-Yield Distinctions

Distinction	Remember
Need vs requirement	Need explains why; requirement defines what is necessary to satisfy the need
Requirement vs design	Requirement states capability/constraint; design explains how to implement
Assumption vs constraint	Assumption is believed true; constraint is a known limitation
Business rule vs requirement	Rule governs behavior or decision logic; requirement may implement or enforce the rule
Validation vs verification	Validation asks “right thing?” verification asks “built/written right?”
Prioritization vs approval	Priority ranks importance; approval authorizes use
Baseline vs backlog	Baseline controls approved scope; backlog is ordered and refined over time
Defect vs change request	Defect fails agreed requirement; change request alters agreed requirement
Output vs outcome	Output is delivered product; outcome is business result
Benefit vs capability	Capability enables value; benefit is realized measurable value

Common PMI-PBA Scenario Traps

Choosing a solution before confirming the business problem.
Accepting one stakeholder’s preference as a requirement without validation.
Confusing project management escalation with business analysis decision facilitation.
Treating documentation as the goal instead of shared understanding and value.
Ignoring nonfunctional and transition requirements.
Skipping impact analysis because a change seems small.
Prioritizing by loudest stakeholder instead of agreed criteria.
Failing to trace requirements to business objectives.
Using agile as an excuse to avoid requirements discipline.
Assuming user acceptance means benefits were achieved.
Treating a prototype as a final specification without confirmation.
Resolving a governance issue without the proper decision authority.

Final Review Checklist

Before the exam, confirm you can quickly answer:

What business need or objective does this requirement support?
Who has authority to approve, prioritize, or change it?
Which elicitation technique best fits the scenario?
Is the issue a requirement defect, a solution defect, a change request, or a stakeholder conflict?
What analysis model would clarify the situation?
Are requirements clear, testable, feasible, and traceable?
Has impact been assessed before changing approved scope?
Are acceptance criteria objective?
Are solution results being compared to baseline measures and expected benefits?

Practical Next Step

Use this Quick Reference as a final-pass checklist, then move into timed PMI-PBA scenario practice. For each missed question, tag the miss by topic: needs assessment, planning, elicitation, analysis, traceability/change control, or evaluation. This will show whether you need more concept review or more scenario-decision practice.

Scenario Guide

Needs Assessment