CAPM guideStudy & preparation
CAPM Business Analysis Frameworks: How to Study the Domain Worth 27%
Business analysis is 27% of the CAPM, roughly 36 of 135 scored questions. Here are PMI's six tasks in plain terms, the roles and techniques the questions compare, traceability vs backlog, acceptance criteria vs definition of done, and a two-week study block.
Short answer
Business Analysis Frameworks is 27% of the CAPM, about 36 of the 135 scored questions by Passy's arithmetic. PMI's outline gives it six tasks: understand business analysis roles, conduct stakeholder communication, gather requirements, understand product roadmaps, see how the delivery approach changes business analysis, and validate requirements through delivery. In practice, that means matching elicitation techniques and tools to situations, reading a traceability matrix or product backlog, setting acceptance criteria, and deciding whether a product is ready to release.
Business Analysis Frameworks is Domain IV of the CAPM and carries 27% of the exam. Applied to the 135 scored questions, that's about 36, second only to Fundamentals. PMI's CAPM Examination Content Outline (2023 Exam Update) defines six tasks for it, and they are less about project management theory than about requirements: who needs what, how you find out, how you track it, and how you know it's delivered.
Why business analysis carries so much weight on the CAPM
Business analysis entered the CAPM with the 2023 Exam Update. PMI's 2023 FAQ says the new exam expanded to cover predictive, agile and business analysis principles because project team members now work across different approaches. The outline's reference list includes two business analysis titles: The PMI Guide to Business Analysis (2017) and Business Analysis for Practitioners: A Practice Guide, Second Edition (2024).
Two consequences for your study plan:
- It's a big share for a topic you may not have studied. If your project management training centered on schedules and budgets, requirements, traceability and roadmaps may be thin in your notes.
- It overlaps the other domains. The outline says business analysis ideas appear "throughout the four domain areas," so a requirements question can also turn up under Fundamentals or Agile.
For a sense of practice volume, see how planned CAPM prep sizes business analysis next to the other three domains.
The six CAPM business analysis tasks in plain terms
The task names are shortened from PMI's outline; the explanations and examples are Passy's.
| Task | What you should be able to do | Typical concepts |
|---|---|---|
| 1. Business analysis roles and responsibilities | Tell stakeholder roles apart, explain why roles need defining, separate internal from external roles | Product owner, product manager, process owner, process manager, sponsor, business analyst |
| 2. Stakeholder communication | Pick the right channel or tool for an audience, explain why the business analyst connects teams | Reports, presentations, working sessions, feature and requirement discussions |
| 3. Gathering requirements | Match tools and techniques to a situation, read a traceability matrix or backlog | Interviews, surveys, workshops, lessons learned, user stories, use cases |
| 4. Product roadmaps | Explain what a roadmap is for, decide which components go in which release | Releases, sequencing by value and dependency |
| 5. How the approach changes business analysis | Describe the business analyst's role in predictive and adaptive work | Up-front documentation vs ongoing backlog refinement |
| 6. Validating requirements through delivery | Define acceptance criteria, judge readiness for release from a traceability matrix or backlog | Acceptance criteria, release readiness |
Business analysis roles CAPM questions compare
Task 1 asks you to distinguish stakeholder roles, and the outline's examples are process owner, process manager, product manager and product owner. The outline doesn't define them. The short descriptions below are Passy's plain-language summaries of common usage, not PMI's definitions, so check the wording against the references the outline lists, such as The PMI Guide to Business Analysis:
| Role | Main concern |
|---|---|
| Sponsor | Provides resources and support for the project and is accountable for enabling its success |
| Product owner | In agile teams, maximizes the value of the product and orders the product backlog |
| Product manager | Owns the product's direction across its life, often beyond a single project |
| Process owner | Accountable for a business process end to end, including how it's designed and how it performs |
| Process manager | Runs a business process day to day |
| Business analyst | Elicits, analyzes and validates requirements, and keeps stakeholders and the delivery team aligned |
| Project manager | Leads the team to deliver the project's objectives |
The outline also asks you to tell internal roles (inside the performing organization) from external ones (customers, regulators and vendors are typical examples), and to explain why identifying stakeholders matters in the first place: requirements come from people, and a missed stakeholder usually means a missed requirement.
Matching requirements techniques to the situation
PMI's outline names interviews, surveys, workshops and lessons learned as examples of gathering approaches, plus user stories and use cases as tools. A useful way to study them is by the situation each one fits. The pairings below are Passy's guidance:
| Situation | Technique that usually fits | Why |
|---|---|---|
| One expert holds knowledge nobody else has | Interview | Depth, follow-up questions, room for sensitive topics |
| Several departments disagree on what they need | Facilitated workshop | Gets the people together to resolve differences and agree |
| Hundreds of users in many locations | Survey or questionnaire | Reaches many people quickly and gives countable answers |
| Users can't describe how they actually work | Observation | You see the real process, including workarounds |
| Stakeholders struggle to react to abstract ideas | Prototype | A tangible model draws concrete feedback |
| A similar project ran last year | Lessons learned | Reuses what that team already learned |
| Stakeholders list far more than one release can hold | A prioritization technique, such as MoSCoW (must, should, could, won't) | Forces ranked choices instead of everything being urgent |
For documenting what you find, know the difference between the two tools the outline names. A user story is a short statement of need from a user's point of view, usually in an adaptive backlog. A use case describes, step by step, how an actor interacts with a system to reach a goal, including alternate paths. Short and value-focused points to a user story; detailed interaction flow points to a use case. Technique-matching is a skill you build by repetition, and drilling business analysis on its own, or mixed with the other domains, is planned for full CAPM prep.
Traceability matrix vs product backlog on the CAPM
The outline pairs these two repeatedly, as "requirements traceability matrix/product backlog." They do a similar job in different approaches:
| Requirements traceability matrix | Product backlog | |
|---|---|---|
| Typical approach | Predictive | Adaptive |
| What it is | A table linking each requirement to its source (the business need) and onward to deliverables and tests | An ordered list of work items, refined continuously |
| Who keeps it in order | Typically the business analyst or project team, under change control | The product owner orders it; the team refines it |
| How it shows readiness | Every required item traces to a delivered and tested result | The items planned for the release meet their acceptance criteria and the team's definition of done |
A worked example (fictional project). A team is preparing release 1 of a booking website. The traceability matrix shows three must-have requirements: online payment is built and its tests pass, confirmation email is built and its tests pass, and refund requests are built but one acceptance test fails. A fourth requirement, loyalty points, was moved to release 2 through an approved change. Is release 1 ready? Not yet: the deferred item is fine because the change was approved, but a must-have with a failing acceptance test is not validated. That's the reasoning Task 6 asks for.
Keep acceptance criteria and the definition of done apart. Acceptance criteria are the conditions one specific item must meet to be accepted. The definition of done is the team's shared checklist that applies to every item. An item can meet its acceptance criteria and still not be done if, say, documentation the team requires is missing.
How the delivery approach changes the business analyst's job
| Predictive | Adaptive | |
|---|---|---|
| When requirements are detailed | Mostly early, then baselined | Continuously, just before the work is done |
| How changes are handled | Through change control | Through backlog refinement and reprioritization |
| Main artifact | Requirements documentation and the traceability matrix | The product backlog with user stories and acceptance criteria |
| Business analyst's focus | Complete, approved requirements before build | Ongoing collaboration with the product owner and team |
Expect questions that describe a situation and ask what the business analyst should do next. Read for the approach first: the same request ("the customer wants a new feature") has a different right answer in a baselined predictive project than in an agile team with a product owner.
Product roadmaps and release decisions
Task 4 asks you to explain what a product roadmap is for and decide which components go to which releases. A roadmap shows the planned direction of a product and the sequence of releases over time, at a high level. Deciding what goes in a release usually weighs business value, dependencies (a component another one needs must come first), risk, and capacity. If an exam scenario says one feature can't work without another, the dependency settles the order before value does.
A two-week CAPM business analysis study block
About 8 to 9 hours a week, matching the business analysis share of a 64-hour plan:
| Days | Focus |
|---|---|
| 1–2 | Roles and stakeholder types: build your own table like the one above from memory |
| 3–4 | Requirements techniques: write one situation for each technique, then swap them around and check the fit |
| 5 | User stories vs use cases, acceptance criteria vs definition of done |
| 6–7 | Mixed practice on Tasks 1 to 3, reviewing every miss |
| 8–9 | Traceability matrix vs backlog, release readiness, product roadmaps |
| 10–11 | Business analysis in predictive vs adaptive work: rewrite three scenarios in both approaches |
| 12–14 | Mixed practice across all six tasks, then a mixed set with other domains |
PMI's own on-demand CAPM course, listed at 23 hours, gives business analysis two of its ten modules. If you need more structure, the CAPM study time guide places this block inside an 8-week plan.
Practice is where business analysis clicks, because the questions are mostly situations rather than definitions. Start with Passy's 20 free CAPM practice questions, which include business analysis items with explanations. For volume, 594 business analysis questions and 146 flashcards are planned for full CAPM prep, and checkout isn't open yet.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.