Business Analysis on the CAPM: The 27% Domain That Catches People Off-Guard

Business Analysis is 27% of the current CAPM exam. That’s about 40 of 150 questions, or a little over one question for every three on the test. It’s also the domain most absent from study materials written before 2023, because on the pre-2023 exam it barely existed.

Candidates who study with outdated materials tend to lose most of the BA questions on exam day. This post covers what the domain actually tests and what a working knowledge looks like.

Why the domain exists

PMI’s rationale: project managers and business analysts work closely together on real projects, and the line between the roles is often blurred. A coordinator-level project manager is frequently asked to elicit requirements, manage traceability, or validate solutions. PMI added Business Analysis to the CAPM in 2023 to test whether candidates can operate at that boundary.

The domain does not test IIBA certification depth. It tests the parts of business analysis a project manager needs to recognize, participate in, and hand off cleanly.

The four areas inside the domain

The CAPM Business Analysis domain covers four areas:

• Needs assessment.
• Requirements elicitation and analysis.
• Requirements prioritization and traceability.
• Solution evaluation.

Each deserves its own section.

Needs assessment

Before requirements can be written, someone has to figure out what problem the project is actually solving. Needs assessment is the discovery phase.

Typical activities:

• Identifying stakeholders whose needs the project should address.
• Understanding the business context: what strategic objective the project serves, what constraints apply, what success looks like.
• Framing the problem in terms the business understands, not in terms of solutions.
• Building a business case that justifies the investment.

Questions in this area often describe a project sponsor who has asked for a specific solution. The scenario hints the real problem might be different, and the right answer usually involves stepping back to validate the underlying need before committing to the solution.

Requirements elicitation and analysis

Once the need is clear, elicitation gathers what stakeholders need the solution to do. PMI expects recognition of several techniques:

• Interviews. One-on-one conversations with stakeholders.
• Focus groups. Facilitated group discussions.
• Workshops. Structured, decision-oriented group sessions (often called JAD sessions).
• Surveys and questionnaires. Broad coverage, shallow depth.
• Observation. Watching users perform current work to identify unstated needs.
• Document analysis. Reviewing existing processes, regulations, or systems.
• Prototyping. Building partial or mock versions of a solution to elicit feedback.

Each technique suits a different context. Interviews and observation work when detail matters and the stakeholder count is small. Surveys work when you need breadth over depth. Workshops work when stakeholders need to reach alignment.

Analysis then turns raw elicited input into structured requirements. Techniques include modeling (process maps, data flow diagrams, use cases), decomposition (breaking a large need into smaller requirements), and validation (confirming with stakeholders that what you’ve captured matches what they meant).

Requirements prioritization

Not every requirement makes the cut. PMI expects familiarity with common prioritization techniques:

• MoSCoW. Must-have, Should-have, Could-have, Won’t-have (this time).
• Weighted scoring. Each requirement scored against multiple criteria, then summed.
• Kano analysis. Classifies features by their effect on customer satisfaction (basic, performance, delight).
• 100-point method. Stakeholders distribute 100 points across requirements to signal relative priority.

Scenario questions often describe a situation where a stakeholder insists every requirement is “must-have.” The right answer is usually to facilitate a structured prioritization rather than accept the claim at face value.

Requirements traceability

Traceability is the discipline of keeping a visible link from each requirement to its source (the business need), its related design elements, its implementation, and its test cases. It matters because requirements change, and without traceability you can’t answer basic questions like “if we cut this feature, which tests do we no longer need?” or “which stakeholder originally asked for this?”

A requirements traceability matrix (RTM) is the most common artifact. The CAPM may ask what an RTM contains, why it matters, and who maintains it. Typical fields:

• Requirement ID.
• Description.
• Source (stakeholder or document).
• Priority.
• Related design element.
• Related test case.
• Status.

Solution evaluation

Once a solution is delivered, someone has to evaluate whether it actually solves the original need. Solution evaluation compares delivered outcomes against the business case and the requirements.

Typical activities:

• Validation. Confirming the solution meets the documented requirements.
• Verification. Confirming the solution performs correctly (functions, edge cases, performance).
• Benefits realization. Measuring whether the project delivered the business value promised in the business case.
• Retrospective analysis. Identifying gaps between what was promised and what was delivered, and updating future planning accordingly.

Questions here often describe a project that delivered what was scoped but didn’t produce the expected business outcome. The right answer typically involves going back to the business case, not the requirements document.

Common question patterns

Solution versus need. A sponsor has asked for a specific solution. The scenario hints the real need is different. The right answer involves clarifying the need before committing.

Prioritization conflict. Two stakeholders disagree on priority. The right answer is usually a structured prioritization technique, not escalation or compromise.

Traceability failure. A requirement has been delivered but no one can confirm which stakeholder originally requested it or which tests cover it. The right answer involves the RTM.

Scope versus value. The project delivered exactly what was scoped but the business didn’t get the expected value. The right answer usually involves re-examining the business case, not the project’s execution.

What to study, at what depth

For the CAPM, BA knowledge should be broad but shallow. Recognize the techniques, understand when to use each, and know the core artifacts (RTM, requirements documents, business case). You don’t need the depth an IIBA certification (ECBA, CCBA, CBAP) would require.

Our CAPM Study Guide and Exam Prep 2026 covers the BA domain at the depth the current exam tests.