Overview
Analysis spans eight tasks that take requirements from discovery to an approved, testable baseline. You elicit or identify requirements with individual and group techniques; analyze, decompose and elaborate them through dependency, interface, data and process modeling; evaluate product options so each requirement is accepted, deferred or rejected; allocate requirements against scope, schedule, budget and resource limits; obtain sign-off on the baseline; write specifications as use cases, user stories, data and interface details; validate requirements with reviews, prototypes and demos; and elaborate detailed metrics and acceptance criteria.
Candidates must understand how each technique fits a situation, how requirement types (business, stakeholder, solution, transition) relate to one another, and how stakeholder values from Domain 1 drive prioritization. The baseline produced here is what Domain 4 traces and controls, and the detailed acceptance criteria are what Domain 5 tests against.
How it's tested
Analysis questions are heavily scenario-based. The stem describes a stakeholder group, a communication barrier, a modeling gap or a prioritization conflict, and asks which technique is BEST or what to do NEXT. The right answer matches the technique to a specific clue, such as geographically dispersed users, an undocumented legacy interface, or tacit knowledge, rather than defaulting to interviews.
-
Match the technique to the clue
Dispersed stakeholders suggest surveys, tacit work knowledge suggests observation, conflicting views suggest a facilitated workshop, and unclear user interaction suggests a prototype.
-
Prioritize and allocate
Competing requirements exceed budget or schedule, and you choose the approach that weighs value against constraints, such as MoSCoW, weighted ranking or deferring to a later release.
-
Verify or validate
A stem asks whether requirements are well-formed or whether they meet business objectives, and you choose verification or validation accordingly.
Warehouse supervisors describe the picking process in interviews, but their accounts conflict and skip steps they perform automatically. Options are a survey, another round of interviews, observation on the floor, or document analysis. The clue is tacit knowledge: people cannot fully describe what they do by habit. Observation captures the real workflow, including workarounds, so it is the best next technique.
Tasks 8
Official tasks from the PMI outline, in outline order.
3.1 Elicit or identify requirementsDraw out requirements and record their origin and rationale.
- What it means
- The analyst uses individual techniques (interviews, observation, document analysis) and group techniques (facilitated workshops, focus groups, brainstorming) to discover requirements and capture supporting details such as source and rationale.
- What to understand
- Elicitation is prepared, conducted, documented and followed up, and requirements are drawn out rather than simply collected. Recording origin and rationale for each requirement is what makes backward tracing and later prioritization possible.
- How it shows up
- A scenario describes stakeholders who are dispersed, conflicting, or unable to articulate needs, and you pick the elicitation technique that fits.
- Common confusion
- Treating elicitation as gathering a wish list, without capturing why each requirement exists or who raised it.
3.2 Analyze, decompose, and elaborate requirementsModel and break requirements down so options become clear.
- What it means
- Using dependency analysis, interface analysis and data and process modeling, the analyst breaks high-level requirements into detail and clarifies product options and capabilities together with stakeholders.
- What to understand
- Models reveal gaps that text hides: process flows show missing steps, entity relationship diagrams and data dictionaries show data rules, context diagrams and interface analysis show external connections, and decomposition models break features into smaller functions.
- How it shows up
- A stem describes a gap, such as an unknown external system feed or an undefined data rule, and asks which model would expose it.
- Common confusion
- Using a process model to find data relationships, or using a data model to find missing workflow steps.
3.3 Evaluate product options and capabilitiesDecide which requirements are accepted, deferred or rejected.
- What it means
- The analyst applies decision-making and valuation techniques, such as cost-benefit analysis, weighted ranking, decision tables and options analysis, to determine whether each requirement or capability is accepted, deferred or rejected.
- What to understand
- The basis for the decision is contribution to the value proposition and alignment with goals and objectives. A deferred requirement stays valid but waits for a later release; a rejected one is removed with the reason recorded.
- How it shows up
- Several capabilities compete for limited funds, and you choose how to decide which to include.
- Common confusion
- Treating deferred and rejected as the same outcome, or deciding by stakeholder seniority instead of value.
3.4 Allocate accepted or deferred requirementsBalance constraints against value to form the requirements baseline.
- What it means
- The analyst assigns accepted and deferred requirements to releases, iterations or solution components by balancing scope, schedule, budget and resources against the value proposition, using prioritization, dependency analysis and decision-making tools to create the requirements baseline.
- What to understand
- Prioritization techniques include MoSCoW (must, should, could, won't this time), Kano analysis, weighted ranking and the purpose alignment model. Dependencies can force a lower-priority requirement into an earlier release because a higher-priority one relies on it.
- How it shows up
- A high-value requirement depends on a lower-priority one, or the budget cannot cover all must-haves, and you decide the allocation.
- Common confusion
- Allocating purely by priority score and ignoring dependencies, or confusing allocation with traceability.
3.5 Obtain sign-off on requirements baselineBuild consensus and secure formal approval.
- What it means
- The analyst uses decision-making techniques to facilitate stakeholder consensus and obtain approval of the requirements baseline, as defined by the approval authority in the requirements management plan.
- What to understand
- Group decision methods include unanimity, majority, plurality, consensus and autocratic decision by the accountable authority. Once signed off, the baseline can change only through the change control process set in Planning.
- How it shows up
- Stakeholders disagree at the approval meeting, and you choose how to reach a decision or what happens to later changes.
- Common confusion
- Thinking sign-off means every stakeholder must agree, or that requirements stay freely editable after baselining.
3.6 Write requirements specificationsDocument process, data and interface details so they are actionable.
- What it means
- The analyst writes specifications using process descriptions such as use cases and user stories, together with data and interface details, so requirements are measurable, actionable and ready for development.
- What to understand
- A well-written requirement is unambiguous, complete, consistent, feasible, testable and traceable. User stories follow the role, goal and benefit pattern and are refined with acceptance criteria; use cases describe actors, main flow, alternate flows, preconditions and postconditions.
- How it shows up
- A requirement such as the system shall be fast is shown, and you identify what quality it lacks or how to rewrite it.
- Common confusion
- Including design or implementation choices in a requirement, or writing nonfunctional requirements that cannot be measured.
3.7 Validate requirementsConfirm requirements are complete, accurate and aligned to value.
- What it means
- Through documentation review, prototypes, demos and other validation methods, the analyst confirms requirements are complete, accurate and aligned with goals, objectives and the value proposition.
- What to understand
- Validation asks whether these are the right requirements for the business need; verification asks whether requirements are well-formed and meet quality standards. Prototypes are especially useful when users cannot judge requirements from text alone.
- How it shows up
- Users approve a written specification but reject the first build, and you choose the validation method that would have caught the mismatch earlier.
- Common confusion
- Swapping verification and validation, especially when a stem describes a peer review for ambiguity.
3.8 Elaborate and specify detailed metrics and acceptance criteriaTurn high-level criteria into measurable tests.
- What it means
- Using measurement tools and techniques, the analyst refines the planning-level metrics and acceptance criteria into detailed, measurable criteria for evaluating whether the solution meets each requirement.
- What to understand
- Detailed criteria state a measurable condition, such as 95% of searches return in under two seconds under 500 concurrent users. Formats include given-when-then scenarios and key performance indicators linked back to business metrics.
- How it shows up
- A requirement has vague acceptance wording, and you choose the most measurable criterion.
- Common confusion
- Confusing this with task 2.6, where criteria are defined at a high level with stakeholders during planning.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Requirement types
PMI's practice guidance separates business requirements (organizational needs), stakeholder requirements (needs of a group), solution requirements (functional and nonfunctional) and transition requirements (temporary capabilities to move from current to future state).
- Remember
- Transition requirements, such as data conversion and training, disappear once the solution is in place.
- Tested as
- Questions ask you to classify a requirement, often a data migration or training need, into the right type.
- Trap
- Classifying a one-time data conversion as a functional requirement instead of a transition requirement.
-
Functional vs. nonfunctional requirements
Functional requirements describe behaviors the solution performs; nonfunctional requirements describe qualities such as performance, security, usability and availability.
- Remember
- Nonfunctional requirements must be measurable, for example response time under two seconds for 95% of requests.
- Tested as
- Stems ask which requirement is nonfunctional or which one is untestable as written.
- Trap
- Accepting quality words such as user-friendly or fast without a measurable threshold.
-
Elicitation technique selection
Interviews suit depth with individuals, workshops suit resolving cross-functional views, surveys suit many dispersed stakeholders, observation suits tacit knowledge, and document analysis suits existing systems and rules.
- Remember
- Choose the technique that fits the clue in the stem, not the one you use most at work.
- Tested as
- One of the most frequent question styles in this domain.
- Trap
- Choosing interviews by default when the stem signals hundreds of users or habits people cannot describe.
-
Facilitated workshop
A structured session in which a neutral facilitator brings key stakeholders together to define or reconcile requirements quickly.
- Remember
- It builds shared understanding and resolves conflicts faster than serial interviews, but it needs preparation and the right decision-makers in the room.
- Tested as
- Expected answer when departments hold conflicting views on the same process.
- Trap
- Choosing separate interviews, which keeps the conflict hidden instead of resolving it.
-
Prototyping
Building a model of the solution, from paper wireframes to working mockups, so stakeholders can react to something concrete.
- Remember
- Throwaway prototypes explore and are discarded; evolutionary prototypes grow into the final product.
- Tested as
- Expected answer when users cannot visualize the solution or approved text keeps producing rejected builds.
- Trap
- Treating a throwaway prototype as nearly finished software and promising its delivery date.
-
MoSCoW prioritization
Groups requirements into must have, should have, could have and won't have this time.
- Remember
- Won't have means not in this release, not rejected forever, so it matches a deferred decision.
- Tested as
- Appears in allocation questions where the budget cannot cover everything.
- Trap
- Labeling too many items as must have, which removes the ability to make trade-offs.
-
Kano model
Classifies features as basic (expected), performance (more is better) or excitement (unexpected delighters) based on customer satisfaction.
- Remember
- Missing basic features causes dissatisfaction even though including them earns no praise.
- Tested as
- Used when a stem asks how to prioritize product features from the customer's point of view.
- Trap
- Cutting a basic feature because customers never asked for it.
-
Data and process models
Process flows and activity diagrams show steps and decisions; entity relationship diagrams, data dictionaries and data flow diagrams show data and how it moves.
- Remember
- Context diagrams and interface analysis show the boundary and external connections of the solution.
- Tested as
- Questions ask which model would reveal a specific type of gap.
- Trap
- Choosing a process flow to discover data cardinality or a missing external feed.
-
Requirements baseline
The approved set of requirements at a point in time, used as the reference for building, tracing and controlling change.
- Remember
- After sign-off, changes go through the change control process; the baseline is not edited informally.
- Tested as
- Questions ask what sign-off produces and how a late request is handled.
- Trap
- Updating a baselined requirement directly because the change looks minor.
-
Verification vs. validation
Verification checks that requirements are well-formed, consistent and meet quality standards; validation checks that they meet business goals, objectives and stakeholder needs.
- Remember
- Verification asks whether we wrote it right; validation asks whether we wrote the right thing.
- Tested as
- Frequently tested as a vocabulary distinction inside a scenario.
- Trap
- Calling a peer review for ambiguous wording validation.
-
Group decision-making methods
Unanimity, majority (over half), plurality (largest block, even if under half), consensus and autocratic decision by the accountable person.
- Remember
- Consensus means everyone can support the decision, not that everyone prefers it.
- Tested as
- Appears in sign-off scenarios with disagreement or in definition questions.
- Trap
- Confusing plurality with majority.
-
User stories and use cases
A user story states who needs what and why in one sentence and is refined with acceptance criteria; a use case describes actors, a main success flow, alternate and exception flows.
- Remember
- Good stories meet INVEST: independent, negotiable, valuable, estimable, small and testable.
- Tested as
- Questions ask what a story is missing or which format suits complex interaction flows.
- Trap
- Writing a story with no benefit clause, which hides why it matters.
-
Acceptance criteria formats
Detailed criteria can be written as given-when-then scenarios, checklists of conditions, or measurable thresholds linked to KPIs.
- Remember
- A good criterion produces a clear pass or fail result.
- Tested as
- Stems offer several criteria and ask which is most measurable.
- Trap
- Choosing criteria that depend on a stakeholder's opinion, such as works well for users.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Verification vs. validation of requirements
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Verification | Checking requirements are well-formed, unambiguous, consistent and testable | Quality of the requirement statement itself | Calling it validation because stakeholders review it |
| Validation | Confirming requirements meet business goals, objectives and the value proposition | Fitness of the requirement for the need | Assuming a well-written requirement is automatically the right one |
Interviews vs. workshops vs. surveys vs. observation
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Interviews | One-on-one or small-group questioning | Depth and sensitive topics with individuals | Using them for hundreds of users or to resolve group conflict |
| Facilitated workshop | Structured session with key stakeholders and a neutral facilitator | Builds consensus across groups quickly | Running it without decision-makers present |
| Survey or questionnaire | Written questions sent to many respondents | Breadth across large or dispersed groups | Expecting deep reasons or tacit knowledge from it |
| Observation | Watching people perform the work | Captures tacit steps and workarounds | Assuming it reveals the reasons behind the actions without follow-up |
Accepted vs. deferred vs. rejected requirements
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Accepted | Included in the current baseline | Will be built in the current scope | Assuming accepted means highest priority within the release |
| Deferred | Valid but scheduled for a later release or iteration | Stays in the backlog or traceability record | Deleting it as if rejected |
| Rejected | Will not be implemented | Removed with the reason recorded | Not documenting why, so it resurfaces later |
Business vs. stakeholder vs. solution vs. transition requirements
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Business requirement | Higher-level need of the organization, such as reducing claim processing cost | Why the initiative exists | Writing it as a system feature |
| Stakeholder requirement | Need of a particular stakeholder group | Bridges business needs and the solution | Treating it as already specified enough to build |
| Solution requirement | Functional and nonfunctional characteristics of the solution | What the product does and how well | Mixing in temporary migration needs |
| Transition requirement | Temporary capability needed to move to the future state, such as data conversion or training | No longer needed after transition | Classifying it as functional |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Interviews for everything
- What candidates pick
- Schedule more interviews when elicitation is not producing clear requirements.
- Why it looks right
- Interviews are familiar and give depth.
- Why it's wrong
- If the issue is tacit knowledge, conflicting groups or many dispersed users, interviews repeat the problem; observation, workshops or surveys fit those clues.
Clue to watch for People skip steps they do by habit, departments contradict each other, or users number in the hundreds across regions.
-
Peer review called validation
- What candidates pick
- Label a review that checks requirements for ambiguity and consistency as validation.
- Why it looks right
- Any review of requirements feels like validating them.
- Why it's wrong
- Checking wording quality is verification; validation confirms the requirements meet business objectives and stakeholder needs.
Clue to watch for The reviewers are checking format, clarity or testability rather than business fit.
-
Priority ignores dependencies
- What candidates pick
- Allocate the highest-priority requirements to release 1 and defer everything else.
- Why it looks right
- It looks like a clean application of priority scores.
- Why it's wrong
- If a must-have depends on a lower-priority requirement, the dependency must be delivered first or the must-have cannot work.
Clue to watch for The stem mentions that one requirement relies on another, such as reporting depending on a data feed.
-
Everyone must agree
- What candidates pick
- Delay sign-off until every stakeholder fully agrees with every requirement.
- Why it looks right
- Full agreement seems to reduce later conflict.
- Why it's wrong
- The requirements management plan names the approval authority and decision method; waiting for unanimity can stall the project without improving the baseline.
Clue to watch for One stakeholder holds out on a low-value item while the accountable approver is ready.
-
Minor edit to the baseline
- What candidates pick
- Update a signed-off requirement directly because the change is small.
- Why it looks right
- Small changes feel too trivial for formal process.
- Why it's wrong
- Once baselined, any change goes through change control so impact is assessed and traceability stays intact.
Clue to watch for The word approved, baselined or signed off appears before the change request.
-
Text is enough
- What candidates pick
- Ask users to re-read and re-approve the written specification after a build was rejected.
- Why it looks right
- The specification was approved, so the build must have strayed from it.
- Why it's wrong
- If users approved text but rejected the product, they could not visualize it; a prototype or demo validates requirements before more is built.
Clue to watch for Users say the build is not what they meant even though it matches the document.
-
Deferred equals deleted
- What candidates pick
- Remove deferred requirements from the traceability record to keep the baseline clean.
- Why it looks right
- They are not in the current release.
- Why it's wrong
- Deferred requirements remain valid for later releases and must stay tracked; only rejected requirements are closed, with the reason recorded.
Clue to watch for The requirement was deferred for budget or schedule, not rejected for lack of value.
Answer framework
For an Analysis scenario, use these steps to pick the technique or action the exam expects.
- Name the obstacle in the stem, such as tacit knowledge, dispersed users, conflicting groups, an unseen interface or a vague requirement.
- Pick the elicitation or modeling technique built for that obstacle rather than the one you use most often at work.
- Judge each requirement by its contribution to the value proposition and stakeholder values, then decide whether it is accepted, deferred or rejected.
- Allocate requirements by priority and dependencies within scope, schedule, budget and resources, and seek sign-off from the authority named in the plan.
- Check that each requirement is well-formed (verification), fits the business need (validation) and has measurable acceptance criteria before development.
Practice question
Want more like this? The PMI-PBA practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give Analysis the largest share of your time, since it is 35% of the exam. Work through it in lifecycle order: elicitation, modeling, evaluation and allocation, sign-off, specification, validation, then detailed acceptance criteria.
For elicitation, build a one-page table of techniques with the clue that selects each one, and quiz yourself with scenarios. For modeling, sketch a process flow, an entity relationship diagram, a context diagram and a data flow diagram for the same small example, so you can see what each reveals and what it hides. These two areas produce the most technique-selection questions.
High-priority concepts are requirement types, the accepted, deferred and rejected outcomes, prioritization with dependencies, and verification versus validation. Commonly underestimated areas are group decision methods (especially plurality versus majority) and the line between task 2.6 and task 3.8 acceptance criteria.
Afterward, practice large mixed sets of Analysis questions, because volume is how you learn to read the technique clue quickly. Review misses by asking which word in the stem pointed to the right technique. Then move to Domain 4, which traces and controls the baseline you just learned to create.
FAQ
How much of the PMI-PBA exam is Analysis?
Analysis is the largest domain at 35% of the exam. On 200 items that is roughly 70 questions as a planning estimate; PMI does not publish per-domain counts.
Which elicitation techniques should I know best?
Interviews, facilitated workshops, focus groups, surveys, observation, document analysis, brainstorming and prototyping. The exam tests when each fits, so learn the scenario clue for each.
What is the difference between verification and validation?
Verification checks that requirements are well-formed and meet quality standards. Validation checks that they meet business goals, objectives and the value proposition.
What happens to a deferred requirement?
It stays valid and tracked but is allocated to a later release or iteration. A rejected requirement is closed, with the reason recorded.
Does sign-off require unanimous agreement?
No. The requirements management plan defines who approves and how decisions are made; consensus means everyone can support the decision, not that everyone prefers it.
Are user stories and use cases both on the exam?
The ECO names both as ways to write process requirements. Know the structure of each and when a detailed use case suits complex interactions better than a story.
How does Analysis connect to Evaluation?
The detailed acceptance criteria written in task 3.8 are what Domain 5 uses to judge test evidence and identify gaps in the built solution.
Is this domain harder than the others?
It is the broadest, which makes it demanding. Most difficulty comes from choosing between two plausible techniques, so practice reading the specific clue in each scenario.
Other Business Analysis certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered elicitation, modeling, prioritization, baseline sign-off, specification and validation. Test whether you can spot the clue that selects the right technique under exam time pressure.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the PMI-PBA AI tutor Get any concept explained your way