PMI-PBA Requirements Analysis: Models, Priorities, and Decisions

What the PMI-PBA Analysis domain covers

Analysis is 35% of the PMI-PBA content outline, the largest domain. It focuses on discovering, structuring, examining, validating, and prioritizing requirements and evaluating solution options. Candidates need more than a list of elicitation techniques. They must decide which method will clarify the issue, how to resolve conflicting information, and what evidence demonstrates that a requirement is usable and aligned with the need.

Analysis continues after initial discovery. Stakeholder feedback can reveal a misunderstanding. A model can expose a missing exception. A new constraint can make an option infeasible. An analyst revisits requirements as evidence changes, while preserving the decisions, versions, and approvals needed for the project’s governance.

Elicit information with a clear purpose

Elicitation gathers information from people, documents, systems, observation, and other sources. The analyst should start with a question: What do we need to learn? Which stakeholders or evidence can answer it? What technique fits the information, access, and constraints? The same technique is not equally useful for every situation.

Interviews can surface an individual’s experience, motivations, and exceptions. Workshops help participants compare perspectives and reach shared understanding. Observation reveals actual work, including workarounds people may omit from interviews. Surveys can gather structured input across a broad group but may lack depth. Document and interface analysis help identify policies, data, existing rules, and legacy assumptions. Prototypes let stakeholders react to a possible interaction before full implementation.

Consider a bank where staff say customers provide incomplete loan applications. Interviews may identify what staff believe is missing; application data can show which fields are often blank; observation can reveal that instructions are unclear; a prototype can test revised guidance. Triangulating methods is useful when stakeholder reports and measured behavior differ.

Use models to make complexity visible

Models provide a focused view of a situation. A process model shows activities, handoffs, decisions, and exceptions. A data model organizes concepts, relationships, and constraints. A state model shows how an entity changes over time. A use case or interaction model describes how actors achieve goals through a solution. A context diagram clarifies system boundaries and external connections.

Select the model that answers the analysis question. If customers repeat steps between departments, a process model can expose handoffs. If different systems use the word “account” differently, a conceptual data model can clarify entities and relationships. If a request is allowed only in certain statuses, a state model can make those transitions explicit. A model should be understandable to its audience and useful for decisions, not produced because a template requires it.

Models also reveal gaps and contradictions. A process diagram may show a decision with no owner. A data model may expose a field that has no defined source. A state model may omit what happens after a timeout. Review the model with relevant stakeholders and maintain links between important model elements and requirements where the project requires traceability.

Analyze and refine requirements

Analysis turns raw statements into requirements that can guide a solution and its verification. A useful requirement is clear, necessary, feasible, consistent with constraints, testable, and traceable to a source or need. It avoids unnecessary design choices unless the design constraint is itself required. It uses language that stakeholders and implementers can interpret consistently.

A statement such as “the system should be fast and easy” is too vague for verification. The analyst can clarify what task should take less time, under what conditions, for which users, and what threshold would count as acceptable. The result might be a measurable response-time requirement plus usability criteria. The measure should fit the actual business need rather than use an arbitrary threshold.

Check completeness without inventing requirements. Explore normal flows, alternatives, exceptions, permissions, data handling, dependencies, and failure conditions. Use stakeholder review to validate that the requirement expresses the need. Technical review can assess feasibility. Testers can help determine whether it can be verified. These perspectives complement each other but do not replace the accountable business owner’s approval.

Verification and validation are different questions

Verification asks whether the requirement is well formed: clear, consistent, feasible, and testable. Validation asks whether it is the right requirement for the stakeholder or business need. A requirement can pass a quality review and still describe the wrong outcome. Conversely, a stakeholder may genuinely need something but express it in language too vague to implement or test.

A requirement that says “send a reminder before renewal” may be clear enough to discuss but incomplete. Which renewals? How far in advance? Which channel? What happens when contact permission is missing? Validation asks whether the reminder addresses the customer or business need. Verification asks whether the statement has enough precision to be built and tested.

Resolve conflict by finding the underlying need

Stakeholders can disagree because they have different goals, different information, or different interpretations of the same phrase. The analyst should clarify what each person needs and why, identify constraints and trade-offs, and facilitate comparison. A model or scenario walkthrough can turn abstract disagreement into concrete consequences.

Suppose a sales team wants customer records editable by every representative to speed service, while data governance requires controlled updates. The underlying needs may be quick correction and reliable accountability. A role-based edit workflow, audit log, or limited field permission may satisfy both better than choosing one statement over the other. If the conflict reflects a policy decision, route it to the authorized owner.

