PMI-PBA PMI Professional in Business Analysis Exam Topics and Questions

This topic sits at the front of the exam because it sits at the front of every initiative: identifying what the problem actually is, whether solving it is worth the cost, and who needs to be involved. The weight is substantial, and candidates who treat this as soft or obvious work pay for it.

– Problem definition and value proposition

You start by defining the business problem or opportunity, using problem and opportunity analysis to produce a solution scope statement and feed the business case. The exam expects you to distinguish between a symptom and a root cause, and to know when the scope statement is tight enough to be useful but not so prescriptive that it forecloses options. Next comes collecting and analyzing information to determine the value proposition. Valuation tools and techniques appear here, and the exam tests whether you can articulate why an initiative is worth pursuing in terms that matter to the organization. The trap is confusing activity with value: delivering a feature is not the same as delivering a benefit.

– Goals, objectives, and stakeholder engagement

Collaborating on project goals and objectives means providing clarity on business needs and solution scope so the product aligns with organizational goals. The exam wants to see that you understand alignment as a two-way conversation, not a handoff. Identifying stakeholders follows: you review goals, objectives, and requirements to ensure the right parties are represented, informed, and involved. The skill being tested is completeness. Missing a stakeholder group at this stage creates gaps that cost marks later. Finally, you determine stakeholder values using elicitation techniques to establish a baseline for prioritizing requirements. The exam checks whether you can translate what people say they want into a structure that supports prioritization decisions.

How Needs Assessment is tested

Eighteen percent of the exam means roughly one question in five or six comes from this domain, so you will see it throughout the paper. Items typically present a scenario where the problem is poorly defined, stakeholders are unclear, or the value proposition is contested. You are asked to choose the next step or the correct technique. The demand is recognizing which tool fits the situation and what outcome it should produce. Candidates lose marks by choosing a response that sounds active but does not address the actual gap in the scenario. For example, selecting a technique that gathers more data when the real issue is that no one has agreed what problem is being solved. Another common error is treating stakeholder identification as a one-time event rather than an iterative activity tied to goals and requirements. The exam rewards precision in matching the task to the need.

Planning carries the second-heaviest weighting, and it earns that position by forcing you to make decisions about traceability, change control, and acceptance criteria before requirements work begins. The cost comes when you confuse planning with doing: the exam tests whether you know what to decide now and what to defer.

– Context and traceability strategy

Reviewing the business case and project goals provides context for all business analysis activities. The exam expects you to know what information you extract from the business case and how it shapes your approach. Defining a strategy for requirements traceability follows. You use traceability tools and techniques to establish the level of traceability needed to monitor and validate requirements. The exam tests whether you can match traceability depth to the initiative's complexity and risk. Over-engineering traceability on a small project wastes effort; under-engineering it on a regulated initiative creates compliance gaps. The skill is calibration, and the exam will present a scenario where the wrong level of traceability has been proposed.

– Requirements management and change control

Developing the requirements management plan means identifying stakeholders, roles, responsibilities, communication protocols, and methods for elicitation, analysis, documentation, management, and approval. The exam looks for completeness: a plan that omits approval methods or communication protocols is incomplete. Selecting methods for requirements change control involves identifying channels for requests and processes for managing changes, establishing protocols that feed into the change management plan. The trap is assuming change control is purely procedural. The exam rewards understanding that change control protects the baseline while allowing necessary evolution. Candidates who treat every change request as an interruption rather than information will choose the wrong response.

– Document control and acceptance criteria

Selecting methods for document control uses documentation management tools and techniques to establish standards for traceability and versioning. The exam tests whether you understand version control as a coordination mechanism, not just an archive. Defining business metrics and acceptance criteria involves collaboration with stakeholders to establish how you will evaluate whether the solution meets requirements. The exam expects you to know the difference between a metric and a target, and to recognize when acceptance criteria are vague enough to invite dispute later. Candidates lose marks by accepting criteria that sound reasonable but cannot be measured or verified.

How Planning is tested

At twenty-two percent, this is the second-largest topic by weight, so expect it to appear regularly and in combination with other domains. Items often describe a planning artifact that is missing a component or a scenario where the level of rigor is mismatched to the initiative. You are asked to identify what is missing or what should be adjusted. The demand is knowing what each plan must contain and why. Candidates lose marks by selecting responses that add process overhead without addressing the actual gap, or by choosing a lightweight approach when the scenario signals high complexity or regulatory constraint. Another common error is confusing the requirements management plan with the project management plan, or assuming that traceability strategy can be defined after requirements are already in flight. The exam rewards foresight: planning decisions are tested on their ability to prevent downstream problems, not on their compliance with a template.

Analysis dominates the exam at thirty-five percent, more than a third of all items. It covers elicitation, decomposition, evaluation, prioritization, specification, validation, and acceptance criteria. The breadth is wide and the depth is real. Candidates who skim this topic or rely on general project management intuition will run out of marks.

– Elicitation and elaboration

Eliciting or identifying requirements means using individual and group techniques to discover and capture requirements with supporting details such as origin and rationale. The exam tests your ability to choose the right elicitation technique for the stakeholder group and the type of requirement. A workshop is not always the answer, and neither is an interview. Once requirements are captured, you analyze, decompose, and elaborate them using dependency analysis, interface analysis, data modeling, and process modeling to uncover and clarify product options and capabilities. The skill being tested is whether you can take a high-level requirement and break it down without losing traceability or introducing assumptions. Candidates who decompose too far create noise; those who stop too soon leave ambiguity that costs marks when the exam asks what happens next.

– Evaluation and prioritization

