PMI-PBA Exam Content Outline

The five-domain PMI-PBA outline

These are the weights on PMI’s current PMI-PBA content outline and certification page. They total 100% of the item allocation. They are a blueprint for exam coverage, not a guarantee of the exact count of scored questions in one exam form. Analysis is the largest domain at 35%; Needs Assessment, Planning, Traceability and Monitoring, and Evaluation make up the remaining 65%.

Business analysis is a connected practice. The analyst starts by understanding a business need, plans how to do the analysis, develops and manages requirements, keeps their relationships and status current, and evaluates the solution and outcomes. Learning the domain names is useful, but the exam expects candidates to select activities and artifacts that fit a scenario.

Needs Assessment: understand the business problem

Needs Assessment accounts for 18%. Its tasks include defining or reviewing a problem or opportunity, analyzing information to contribute to a value proposition, clarifying project goals and solution scope, identifying stakeholders, and eliciting stakeholder values. The analyst helps the organization distinguish its desired change from an early solution idea.

A service manager says, ‘We need an automated chatbot because customers are waiting too long.’ The analyst should investigate wait times, contact reasons, customer feedback, service hours, and current work patterns. Perhaps most delays happen because customers repeat information between departments; perhaps they need a staffed option for unusual cases. A chatbot is one possible solution, but the business problem should be defined before the organization commits to it.

Value assessment considers expected benefits, costs, feasibility, risk, and alignment with organizational goals. Stakeholder identification should include people who use, support, maintain, approve, or are affected by the solution. A customer segment with low representation can have needs that are missed if the analyst interviews only managers. The analyst also explores differing stakeholder values so requirements can be prioritized transparently.

A solution scope statement or business case input provides a basis for later work. It describes the need, goals, constraints, possible options, and expected outcomes at an appropriate level. If the evidence changes, revisit assumptions rather than allowing a once-stated solution to become permanent by default.

Planning: decide how the analysis will work

Planning makes up 22%. It begins with the business case and project objectives, then establishes how requirements and analysis information will be elicited, documented, managed, communicated, approved, and changed. Planning also defines traceability strategy, document control, business metrics, and acceptance criteria.

The right analysis approach depends on the project. A regulated system with complex integrations may need formal version control, impact records, approval gates, and traceability from business objectives to tests. A small internal process improvement may use visual workflows, short workshops, and lightweight decision records. Both approaches need enough discipline to manage risk and keep stakeholders aligned.

A traceability strategy specifies which relationships to maintain and why. It might link each business objective to stakeholder requirements, solution requirements, design components, tests, and delivery evidence. The plan should explain who maintains the artifact and when statuses are updated. A traceability tool is useful when it supports decisions about coverage, dependencies, impact, or readiness.

The requirements management plan clarifies roles and responsibilities, communication channels, elicitation and analysis methods, approval procedures, and change protocols. Document control establishes how versions are named, stored, reviewed, and retired. Business metrics and acceptance criteria establish how the team will assess both requirement conformance and expected business results.

Analysis: elicit, refine and validate requirements

Analysis represents 35% and has the most tasks. It includes eliciting or identifying requirements with their source and rationale, analyzing and decomposing them, evaluating product options, prioritizing and allocating requirements, obtaining baseline approval, writing specifications, validating requirements, and defining detailed metrics and acceptance criteria.

Elicitation methods include interviews, facilitated workshops, brainstorming, focus groups, observation, document analysis, surveys, research, and prototypes. Select the method based on the information needed. Interviews may uncover individual concerns. Observation can reveal workarounds people do not think to mention. A workshop helps reconcile conflicting definitions. A survey can compare responses across a large group, but it may not explain why an answer was selected.

Analysis turns discovered information into requirements that are clear, feasible, testable, and connected to a need. Models help expose gaps: process diagrams show handoffs, data models show entities and relationships, and interface analysis reveals dependencies with other systems. Decomposition breaks a broad requirement into smaller parts while preserving the overall goal and relationships.

Evaluate possible solution capabilities before accepting or deferring requirements. Prioritize using value, cost, risk, dependency, schedule, resource constraints, and stakeholder input. Build a requirements baseline only after appropriate review and approval. A baseline is a controlled reference for future change, not a rule that needs cannot ever evolve.

Specifications communicate requirements to those who will build, test, approve, or operate the solution. User stories and use cases can describe interactions; process, data, and interface details may be needed for complex behavior. Choose a representation that communicates the requirement to the audience. A vague phrase such as ‘fast response’ should become a measurable condition where the business need allows it.

Validation checks whether requirements are complete, accurate, and aligned with goals and value. Review, prototype, demo, and stakeholder walkthroughs can expose misunderstandings before implementation. Validation of the requirement is distinct from verification of the finished solution against that requirement. Both matter, but they answer different questions.

