Try 10 focused PMI-PBA questions on Analysis, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PMI-PBA |
| Topic area | Analysis |
| Blueprint weight | 35% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Analysis for PMI-PBA. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 35% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Analysis
A BA is defining validation metrics for the requirement below.
Requirements package excerpt
Business objective: Reduce payroll-support demand during pay-cycle changes
Requirement R-18: Employees must be able to update direct-deposit details in the self-service portal without HR assistance.
Rationale: Most related calls occur when employees cannot complete the update.
Validation point: Pilot test before production release
Which measure is most useful as an acceptance criterion for R-18?
Best answer: A
What this tests: Analysis
Explanation: The strongest metric is the one that directly tests the requirement itself: employees updating direct-deposit details without HR help. Because the exhibit specifies pilot validation before release, a direct task-completion measure is more useful than downstream outcomes, technical proxies, or general opinions.
When selecting a requirement measure, the best choice is the one closest to the stated requirement and easiest to verify at the planned validation point. Here, the requirement is about successful self-service completion without HR assistance, and the exhibit says validation will occur in a pilot before production. That makes a user task-completion metric the most useful acceptance criterion.
Measures such as call-volume reduction, system speed, or stakeholder satisfaction may still matter, but they are indirect or broader than the requirement being validated.
It directly measures whether users can perform the required self-service task during the planned pilot validation.
Topic: Analysis
A business analyst is reviewing a draft requirement package for a new contact center order lookup screen.
Draft excerpt:
Requirement: The screen should help agents quickly find orders and show useful customer information in an easy-to-use layout.
Acceptance criterion: Most agents can locate the correct order in a short time with minimal training.
Before sending this package to development, what is the most important improvement?
Best answer: A
What this tests: Analysis
Explanation: The main defect is vague wording. A requirement package for development should describe observable behavior and measurable criteria so the team can build, test, and validate the solution consistently.
This item tests requirement quality. The draft uses subjective phrases like “quickly,” “useful,” “easy-to-use,” and “short time,” which are open to interpretation and are not suitable for development or verification. Before baselining or handing work to delivery teams, the BA should rewrite the requirement and acceptance criterion so they are actionable and measurable.
A stronger version would specify things such as:
That makes the requirement clear for designers, developers, testers, and stakeholders. Adding traceability, source information, or governance controls is helpful, but those do not solve the core problem if the requirement itself is still vague.
Subjective terms such as “quickly,” “useful,” and “short time” are not testable, so the requirement needs measurable and observable wording.
Topic: Analysis
A BA is finalizing requirements for a customer self-service portal that must go live in 8 weeks before annual enrollment. A senior sales stakeholder wants facial-recognition login to improve adoption. Legal has confirmed customer images cannot be sent to external AI vendors under current policy, enterprise architecture has no approved internal biometric service, and the sponsor will not add budget or time for a new platform. What is the BEST BA action?
Best answer: D
What this tests: Analysis
Explanation: A requirement is infeasible when known constraints make it not realistically implementable within the approved solution context. Here, policy, architecture, budget, and schedule all prevent biometric login, so the BA should document that reality and recommend an achievable alternative instead of treating it as simple prioritization.
The core concept is distinguishing feasibility from priority. Priority answers, “How important is this requirement relative to others?” Feasibility answers, “Can this requirement be delivered within the current constraints?” In this scenario, the BA has explicit evidence that facial-recognition login cannot be implemented: legal prohibits the external option, no approved internal capability exists, and the sponsor will not authorize the time or funding needed to create one.
A sound BA response is to:
Simply pushing the item lower in priority would mislabel the problem. The issue is not that the requirement has less value; it is that it cannot be delivered under current conditions.
The requirement is blocked by confirmed policy and architecture constraints, so it should be treated as infeasible rather than merely lower priority.
Topic: Analysis
A bank is updating overdraft fee waivers in its mobile app. The draft acceptance criterion says, “Qualified customers receive the correct waiver during nightly processing.” In review, testers interpret “qualified” using account balance only, while operations managers also include customer segment, prior waivers, and cutoff time. The business analyst must refine the acceptance criteria so both groups evaluate the feature consistently before UAT. Which requirement package is the best fit?
Best answer: A
What this tests: Analysis
Explanation: The best fit is a decision table because the ambiguity is in how multiple business rules combine to determine eligibility. A structured rule model turns vague wording into measurable, testable acceptance criteria that both testers and business stakeholders can interpret the same way.
When acceptance criteria are being interpreted differently, the BA should replace vague phrases with explicit conditions, expected results, and boundary cases. Here, the issue is not screen design, ownership, or system scope; it is inconsistent interpretation of a rule-driven outcome. A decision table is well suited because it organizes combinations such as account balance, customer segment, prior waiver history, and cutoff time into clear expected waiver results.
This helps by:
The closest distractor is the prototype, but visualizing screens does not resolve rule ambiguity as effectively as a structured rule model.
A decision table makes each qualifying condition and resulting waiver outcome explicit, so business users and testers apply the same pass/fail logic.
Topic: Analysis
A business analyst is planning elicitation for a loan-origination update. Four senior underwriters handle complex approval exceptions using largely undocumented judgment, compliance requirements are already described in policy manuals, and 250 branch employees can provide input on screen usability. Which elicitation approach should the analyst AVOID?
Best answer: A
What this tests: Analysis
Explanation: The key is to match the technique to the stakeholder group and the type of requirement. Detailed exception logic held by only four experts is better explored through richer, interactive methods, so a questionnaire is the weakest fit.
Elicitation technique selection depends on how much depth, interaction, and context the requirement needs. Tacit decision logic and undocumented exceptions usually require probing follow-up questions, examples, and clarification, which interviews, workshops, or observation provide better than a questionnaire. In this scenario, observation fits the underwriters’ judgment-based work, document analysis fits already documented compliance rules, and surveys fit a large user population providing broad usability input. A questionnaire sent to four expert underwriters is an anti-pattern because it limits discovery of rationale, exceptions, and hidden rules. The closest acceptable choice is surveying branch employees, because broad feedback from many users is exactly where surveys are useful.
Questionnaires are weak for uncovering rich, tacit business rules from a small set of expert stakeholders.
Topic: Analysis
A BA is revising the requirements baseline for two releases after a budget cut. The traceability record shows:
R-31 Override audit log — accepted; compliance note: must be implemented and validated before any override capability is releasedR-24 Manager override — accepted; trace link: depends on R-31R-18 Risk service — accepted for Release 1R-42 Exception dashboard — accepted; trace link: depends on R-18Which proposed allocation should the BA flag as breaking a dependency or stakeholder commitment?
R-24 to Release 1 and R-31 to Release 2R-42 to Release 2 and keep R-18 in Release 1R-24 and R-31 together to Release 2R-31 to Release 1 and keep R-24 in Release 2Best answer: A
What this tests: Analysis
Explanation: The invalid allocation schedules the manager override before the audit log it depends on and before compliance’s release condition is satisfied. When creating or revising a requirements baseline, dependency links and stakeholder commitments must still hold after reallocation.
Requirement allocation is not just a prioritization exercise; it must preserve traced dependencies and explicit stakeholder commitments in the baseline. Here, R-24 has a dependency link to R-31, and compliance has stated that no override capability can be released until the audit log is implemented and validated. Moving R-24 earlier than R-31 breaks both the trace link and the stakeholder commitment, so that proposed baseline is not acceptable.
A dependent requirement can be moved to a later release while its prerequisite stays earlier, or both can move together through normal change control. What cannot happen is allocating the dependent item to a release that occurs before the prerequisite or before the committed release condition is met.
This places the override feature before its traced prerequisite and violates the compliance release condition tied to the audit log.
Topic: Analysis
A release 1 requirements baseline (version 2.1) has been approved for a customer service platform. The sponsor has cut the schedule by two weeks and asked the business analyst to recommend the first requirement to defer through change control. The analyst must preserve compliance coverage and avoid breaking downstream trace links.
| ID | Requirement | Business value | Downstream trace links | Lifecycle status |
|---|---|---|---|---|
| R-101 | Retain approval history for 7 years | Mandatory | 4 test cases, operations procedure | Build started |
| R-108 | Auto-create case from email | High | Enables R-112, training script TS-3 | Build started |
| R-115 | Export dashboard data to CSV | Low | 1 report mockup only | Not started |
| R-119 | Show customer risk score on profile | Medium | UAT scenario U-6, KPI K-2 | Design complete |
Which requirement should be deferred first?
Best answer: B
What this tests: Analysis
Explanation: The best candidate to defer first is the low-value requirement with the fewest downstream trace links and least implementation progress. That preserves the approved baseline’s critical compliance and dependency coverage while minimizing rework and change impact.
When constraints tighten after baselining, the business analyst should recommend deferring the requirement that delivers the least value and causes the smallest controlled impact across trace links, dependencies, and lifecycle artifacts. Here, exporting dashboard data to CSV is low value, has only a single mockup tied to it, and has not started, so it is the cleanest item to move out of the current baseline.
By contrast, the other requirements have stronger reasons to stay:
After selecting the item, the analyst would still process the deferral through formal change control and update the baseline version and traceability records.
It has the lowest business value, no meaningful downstream dependency coverage, and work has not started, so deferring it creates the least baseline disruption.
Topic: Analysis
A BA is supporting requirements for a customer onboarding portal. During a prototype review, operations says exception cases are missing, compliance says the design violates a seven-year consent retention rule, and sales says the proposed flow will reduce the conversion rate targeted in the business case. The requirements package had already been approved by the product owner and development lead. What is the most likely underlying BA gap?
Best answer: D
What this tests: Analysis
Explanation: This feedback is a validation signal, not just review friction. Missing exception handling, conflicting compliance rules, and misalignment to the business case show the requirements were not sufficiently validated for completeness, accuracy, consistency, and alignment with expected value.
The core issue is inadequate requirements validation. Validation is used to confirm that requirements are complete, correct, internally consistent, and aligned with business objectives before development proceeds too far. In this scenario, operations identified missing requirements, compliance identified conflicting or incorrect requirements, and sales identified misalignment with the value proposition in the business case. Those are classic signs that the BA did not validate the requirements package broadly enough with the right stakeholders and against key business rules and success measures.
Approval by only the product owner and development lead is not enough when operations, compliance, and sales each have material needs and constraints. The closest alternative is change control, but these comments point to defects in the original requirements, not merely new requests.
The feedback exposes missing, conflicting, and misaligned requirements, which indicates inadequate validation against stakeholder needs, business rules, and value goals.
Topic: Analysis
A business analyst is elaborating this high-level requirement for a retailer’s returns system: “Store associates must complete an in-store return in under 90 seconds while capturing a return reason and a manager override when policy requires one.” Current returns policy already defines which transactions need a manager override. Which proposed acceptance criterion is NOT appropriate?
Best answer: B
What this tests: Analysis
Explanation: Detailed acceptance criteria should be specific, measurable, and verifiable against the requirement. The statement about being user-friendly and visually appealing is vague and subjective, so it cannot be consistently tested or used for solution acceptance.
When deriving acceptance criteria from a high-level requirement, the analyst should turn broad business intent into objective conditions that can be validated. In this case, the requirement already points to three testable areas: cycle time, required override behavior, and required data capture. Good acceptance criteria therefore describe observable outcomes such as completing the return within 90 seconds, blocking finalization when an override is required, and recording the reason and override information.
The closest trap is wording that sounds customer-focused or usability-focused but lacks a clear pass/fail standard.
This is subjective and not directly testable, so it does not function as a detailed acceptance criterion.
Topic: Analysis
A BA is elaborating requirements for a bank’s online account-opening process. Draft requirements include applicant eligibility rules, required customer data fields, an interface to a third-party identity service, and the wording shown on the final confirmation page. Using dependency analysis, which requirement should the BA NOT clarify first?
Best answer: A
What this tests: Analysis
Explanation: Dependency analysis prioritizes requirements that many other requirements rely on, such as business rules, shared data definitions, and interface details. Final confirmation wording does not unlock other analysis work, so it is the least appropriate item to clarify first.
When using dependency analysis, clarify upstream requirements first: the ones that drive process paths, constrain data capture, or affect multiple downstream requirements and test cases. In this scenario, eligibility rules determine who can open an account and what path applies; shared applicant data definitions affect forms, validations, and traceability; and the identity-service interface constrains inputs, outputs, and error handling. By contrast, the confirmation page wording is largely a presentation detail that depends on those earlier decisions already being understood. It can be elaborated later without blocking the analysis of core product behavior. The key takeaway is to start with requirements that unlock or constrain many others, not with isolated UI text.
Confirmation text is a downstream presentation detail, while the other requirements drive or constrain multiple requirements and should be clarified earlier.
Use the PMI-PBA Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the PMI-PBA guide on PMExams.com, then return to PM Mastery for timed practice.