Evaluating product options and capabilities involves decision-making and valuation techniques to determine which requirements are accepted, deferred, or rejected. The exam expects you to know that not all requirements are equal and that deferral is a legitimate decision, not a failure. Allocating accepted or deferred requirements means balancing scope, schedule, budget, and resource constraints against the value proposition. You use prioritization, dependency analysis, and decision-making tools to create a requirements baseline. The trap here is treating prioritization as a solo activity. The exam rewards collaboration and transparency. Obtaining sign-off on the baseline uses decision-making techniques to facilitate consensus and achieve approval. Candidates lose marks by moving forward without sign-off or by treating sign-off as a formality rather than a checkpoint.

– Specification and validation

Writing requirements specifications involves using process notations like use cases or user stories, along with data and interface details, to communicate requirements that are measurable and actionable. The exam tests whether your specification is suitable for development. Vague language, missing acceptance criteria, and untestable statements all signal a deficient specification. Validating requirements uses tools and techniques such as documentation review, prototypes, and demos to ensure requirements are complete, accurate, and aligned with goals, objectives, and the value proposition. The exam distinguishes between validation, which checks that you built the right thing, and verification, which checks that you built it right. Confusing the two costs marks. Elaborating detailed metrics and acceptance criteria uses measurement tools and techniques for evaluating whether the solution meets requirements. The skill is specificity: acceptance criteria that cannot be measured cannot be validated.

How Analysis is tested

Thirty-five percent means Analysis appears in more than one question in three, and the items span all eight tasks. Scenarios typically present a requirement that is incomplete, ambiguous, or misaligned, and you are asked to identify the problem or choose the corrective action. The demand is diagnostic: you must recognize what is wrong and know which technique fixes it. Candidates lose marks by choosing a response that sounds thorough but does not address the specific defect in the scenario. For example, running another workshop when the real issue is that the requirement has no acceptance criteria, or building a prototype when the requirement has not been validated against the business case. Another error is confusing elicitation with analysis, or analysis with validation. Each task has a distinct purpose, and the exam tests whether you can match the task to the gap. The weight makes this topic the highest-value area to strengthen if your practice test results show weakness here.

Traceability and Monitoring shifts from defining and analyzing requirements to tracking them through delivery. Fifteen percent of the exam tests whether you can maintain the integrity of the baseline, communicate status, and manage change without losing control of scope. Candidates who treat traceability as paperwork rather than risk management will struggle here.

– Tracking and monitoring

Tracking requirements means using a traceability artifact or tool to capture status, sources, and relationships, including dependencies, to provide evidence that requirements are delivered as stated. The exam tests whether you understand traceability as a verification mechanism. If you cannot trace a requirement from origin to delivery, you cannot confirm it was met. Monitoring requirements throughout their lifecycles ensures that supporting artifacts such as models, documentation, and test cases are produced, reviewed, and approved at each lifecycle point. The exam expects you to know what artifacts are appropriate at each stage and what happens when one is missing or out of sync. Updating a requirement's status involves communicating with stakeholders and recording changes in the traceability artifact or tool to track requirements towards closure. The skill is currency: stale status information creates false confidence.

– Communication and change management

Communicating requirements status to the project manager and other stakeholders keeps them informed of issues, conflicts, changes, risks, and overall status. The exam tests your ability to tailor the message to the audience and choose the right communication method. A status dashboard for the project manager is not the same as a change notification for a business stakeholder. Managing changes to requirements involves assessing impacts, dependencies, and risks in accordance with the change control plan, and comparing to the baseline to maintain integrity. The trap is treating change management as approval workflow. The exam rewards understanding that impact assessment comes first, and that a change which breaks a dependency or introduces a risk may be rejected even if a stakeholder requested it. Candidates who approve changes without assessing impact lose marks.

How Traceability and Monitoring is tested

Fifteen percent means roughly one question in seven comes from this domain, often in scenarios where a requirement has changed, a dependency is unclear, or status reporting has failed. You are asked to identify what went wrong or what should happen next. The demand is recognizing that traceability and monitoring are active disciplines, not passive record-keeping. Candidates lose marks by choosing responses that update a document but do not assess impact, or that communicate status without addressing the underlying issue. Another common error is assuming that traceability is the same as version control. Traceability captures relationships and evidence; version control captures history. The exam tests whether you know the difference and can use the right tool for the task. Items may also present a scenario where a requirement's status is ambiguous or where a change was approved without following the change control plan, and you must identify the consequence or the corrective action.

Evaluation closes the cycle by testing the delivered solution against acceptance criteria, the requirements baseline, and the business case. At ten percent it is the lightest topic by weight, but candidates still lose marks here by confusing validation with testing or by treating sign-off as ceremonial. The exam expects you to know what evidence proves the solution is ready and what happens when it is not.

How Evaluation is tested

Ten percent means roughly one question in ten, typically in scenarios where test results are ambiguous, gaps have been identified, or stakeholders are divided on whether to proceed with deployment. You are asked to choose the next step or identify what evidence is missing. The demand is knowing the difference between validating that the solution satisfies requirements and evaluating whether it delivers the value promised in the business case. Candidates lose marks by treating these as the same activity. Validating test results against acceptance criteria is a technical checkpoint; evaluating against the business case is a value checkpoint. Another error is obtaining sign-off without resolving identified gaps, or proceeding to deployment when the solution does not meet acceptance criteria. The exam rewards a disciplined approach: if the evidence does not support the decision, the decision should not be made. Items may present scenarios where stakeholders want to deploy despite gaps, or where the deployed solution is underperforming and you must choose the appropriate valuation technique to quantify the shortfall.