Traceability and Monitoring: manage requirement lifecycles

Traceability and Monitoring carries 15%. Requirements have sources, statuses, dependencies, versions, and relationships to models, tests, approvals, and solution elements. The analyst tracks these relationships so the team can show what is delivered, what remains open, and which artifacts need attention at each lifecycle point.

Monitoring helps the analyst notice when a requirement is stalled, changed, contradicted, or not supported by a test. Status communication should reach the project manager and relevant stakeholders. If an important stakeholder changes a requirement, the analyst documents the source and routes the decision through the change method. The work should not be updated privately without communicating the effect to the people making delivery decisions.

Impact analysis follows relationships and dependencies. A change to a customer identity field may affect interfaces, data retention, reports, privacy controls, test cases, training, and operational procedures. The analyst helps estimate the impacts and risks so the accountable group can accept, defer, or reject the change. Traceability is especially useful when a requirement has many dependents or when omissions would create significant risk.

Evaluation: check delivery and realized outcomes

Evaluation is 10%. It includes validating test results and other evidence against acceptance criteria, identifying gaps between scope and the developed solution, communicating discrepancies, obtaining stakeholder sign-off, and evaluating the deployed solution against the business case and value proposition.

Suppose a scheduling system correctly sends reminders according to every approved requirement, but missed appointments do not decline. Verification may show that the messages were sent, the timing rules worked, and the delivery report was accurate. Evaluation asks whether the deployed solution met the business objective. The analyst should examine outcome data, compare it with the baseline, and help stakeholders understand remaining gaps.

Sign-off confirms that authorized stakeholders accept a defined solution or deliverable under the applicable process. It does not automatically prove that the solution created value. A solution can meet acceptance criteria but need follow-up if the business environment changes or the original value proposition was based on a weak assumption. Evaluation provides an evidence-based basis for improvement or further investment.

Connect the domains in one case

A public agency wants to reduce the time required for residents to renew a permit. The request begins with a proposed online portal. In Needs Assessment, the analyst examines wait-time records and observes that many residents bring incomplete documents. Interviews show that instructions differ between departments. The analyst identifies residents, clerks, policy staff, IT, and accessibility advocates, then frames the outcome as reducing repeat visits while maintaining legal documentation.

In Planning, the analyst sets stakeholder sessions, identifies requirements and document control methods, and plans traceability from the goal to tests. Metrics include complete applications on first submission and repeat visit rates. In Analysis, the analyst models the current process, clarifies document rules, creates requirements for accessible instructions and error handling, prioritizes an initial release, and validates drafts with clerks and residents.

During Traceability and Monitoring, a policy revision changes which documents are required. The analyst identifies the affected instructions, forms, validation rules, tests, and training materials, then communicates the impact through change control. In Evaluation, test results show the new portal applies the rules correctly, while outcome measures reveal that residents still return because they cannot tell which documents apply to their case. The team has evidence that the solution conforms technically but needs another improvement to achieve the business goal.

How to prioritize study across domains

Analysis receives 35%, so candidates should become comfortable with elicitation, models, prioritization, baseline approval, specification, and validation. Planning at 22% has a substantial weight and provides the governance that supports Analysis. Needs Assessment establishes the reason for the initiative; Traceability and Monitoring manage the work as it changes; Evaluation verifies delivery and realized results.

A weighted study plan should still account for personal gaps. An experienced requirements analyst may need to revisit value assessment or post-deployment evaluation. A project manager may know change control but need more practice with elicitation, modeling, and requirement quality. A systems analyst may be strong in technical interfaces but less familiar with stakeholder values and business cases.

Take a diagnostic set, classify each error by domain and task, and write the decision mistake. Did you select a solution before defining the problem? Did you document a requirement before confirming its source? Did you skip impact analysis? Did you treat acceptance as proof of business value? Then practice a different scenario using the same concept to test whether the reasoning transfers.

Common outline-reading mistakes

• Treating the five domains as isolated stages rather than connected responsibilities.
• Assuming the business analyst can approve scope, budget, or risk without the authority stated in the scenario.
• Confusing a stakeholder request with a validated requirement.
• Treating a requirements baseline as unchangeable instead of controlled.
• Using traceability as a spreadsheet exercise without a decision purpose.
• Confusing requirement validation, solution verification, and post-deployment evaluation.
• Assuming that technically correct delivery proves expected business value.

For each question, identify the stage, objective, evidence, and decision owner. The best answer will usually close a gap in understanding, protect the traceability of a decision, or provide evidence for an appropriate stakeholder choice. Select the answer that addresses the question’s timing rather than a general activity that could happen later.