PMI-PBA® Prep Hub — Free Business Analysis Practice Questions, Case Studies & Mock Exams
PMI-PBA® Prep Hub is a free, all-in-one preparation tool for the PMI Professional in Business Analysis (PMI-PBA)® exam, with 1,500 ECO-aligned practice questions, active-recall flashcards, 50 applied case studies, and 5 full-length mock exams across Needs Assessment (18%), Planning (22%), Analysis (35%), Traceability & Monitoring (15%), and Evaluation (10%). Every question maps to a task and enabler in the PMI-PBA® Examination Content Outline. This content is loaded interactively; the summary below is provided for search engines and readers without JavaScript. Last reviewed: 2026-09-13.
Exam at a glance
- Questions: 200 (175 scored + 25 unscored pretest)
- Time: 4 hours (240 minutes)
- Domains & weight: Needs Assessment 18% · Planning 22% · Analysis 35% · Traceability & Monitoring 15% · Evaluation 10%
- Eligibility: Secondary degree + 60 months BA experience, or bachelor's degree + 36 months, plus 35 contact hours
The 28 PMI-PBA® ECO tasks
Needs Assessment (18%, 5 tasks)
- D1T1 — Define or review a business problem or opportunity using problem and opportunity analysis techniques in order to develop a solution scope statement and/or to provide input to create a business case.: Use gap analysis to compare the current state to the desired future state; Explain the relationship between needs assessment outputs and the business case; Apply root cause analysis techniques during needs assessment (and more).
- D1T2 — Collect and analyze information from a variety of sources using valuation tools and techniques to contribute to determining the value proposition of the initiative.: Apply payback period analysis to evaluate an initiative; Use market and competitive analysis to inform the value proposition; Use benchmarking as an information source for valuation (and more).
- D1T3 — Collaborate in the development of project goals and objectives by providing clarification of business needs and solution scope in order to align the product with the organization's goals and objectives.: Distinguish between organizational goals and project objectives; Apply SMART criteria to define project goals and objectives; Collaborate with stakeholders in developing project goals and objectives (and more).
- D1T4 — Identify stakeholders by reviewing goals, objectives, and requirements in order that the appropriate parties are represented, informed, and involved.: Distinguish the sponsor's role from the end user's role among identified stakeholders; Apply techniques to identify stakeholders; Distinguish between internal and external stakeholders (and more).
- D1T5 — Determine stakeholder values regarding the product, using elicitation techniques, in order to provide a baseline for prioritizing requirements.: Apply MoSCoW prioritization based on elicited stakeholder values; Use individual stakeholder interviews as an elicitation technique; Apply the Kano model to understand stakeholder value perceptions (and more).
Planning (22%, 6 tasks)
- D2T1 — Review the business case, and the project goals and objectives, in order to provide context for business analysis activities.: Consider project and product risk when planning business analysis activities; Use project goals and objectives to provide context for business analysis activities; Review the intended delivery approach (predictive, adaptive, hybrid) during business analysis planning (and more).
- D2T2 — Define strategy for requirements traceability using traceability tools and techniques in order to establish the level of traceability necessary to monitor and validate the requirements.: Determine the appropriate level of requirements traceability for a given initiative; Formally document the agreed traceability strategy; Explain why regulatory or compliance needs drive the required level of traceability (and more).
- D2T3 — Develop a requirements management plan by identifying stakeholders, roles and responsibilities, communication protocols, and methods for eliciting, analyzing, documenting, managing, and approving requirements in order to establish a roadmap for delivering the expected solution.: Establish a review cadence for requirements within the requirements management plan; Explain how the requirements management plan establishes a roadmap for delivering the expected solution; Define documentation standards within the requirements management plan (and more).
- D2T4 — Select methods for requirements change control by identifying channels for communicating requests and processes for managing changes in order to establish standard protocols for incorporation into the change management plan.: Describe the purpose of a requirements change control process; Explain the role of a change control board (CCB) in the change management process; Identify channels for communicating requirement change requests (and more).
- D2T5 — Select methods for document control by using documentation management tools and techniques in order to establish a standard for requirements traceability and versioning.: Establish a single source of truth for requirements documentation; Explain how document control supports requirements traceability and versioning; Explain why establishing a document control standard matters across a multi-stakeholder initiative (and more).
- D2T6 — Define business metrics and acceptance criteria by collaborating with stakeholders for use in evaluating when the solution meets the requirements.: Explain why business metrics and acceptance criteria should be defined during planning, not later; Establish a baseline measurement before defining target business metrics; Ensure acceptance criteria are specific and testable (and more).
Analysis (35%, 8 tasks)
- D3T1 — Elicit or identify requirements, using individual and group elicitation techniques, in order to discover and capture requirements with supporting details (e.g., origin and rationale).: Confirm stakeholder readiness and availability before beginning elicitation; Distinguish individual elicitation techniques from group elicitation techniques; Confirm elicitation results with the stakeholder before finalizing (and more).
- D3T2 — Analyze, decompose, and elaborate requirements using techniques such as dependency analysis, interface analysis, and data and process modeling, in order to collaboratively uncover and clarify product options and capabilities.: Apply dependency analysis to uncover relationships between requirements; Explain why analyzing requirements collaboratively helps uncover product options and capabilities; Apply interface analysis to identify how a solution interacts with other systems (and more).
- D3T3 — Evaluate product options and capabilities by using decision-making and valuation techniques in order to determine and recommend the most economically viable solution option.: Apply a weighted decision matrix to compare product options; Apply decision-making techniques to evaluate competing product options; Use multi-voting (dot voting) to narrow a large list of product options (and more).
- D3T4 — Organize, categorize, and specify requirements using a defined set of attributes and requirements/design models (e.g., process flows, use cases, business rules) in order to produce a structured requirements specification.: Select an appropriate specification format based on audience and content; Specify acceptance criteria alongside individual requirements; Specify business rules as a distinct requirement type within the specification (and more).
- D3T5 — Determine assumptions, dependencies, and constraints affecting the requirements and the proposed solution by analyzing the current and future business environment in order to support feasibility and design decisions.: Define a constraint affecting the requirements or proposed solution; Ensure stakeholders are aware of documented constraints affecting the solution; Maintain a documented assumptions log throughout the initiative (and more).
- D3T6 — Verify requirements by checking them against a defined set of quality criteria (e.g., unambiguous, complete, consistent, testable) using techniques such as peer review and inspection, in order to ensure that requirements are of sufficient quality to proceed.: Explain why verifying requirements early reduces overall cost; Verify that a requirement is feasible; Describe the purpose of verifying requirements (and more).
- D3T7 — Validate requirements by comparing them to the identified business need using techniques such as demonstration and walkthroughs, in order to ensure that requirements align with and support the business goals and objectives.: Use a walkthrough to validate requirements with stakeholders; Explain how validation catches gaps that verification alone may miss; Use validation to help detect scope creep (and more).
- D3T8 — Obtain approval of requirements using a formal or informal approval process in order to proceed to design, development, and/or implementation of the requirements.: Identify the appropriate approval authority for a given requirement; Explain how requirements approval establishes a scope baseline; Distinguish formal from informal requirements approval processes (and more).
Traceability & Monitoring (15%, 5 tasks)
- D4T1 — Track requirements using a traceability artifact or tool, capturing the requirements' status, sources, and relationships (including dependencies), in order to provide evidence that the requirements are delivered as stated.: Explain how a traceability artifact helps prevent an 'orphaned' requirement; Capture requirement dependencies within a traceability artifact; Document each requirement's source within the traceability artifact (and more).
- D4T2 — Manage the requirements life cycle status of each requirement throughout the project by monitoring changes in status and disposition in order to ensure that requirements remain aligned with business objectives.: Maintain an audit trail of status changes throughout the requirement's life cycle; Assign clear ownership for updating a requirement's life cycle status; Ensure accuracy when reporting requirement life cycle status to stakeholders (and more).
- D4T3 — Evaluate the impact of proposed changes to requirements on the project scope, schedule, cost, and previously approved requirements, using impact analysis techniques, in order to make an informed change control decision.: Document impact analysis findings for later reference; Explain how impact analysis supports an informed change control decision; Involve technical stakeholders when conducting impact analysis (and more).
- D4T4 — Communicate requirements status to stakeholders using agreed-upon reporting methods (e.g., dashboards, status reports) in order to maintain a shared and current understanding of requirements progress.: Use a dashboard to communicate requirements status efficiently; Communicate concerning requirements status (e.g., a significant delay) transparently; Reference the traceability artifact when communicating detailed requirements status (and more).
- D4T5 — Update requirements and related artifacts following an approved change, using version and configuration control techniques, in order to maintain a single, current, and accurate baseline.: Describe the purpose of updating the requirements baseline after an approved change; Retain the rationale for a change alongside the updated requirement; Determine whether an updated baseline requires formal re-approval (and more).
Evaluation (10%, 4 tasks)
- D5T1 — Validate the developed solution against the specified requirements and acceptance criteria, using techniques such as testing, demonstration, and inspection, in order to confirm the solution has been built as specified.: Use a demonstration to validate a developed solution component; Describe the purpose of validating a developed solution against requirements; Validate non-functional requirements as part of solution validation (and more).
- D5T2 — Determine whether the delivered solution results/deliverables satisfy the business and stakeholder needs, by comparing performance against defined business metrics and success criteria, in order to identify gaps or deficiencies.: Involve relevant roles (testers, project manager, business analyst) when evaluating solution results; Use both quantitative and qualitative methods to evaluate solution performance; Assess stakeholder satisfaction as part of solution evaluation (and more).
- D5T3 — Facilitate the go/no-go decision and obtain formal sign-off on the solution or solution component, using established acceptance and decision-making criteria, in order to authorize transition, deployment, or closure.: Base a go/no-go decision on established acceptance criteria; Document formal sign-off for later reference and audit; Handle a conditional 'go' decision with outstanding minor issues (and more).
- D5T4 — Evaluate the long-term performance and realized business value of the deployed solution against the original business case, using performance measurement techniques, in order to inform future initiatives and continuous improvement.: Measure benefits realization against the original business case; Conduct a post-implementation review to evaluate long-term solution performance; Use long-term evaluation findings to inform continuous improvement (and more).
Sample PMI-PBA® practice questions
Why does the purpose of gap analysis in needs assessment matter to effective business analysis practice? (Needs Assessment — Define or review a business problem or opportunity using problem and opportunity analysis techniques in order to develop a solution scope statement and/or to provide input to create a business case.)
Answer: Gap analysis compares the organization's current state against its desired future state to identify what must change to close the difference
Gap analysis requires comparing BOTH current and future states to identify the gap — it occurs during needs assessment/planning, and its findings typically inform (not replace) the solution scope statement.
Which of the following is an accurate statement regarding the application of MoSCoW prioritization based on stakeholder values? (Needs Assessment — Determine stakeholder values regarding the product, using elicitation techniques, in order to provide a baseline for prioritizing requirements.)
Answer: MoSCoW prioritization categorizes requirements into Must have, Should have, Could have, and Won't have (this time), based on elicited stakeholder values and relative importance
MoSCoW categorizes by these four priority tiers based on stakeholder value/importance — it is not based on alphabetical order, not every requirement is a 'must have,' and it is used across delivery approaches.
Which of the following scenarios BEST illustrates a correct understanding of the application of payback period analysis in evaluating an initiative? (Needs Assessment — Collect and analyze information from a variety of sources using valuation tools and techniques to contribute to determining the value proposition of the initiative.)
Answer: Payback period measures the length of time required for an initiative's cumulative benefits to equal its initial cost, helping assess how quickly the investment is recovered
Payback period measures time-to-recover-investment — a shorter payback period is typically viewed favorably (not less valuable), and this technique is one of several complementary financial valuation methods, not a replacement for all others.
Which of the following scenarios BEST illustrates a correct understanding of the distinction between the sponsor's role and the end user's role? (Needs Assessment — Identify stakeholders by reviewing goals, objectives, and requirements in order that the appropriate parties are represented, informed, and involved.)
Answer: The sponsor provides authorization and organizational backing for the initiative, while the end user interacts directly with the delivered solution in their day-to-day work
The sponsor provides authorization/backing, while the end user interacts with the solution directly — these are distinct roles (not the same individual by default), and this distinction has real bearing on engagement approach.
Which of the following is an accurate statement regarding the distinction between organizational goals and project objectives? (Needs Assessment — Collaborate in the development of project goals and objectives by providing clarification of business needs and solution scope in order to align the product with the organization's goals and objectives.)
Answer: An organizational goal is a broader, longer-term outcome the organization seeks, while a project objective is a specific, measurable target the current initiative is intended to achieve in support of that goal
A goal is broader/longer-term, while an objective is specific and measurable in support of that goal — objectives are narrower (not broader) than goals, and this distinction has real practical bearing on strategic alignment.
A business analyst is asked to justify a specific decision related to the establishment of a single source of truth for requirements documentation. Which justification is MOST accurate? (Planning — Select methods for document control by using documentation management tools and techniques in order to establish a standard for requirements traceability and versioning.)
Answer: Establishing a single, authoritative source of truth for requirements documentation helps prevent stakeholders from working off conflicting or outdated copies stored in different locations
A single source of truth prevents stakeholders from working off conflicting or outdated copies; multiple independent copies are NOT equally effective, this is a substantive (not decorative) practice, and applies regardless of the specific platform used.
Which of the following scenarios BEST illustrates a correct understanding of the purpose of a requirements change control process? (Planning — Select methods for requirements change control by identifying channels for communicating requests and processes for managing changes in order to establish standard protocols for incorporation into the change management plan.)
Answer: A requirements change control process establishes standard channels and procedures for requesting, evaluating, and deciding on proposed changes to previously approved requirements
A change control process establishes standard channels/procedures for evaluating proposed changes — it does not eliminate change (it manages it), is relevant across delivery approaches, and substantively affects change management effectiveness.
Why does the consideration of project and product risk when planning business analysis activities matter to effective business analysis practice? (Planning — Review the business case, and the project goals and objectives, in order to provide context for business analysis activities.)
Answer: Factoring in known project and product risk levels when planning business analysis activities helps determine how much rigor, review, and stakeholder engagement is warranted
Factoring in risk level helps calibrate planning rigor appropriately; risk DOES bear on planning, higher-risk initiatives typically warrant more (not identical) rigor, and this concern applies broadly, not solely to regulated industries.
A business analyst is explaining the factors used to determine the appropriate level of requirements traceability to a new team member. Which explanation is MOST accurate? (Planning — Define strategy for requirements traceability using traceability tools and techniques in order to establish the level of traceability necessary to monitor and validate the requirements.)
Answer: The appropriate level of traceability depends on factors such as regulatory requirements, project complexity, and the risk associated with an untracked or lost requirement
The appropriate traceability level should be tailored to regulatory context, complexity, and risk — an identical level regardless of context is not appropriate, and while it doesn't guarantee zero risk, this determination has real practical bearing on implementation.
Why does the importance of defining business metrics and acceptance criteria during planning rather than after delivery matter to effective business analysis practice? (Planning — Define business metrics and acceptance criteria by collaborating with stakeholders for use in evaluating when the solution meets the requirements.)
Answer: Defining business metrics and acceptance criteria during planning, rather than after delivery, helps avoid a biased or retroactively adjusted standard for evaluating whether the solution actually succeeded
Defining metrics/criteria upfront during planning avoids a retroactively biased standard — defining them only after delivery is LESS objective (not more), and this timing concern applies regardless of initiative duration.
Which of the following scenarios BEST illustrates a correct understanding of the establishment of a review cadence for requirements? (Planning — Develop a requirements management plan by identifying stakeholders, roles and responsibilities, communication protocols, and methods for eliciting, analyzing, documenting, managing, and approving requirements in order to establish a roadmap for delivering the expected solution.)
Answer: The requirements management plan establishes how frequently requirements will be reviewed and reassessed throughout the initiative, supporting timely identification of needed updates
Establishing a review cadence supports timely identification of needed updates; requirements are not automatically guaranteed to remain accurate indefinitely, this is a substantive (not decorative) practice, and applies across delivery approaches.
A business analyst is asked to justify a specific decision related to the selection of an appropriate specification format based on audience and content. Which justification is MOST accurate? (Analysis — Organize, categorize, and specify requirements using a defined set of attributes and requirements/design models (e.g., process flows, use cases, business rules) in order to produce a structured requirements specification.)
Answer: Selecting an appropriate specification format (e.g., narrative text, a formal use case, a visual model) depends on the specific audience's needs and the nature of the content being specified
Format selection should be driven by audience and content — no single format fits every situation, this substantively affects communication effectiveness (not purely stylistic), and applies to specifications of varying lengths.
Why does the use of a walkthrough to validate requirements with stakeholders matter to effective business analysis practice? (Analysis — Validate requirements by comparing them to the identified business need using techniques such as demonstration and walkthroughs, in order to ensure that requirements align with and support the business goals and objectives.)
Answer: A walkthrough involves guiding stakeholders through documented requirements or a related model, confirming in real time that the material reflects their actual intent
A walkthrough involves guiding stakeholders (not a solo BA review) through requirements in real time — it occurs during analysis (before full development), and resulting feedback should still be documented.
A business analyst is explaining the application of dependency analysis to uncover relationships between requirements to a new team member. Which explanation is MOST accurate? (Analysis — Analyze, decompose, and elaborate requirements using techniques such as dependency analysis, interface analysis, and data and process modeling, in order to collaboratively uncover and clarify product options and capabilities.)
Answer: Dependency analysis identifies which requirements rely on, or are affected by, other requirements, helping the team understand an appropriate sequence or grouping for delivery
Dependency analysis surfaces real relationships between requirements to inform sequencing/grouping — requirements are not assumed independent, this analysis occurs during analysis (before delivery), and is relevant across delivery approaches.
A business analyst is explaining the definition of a constraint affecting requirements or the proposed solution to a new team member. Which explanation is MOST accurate? (Analysis — Determine assumptions, dependencies, and constraints affecting the requirements and the proposed solution by analyzing the current and future business environment in order to support feasibility and design decisions.)
Answer: A constraint is a fixed limitation restricting the available options for the requirements or proposed solution (e.g., a mandated technology platform, a fixed budget, or a regulatory deadline)
A constraint is a fixed limitation on available options — this differs from a risk (an uncertain future event) and from an assumption (an unverified belief), and constraints can affect requirements/design, not solely schedule.
Key business analysis terms
- Business Analyst (BA): The role responsible for eliciting, analyzing, documenting, and validating requirements on behalf of stakeholders.
- Gap Analysis: Compares the organization's current state against its desired future state to identify what must change to close the difference.
- Business Case: The documented justification for an initiative, presenting the problem, solution options, expected costs and benefits, and a recommendation.
- Solution Scope Statement: Defines the high-level boundaries of what a proposed solution will and will not include.
- Stakeholder Register: A record of identified stakeholders including their role, interest, influence, and engagement approach.
- MoSCoW Prioritization: A technique categorizing requirements as Must have, Should have, Could have, and Won't have (this time).
- Kano Model: Categorizes product features as basic, performance, or delighter based on stakeholder value perception.
- Requirements Elicitation: The activity of drawing out requirements, including underlying needs stakeholders may not have consciously stated.
- Facilitated Workshop (JAD): Brings multiple stakeholders together to collaboratively elicit and reach consensus on requirements in real time.
- Document Analysis: Reviews existing artifacts (policies, reports, system documentation) to surface requirements without live stakeholder time.
- Prototyping: Provides a tangible, interactive representation of a proposed solution to surface stakeholder reactions before development.
- Requirements Management Plan: A roadmap for how requirements will be elicited, analyzed, documented, managed, and approved.
- Traceability Strategy: Defines how each requirement is tracked from origin through delivery and the level of traceability needed.
- Requirements Traceability Matrix (RTM): A tool maintaining structured links between requirements and their related design, test, and delivery artifacts.
- Change Control Board (CCB): Reviews, evaluates, and formally approves or rejects proposed changes to requirements.
- Single Source of Truth: One authoritative source of requirements documentation that prevents conflicting or outdated copies.
- Acceptance Criteria: Specific, testable conditions that confirm whether a requirement has actually been satisfied.
- Dependency Analysis: Identifies which requirements rely on or are affected by others to inform an appropriate delivery sequence.
- Interface Analysis: Identifies the points where a proposed solution must interact with other systems, processes, or actors.
- Use Case: A structured interaction between an actor and a system to achieve a goal, including alternative and exception flows.
- User Story: A concise unit of desired functionality (As a..., I want..., so that...), elaborated through acceptance criteria.
- Business Rule: A specific constraint or policy governing how the business operates, distinct from system behavior.
- Weighted Decision Matrix: Scores each option against multiple weighted criteria to compare competing product options objectively.
- Build-versus-Buy Analysis: Compares developing a custom solution internally against acquiring or configuring a commercial product.
- Assumptions Log: A maintained record documenting each assumption, its rationale, and its current validation status.
- Requirements Verification: Confirms a requirement meets defined quality criteria (unambiguous, complete, consistent, testable).
- Requirements Validation: Confirms that documented requirements align with and would satisfy the actual business need.
- Peer Review: Has another qualified individual examine documented requirements for quality issues the author may have missed.
- Walkthrough: Guiding stakeholders through documented requirements or a model to confirm they reflect actual intent.
- Scope Baseline: The approved requirement set against which any future proposed change is evaluated via change control.
- Impact Analysis: Evaluates a proposed change's effect on scope, schedule, cost, and previously approved requirements.
- Requirements Status Dashboard: A reporting method giving stakeholders a shared, current view of requirements progress.
- Configuration Control: Version and configuration techniques that keep a single, current, accurate requirements baseline.
- Solution Validation: Confirming the developed solution was built as specified, using testing, demonstration, or inspection.
- Benefits Realization: Measuring the solution's realized benefits against the targets defined in the original business case.
- Post-Implementation Review: An evaluation of a deployed solution's long-term performance and realized business value.
- Go/No-Go Decision: A decision, based on established acceptance criteria, to authorize transition, deployment, or closure.
- Elicitation Technique: A method (interview, workshop, survey, observation) used to draw out requirements from stakeholders.
- Payback Period: The length of time required for an initiative's cumulative benefits to equal its initial cost.
- Net Present Value (NPV): Discounts an initiative's expected future cash flows to their present-day value to gauge financial worth.
Frequently asked questions
How many questions are on the PMI-PBA exam?
The exam has 200 questions (175 scored plus 25 unscored pretest items) and you have 240 minutes (4 hours) to complete it.
What are the five domains and their weights?
Needs Assessment 18%, Planning 22%, Analysis 35%, Traceability & Monitoring 15%, and Evaluation 10%.
What are the eligibility requirements for the PMI-PBA?
Either a secondary degree plus 60 months of business-analysis experience, or a bachelor's degree plus 36 months, plus 35 contact hours of BA education in both cases.
Which domain should I focus on most?
The Analysis domain is the largest at 35% of the exam, so it deserves the most study time, followed by Planning at 22%.
Is the PMI-PBA Prep Hub free?
Yes. All 1,500 practice questions, flashcards, 50 case studies, and 5 mock exams are free to use in any modern browser, with progress saved locally on your device.
How should I study for the PMI-PBA exam?
Study by ECO domain, task, and enabler, drill the practice bank with detailed explanations, use flashcards for active recall, review case studies, and take full-length timed mock exams until you consistently score around 75% or higher.
PMI-PBA, PMP, CAPM, PMI-ACP, PMI-RMP and PMI are registered marks of the Project Management Institute, Inc. This is an independent study resource and is not affiliated with or endorsed by PMI.