Do not decide by counting votes or defaulting to the most senior stakeholder unless governance explicitly assigns that authority. The analyst should make the consequences legible and document assumptions, options, and decisions. Consensus is useful when available, but it cannot replace formal approval where the project requires it.

Prioritize requirements transparently

Prioritization determines relative importance or sequence. Criteria may include mandatory compliance, business value, risk reduction, urgency, dependency, cost, feasibility, stakeholder impact, and learning value. Make criteria explicit and apply them consistently. A priority label without rationale can conceal a negotiation rather than communicate a decision.

A regulated payment change might treat legal controls as non-negotiable constraints, then prioritize remaining improvements by customer impact and dependency. A new service with uncertain demand may prioritize a small experiment that produces learning before a costly feature. A technically dependent requirement may need earlier implementation even if it is not highly visible to users.

Avoid false precision. Scoring methods can help compare options, but their numeric totals reflect assumptions and weights. If one option scores highest only because a highly uncertain benefit received a large weight, call out that uncertainty. The authorized stakeholder decides trade-offs; analysts provide a defensible basis.

Evaluate solution options, not only requirements

The analysis may compare changes to process, policy, roles, training, information, or technology. Evaluate options against the defined need, constraints, expected benefits, risk, cost, feasibility, and impact. Include the status quo when it is a viable choice. If uncertainty could materially alter the recommendation, propose a pilot or additional evidence gathering.

For a company struggling with delayed employee onboarding, options may include simplifying approvals, clarifying manager responsibilities, integrating identity systems, or improving status visibility. A new application may help, but requirements should not be constrained to software until alternatives are considered. Evaluate how each option affects security, employee experience, effort, and time to productivity.

A worked case from elicitation through prioritization

A university reports that students cannot register for required courses. The analyst reviews registration data, interviews students and advisors, observes peak-period workflows, and maps prerequisite rules. The evidence reveals that some students are blocked by outdated prerequisite records while others encounter courses that fill before advising appointments.

A process model separates record correction from course-capacity issues. A data model clarifies which system owns prerequisite status. Stakeholders validate the requirements for timely record updates and transparent waitlist status. The analyst prioritizes a rule-compliant correction path and waitlist visibility, while documenting dependencies and measures. The registrar and academic owners approve the relevant policy and sequence.

This case shows why tools should follow the information need. A survey alone might report frustration but not reveal the data dependency. A model exposes the relationship between systems and decisions. Requirement validation confirms that the proposed changes address distinct problems; prioritization then makes trade-offs visible.

What the exam may ask

Questions can ask which elicitation method fits a context, what a model should clarify, how to handle conflicting needs, whether a requirement is verifiable, or how to prioritize options. Watch for the stated purpose and stakeholder access. If the issue involves actual work that differs from documented work, observation may be especially useful. If it involves broad stakeholder alignment, a facilitated workshop may be more suitable.

When evaluating answer choices, identify what is already known. If a need is unclear, do not jump straight to a detailed specification. If stakeholders have validated a requirement but it lacks testable criteria, refine and verify it. If priorities conflict, make criteria and impacts explicit and use the defined decision authority. If a solution option is being selected, compare it with the original outcome and constraints.

• Choose a technique based on the question it must answer.
• Use models to clarify structure, behavior, boundaries, and exceptions.
• Separate raw stakeholder statements from analyzed requirements.
• Check quality and stakeholder fit as distinct verification and validation questions.
• Resolve conflict by clarifying needs, constraints, and decision rights.
• Prioritize against transparent criteria and record uncertainty.
• Compare solution options with the need and intended business outcome.

Common analysis mistakes

Treating elicitation as a one-time event

New information can emerge during modeling, validation, design, testing, and evaluation. Elicitation and analysis may revisit earlier assumptions. The analyst should update the relevant records under the agreed management approach.

Confusing a model with an approved decision

A diagram helps people reason; it does not grant authority. Record decisions and approval status through the governance process.

Prioritizing by urgency alone

Urgency may matter, but dependencies, risk, mandatory constraints, benefit, and feasibility can change the sequence. Explain the criteria and impacts.

Writing solution design as if it were a need

Some design constraints are legitimate, but many solution details remain open until analysis compares options. Keep needs, requirements, and design decisions distinguishable.

Study checklist

• Can you select an elicitation method from the uncertainty and audience described?
• Can you choose a model that reveals the needed relationships or behavior?
• Can you improve a vague requirement without imposing unsupported design?
• Can you explain validation versus verification?
• Can you facilitate stakeholder conflict without usurping approval?
• Can you prioritize with explicit criteria and evaluate alternatives against the need?