Free PMI-PBA Full-Length Practice Exam: 200 Questions

This free full-length PMI-PBA practice exam includes 200 original PM Mastery questions across the exam domains.

The questions are original PM Mastery practice questions aligned to the exam outline. They are not official exam questions and are not copied from any exam sponsor.

Count note: this page uses the full-length practice count maintained in the Mastery exam catalog. Some exam sponsors publish total questions, scored questions, duration, or unscored/pretest-item rules differently; always confirm exam-day rules with the sponsor.

For concept review before or after this set, use the PMI-PBA guide on PMExams.com.

How to run this diagnostic

Set a 240-minute timer and answer the 200 questions in one sitting if you want a true endurance check. Track misses by business-analysis domain: needs assessment, planning, analysis, traceability/monitoring, or evaluation.

Suggested timing checkpoints:

Exam snapshot

Full-length exam mix

Practice questions

Questions 1-25

Question 1

Topic: Analysis

A business analyst is preparing approval for a requirements baseline for a customer onboarding solution. Compliance rules are complete and owned by Legal, branch workflow requirements will mature after regional workshops, and interface requirements depend on a vendor prototype; each area has a different approver, and cross-functional impacts must still be managed. Which use of staged sign-off is INCORRECT?

• A. Freezing each section separately before unresolved cross-functional conflicts are analyzed.
• B. Having domain approvers sign their areas before an integrated baseline confirmation.
• C. Approving completed compliance requirements first, with traced dependencies to later workflow requirements.
• D. Sequencing sign-off by requirement set when each package meets agreed review criteria.

Best answer: A

What this tests: Analysis

Explanation: Staged sign-off is useful when requirements mature at different times or require approval from different authorities. It is inappropriate when used to baseline sections before end-to-end conflicts and impacts are understood, because sign-off should support a coherent, agreed baseline.

The core concept is that staged sign-off is a control method for managing different approval timings, stakeholder ownership, and requirement maturity levels. In this scenario, compliance, workflow, and interface requirements do not become ready at the same time, so approving them in stages can be appropriate if each package meets agreed quality criteria and dependencies are traced.

What staged sign-off should not do is replace integration analysis. If cross-functional conflicts are still unresolved, freezing sections separately creates a false baseline and weakens stakeholder consensus, traceability, and later change control. Domain-by-domain approval can still work when it is followed by integrated confirmation of the full baseline.

The key takeaway is that staged sign-off manages readiness differences; it should not be used to hide unresolved end-to-end impacts.

Staged sign-off should reflect maturity and ownership, not bypass unresolved dependencies or conflict analysis.

Question 2

Topic: Analysis

A business analyst finishes a requirements review, and key stakeholders reply “approved” in the meeting chat. The project manager wants to send the package to design and test teams immediately. The shared repository currently contains two recent versions of the requirements package with minor wording differences. What should the business analyst verify first before treating the sign-off as a usable baseline?

• A. That the approval applies to one finalized, version-controlled requirements package
• B. That the sponsor is ready to announce the approval to all stakeholders
• C. That the team has estimated the impact of future requirement changes
• D. That design and test leads agree the package is detailed enough

Best answer: A

What this tests: Analysis

Explanation: The first check is whether stakeholder approval is tied to a single identified version of the requirements package. Without that, the sign-off is ambiguous and cannot serve as a reliable baseline for design, testing, traceability, or change control.

A requirements sign-off is only useful if it establishes an approved baseline that everyone can reference consistently. In this scenario, the repository contains two recent versions, so the key risk is not whether people generally support the requirements, but whether they approved the same artifact. The business analyst should first confirm that the sign-off points to one finalized, version-controlled package and that this is the version to be baselined for downstream work.

Once that is clear, design, testing, traceability, and change requests can all align to the same approved source. If the approved version is unclear, any later work may be based on different content, making the sign-off ineffective even if stakeholders intended to approve.

Sign-off only creates a usable baseline when it clearly references the exact approved version that downstream work and change control will use.

Question 3

Topic: Planning

A BA is defining business metrics and acceptance criteria for a hybrid customer onboarding initiative. Compliance controls must go live together at final cutover, but customer-facing features may be released every two weeks. The sponsor asks for one evaluation approach for the whole effort, while the product owner asks for sprint-level criteria. Before drafting the metrics and acceptance criteria, what should the BA verify first?

• A. Which training materials users want first
• B. How each capability will be delivered and accepted
• C. Which regression tests QA will automate
• D. What dashboard format executives prefer

Best answer: B

What this tests: Planning

Explanation: The BA should first confirm the delivery and acceptance approach for each capability. Metrics and acceptance criteria must be tailored to the evaluation point: predictive work often uses end-to-end acceptance at release, while iterative or incremental work also needs criteria for each story, sprint, or increment.

The core concept is aligning business metrics and acceptance criteria to the delivery approach and the point at which value or readiness will be evaluated. In this scenario, some capabilities are delivered as a single cutover event, while others are delivered in short increments. That means one uniform set of criteria may be inappropriate.

The BA should first clarify:

• which capabilities are delivered predictively versus incrementally
• when each capability will be reviewed or accepted
• whether stakeholders need increment-level criteria, final release criteria, or both

Only after that can the BA define suitable measures, such as sprint-level usability or adoption indicators for incremental features and end-to-end compliance readiness for final cutover. Asking about testing, reporting format, or training too early skips the key tailoring decision.

Delivery and acceptance points determine whether criteria should be defined for final solution approval, each increment, or both.

Question 4

Topic: Evaluation

A BA is seeking sign-off to deploy a new loan-origination solution. The BA presents a summary showing UAT passed, all exit criteria were met, and no high-severity defects remain. The sponsor asks whether the cycle-time target in the business case was achieved, operations asks for proof of training and support readiness, and compliance asks which approved business rules were validated. Requirements were previously baselined and changes were controlled, yet approval is repeatedly deferred. What is the most likely underlying BA gap?

• A. No stakeholder consensus existed on whether deployment should occur.
• B. No remediation plan existed for unresolved UAT defects.
• C. No approved requirements baseline existed for the solution.
• D. No consolidated sign-off package linked validation evidence to requirements, objectives, and readiness.

Best answer: D

What this tests: Evaluation

Explanation: The issue is not that testing failed or scope was uncontrolled. The BA showed only a partial view of readiness, instead of a sign-off evidence package that connects validated requirements, acceptance criteria, business-case measures, business rules, and operational readiness for each approver.

For solution sign-off, stakeholders typically need more than a statement that UAT passed. They need an evidence package that supports the decision to deploy by showing that the developed solution satisfies approved requirements and acceptance criteria, addresses the business need, and is operationally acceptable.

In this scenario, each approver is asking for a different type of decision evidence:

• the sponsor wants business outcome evidence
• operations wants transition and readiness evidence
• compliance wants rule-validation evidence

That pattern points to a packaging gap, not a testing or scope-control failure. A complete sign-off package would usually trace approved requirements and business rules to validation results, summarize unresolved gaps or defects, and include readiness items such as training, support, and deployment impacts. The closest distractor is the lack of consensus, but that is the symptom created by missing decision-ready evidence.

Sign-off is stalling because stakeholders need a complete evidence package that ties approved requirements and acceptance criteria to test results, business outcomes, and operational readiness.

Question 5

Topic: Analysis

A business analyst is comparing three customer onboarding options. A preliminary evaluation shows one option has the lowest cost, another has the fastest deployment, and a third has the strongest compliance controls. The steering committee asks for a recommendation tomorrow, but no agreed decision rule was documented. The sponsor points to the business case goal of reducing customer abandonment and audit findings, while senior stakeholders disagree on what matters most. What should the business analyst verify first before finalizing how to communicate the option evaluation results?

• A. Obtain more detailed cost estimates for each option.
• B. Confirm the decision criteria, success measures, and relative weighting with the decision makers.
• C. Ask each stakeholder group to name its preferred option.
• D. Prepare a final recommendation from the current scorecard.

Best answer: B

What this tests: Analysis

Explanation: The key first step is to confirm the basis for the decision. When stakeholders value different outcomes and no decision rule has been agreed, the business analyst should verify the criteria, measures, and weighting so the evaluation results can be communicated in a way that supports an actual decision.

This question tests whether option evaluation results are being communicated in a decision-ready way. If stakeholders disagree on what matters most, the business analyst should first align on the decision framework: the evaluation criteria, the success measures tied to the business case, and the relative weighting or priority of those criteria. Only then can the analyst present results that are meaningful to the decision makers.

In this scenario, cost, speed, and compliance each favor a different option. That means the issue is not missing detail first; it is missing agreement on how options will be judged. A recommendation based on unconfirmed assumptions can mislead stakeholders or trigger avoidable conflict. The closest distractors gather useful input, but they do not resolve the core problem of unclear decision priorities.

Without agreed evaluation criteria and priorities, any recommendation may not support an informed stakeholder decision.

Question 6

Topic: Analysis

A BA is validating a baselined requirements package through a prototype demo for a claims portal. During the demo, adjusters show that one claim may involve multiple policy holders, but the approved requirements, data model, and linked test cases all assume a single policy holder. The project manager wants to keep the release date unchanged. What should the BA do next to confirm completeness and accuracy while preserving traceability and baseline control?

• A. Add a new test case for multiple policy holders.
• B. Defer the gap to a post-release enhancement log.
• C. Revise the prototype and notify the team by email.
• D. Submit a change request, perform impact analysis, and version the revised requirements.

Best answer: D

What this tests: Analysis

Explanation: Prototype validation is used to confirm that requirements are complete and accurate in a realistic workflow. Because the gap was found in a baselined package with downstream trace links, the BA should handle it through formal change control, impact analysis, and document versioning.

A prototype demo is a validation technique for checking whether requirements fully and accurately represent business needs. In this scenario, the demo revealed that the approved requirements are incomplete and inaccurate because they do not cover multiple policy holders, and that error already affects traced artifacts such as the data model and test cases.

• Record the finding as a controlled change.
• Analyze impacts on linked requirements and downstream artifacts.
• Update and version the requirements package.
• Revalidate the revised content with stakeholders.

This preserves baseline integrity and keeps lifecycle status and trace links reliable. Simply changing testing or the prototype would address only a downstream symptom while leaving the approved requirements inconsistent.

Because the demo exposed a gap in a baselined requirement set, the BA should use controlled change, trace downstream impacts, and update the approved version.

Question 7

Topic: Traceability and Monitoring

During a hybrid customer-portal project, a privacy officer submits a requirement to mask customer email addresses on service screens. The development lead says the screen change depends on an identity-service update, and the sponsor wants evidence of which approved requirements are truly ready for UAT. What should the business analyst prioritize in the traceability artifact?

• A. Add the requirement to meeting notes now and update traceability after UAT begins
• B. Mark the related screen requirements complete and track the dependency only in the risk log
• C. Link the requirement only to planned test cases so readiness can be reported quickly
• D. Record the requirement’s source, current status, and dependency on the identity-service change

Best answer: D

What this tests: Traceability and Monitoring

Explanation: A traceability artifact must show where a requirement came from, where it stands, and what it depends on. Recording the source, status, and dependency gives the sponsor reliable evidence of delivery readiness and prevents a false assumption that the requirement is ready for UAT.

The core concept is complete requirement traceability. In this scenario, the BA needs more than a simple note that a new privacy requirement exists; the artifact must show the requirement’s source, its current lifecycle status, and its relationship to other items, including the dependency on the identity-service update. That is what allows stakeholders to see whether the requirement is approved, in progress, blocked, or actually ready for UAT.

A good traceability entry here should capture:

• the originating stakeholder or source
• the current status of the requirement
• the dependency between the screen change and identity-service update
• links to affected related requirements or downstream validation work

Options that delay updates, overstate completion, or trace only to testing weaken evidence that requirements are delivered as stated. The closest distractor improves reporting speed, but it still omits key origin and dependency information.

This captures the new requirement accurately and shows both its origin and the dependency that affects delivery readiness.

Question 8

Topic: Planning

A business analyst is reviewing a draft requirements management plan for a hybrid customer onboarding project. The draft defines stakeholders, elicitation workshops, document templates, repository/versioning rules, and weekly communication updates. The sponsor notes that compliance and operations frequently request late changes, and only approved requirements may be built. Which missing item is the most material gap in the plan?

• A. A post-implementation benefits dashboard for adoption and cycle time
• B. A prototype demonstration schedule for end-user feedback sessions
• C. A requirements baseline and change approval process with decision rights and impact criteria
• D. A test execution summary showing pass rates by release

Best answer: C

What this tests: Planning

Explanation: The biggest gap is the missing method for approving, baselining, and controlling requirement changes. In this scenario, frequent late requests and the rule that only approved requirements may be built make governance of requirements more critical than downstream evidence or delivery artifacts.

A requirements management plan should do more than describe elicitation and documentation. It also needs a clear method for managing and approving requirements, including who can approve changes, how impacts are assessed, and when a new or revised baseline is established. Those elements are essential when stakeholders commonly introduce late changes and the team must prevent unapproved work from entering delivery.

Without defined approval and change control rules, versioning and communications alone do not protect scope integrity. A benefits dashboard, prototype schedule, or test summary may be useful elsewhere in the life cycle, but they do not close the core planning gap in this draft. The key takeaway is that requirements governance is the missing control, not additional reporting or validation outputs.

The plan must define how requirements are approved, baselined, and changed, especially when late changes are expected and only approved requirements can proceed.

Question 9

Topic: Evaluation

A BA is preparing sign-off for a new supplier onboarding portal that must go live before peak ordering season. Business users confirm the solution meets core functional acceptance criteria. However, the operations manager will approve only if quick-reference guides are distributed before go-live, and the compliance lead accepts one minor report-format defect as an exception if it is fixed in the next release. Governance requires formal sign-off records to state any conditions, exceptions, owners, and target dates before deployment. What should the BA do BEST?

• A. Ask the sponsor to provide final approval because functional criteria are already satisfied.
• B. Update the issue log with the defect and training tasks, then mark the solution approved.
• C. Create a conditional sign-off record with conditions, exception details, owners, dates, and authorized approvals.
• D. Recommend delaying deployment until the training item and defect are fully closed.

Best answer: C

What this tests: Evaluation

Explanation: The stakeholders are not giving unconditional approval; they are willing to proceed only with stated conditions and an accepted exception. The BA should formally document that decision in the sign-off record, including ownership and timing, so deployment can proceed with clear accountability and governance compliance.

The key concept is documenting sign-off accurately based on the actual stakeholder decision. In this case, the solution is acceptable for deployment, but only with specific conditions and one explicit exception. A BA should capture that as conditional approval, not as full approval and not as a rejection.

The sign-off documentation should clearly state:

• the approval conditions that must be met before go-live
• the accepted exception and its impact
• the owner for each follow-up item
• the target date or release for resolution

This approach supports deployment readiness, preserves auditability, and ensures decision-makers understand the residual risk. Simply logging the items or seeking a broad override does not document the approval basis correctly, while delaying deployment ignores that stakeholders have already defined an acceptable path forward.

This correctly documents conditional approval and the accepted exception so deployment can proceed under proper governance control.

Question 10

Topic: Planning

A BA team must maintain two requirements packages in parallel: an internal operating-procedure specification and a vendor-facing functional package. Many requirements are shared, updates occur weekly, and compliance requires a full history of approved changes. Which document control method is the best fit for keeping the parallel versions synchronized?

• A. Use a controlled repository with unique IDs and published document views
• B. Freeze both documents until phase-gate change reviews
• C. Keep separate files with naming rules and weekly manual reconciliation
• D. Assign separate owners and merge redlined edits after approvals

Best answer: A

What this tests: Planning

Explanation: When the same requirements must appear in multiple packages and change frequently, the best approach is a single source of truth in a controlled repository. Unique requirement IDs, version history, and published document views keep both packages aligned while preserving approval and audit records.

When parallel documents contain the same requirements, synchronization is mainly a document-control and versioning problem. The strongest method is to store each requirement once in a controlled repository, give it a unique identifier, and publish different document views or packages for different audiences. That reduces duplication, supports traceability, and preserves a reliable approval history.

• Maintain one approved requirement record per need.
• Control edits with version history and check-in/check-out.
• Publish the internal and vendor packages from the same source.
• Use the repository workflow to capture approvals and changes.

Manual comparisons and delayed merges can work for low-change environments, but they create drift when updates are frequent.

A single controlled repository maintains one approved source while producing multiple packages with version history and auditability.

Question 11

Topic: Planning

A retailer’s business case for a returns automation initiative assumes all regions can use one approval workflow and that the existing ERP provides the same return-status codes everywhere. While planning business analysis work, the analyst learns one region has stricter refund controls and custom ERP mappings. The sponsor still wants the original timeline. What should the business analyst do next?

• A. Baseline the common workflow requirements now and handle regional differences through later change requests.
• B. Keep the original elicitation plan and record the issue in version-controlled meeting notes.
• C. Pause analysis until the sponsor republishes the business case with revised assumptions.
• D. Target elicitation to the affected region and ERP team, and trace the assumptions to impacted requirements before baselining them.

Best answer: D

What this tests: Planning

Explanation: Business case assumptions should directly influence whom the analyst engages, what dependencies are examined, and which requirements can be safely baselined. When a key assumption is doubtful, the analyst should plan focused elicitation and trace its impact before locking requirements.

The core concept is that business case assumptions are planning inputs, not background trivia. Here, the assumptions about a single workflow and consistent ERP status codes are already shown to be uncertain, so the analyst should immediately adjust elicitation and analysis planning around the affected region and technical dependency. Tracing those assumptions to impacted process, rule, and interface requirements helps ensure downstream impact analysis is possible and prevents baselining requirements that may soon change.

A sound response is to:

• identify the stakeholders needed to validate the assumptions
• trace the assumptions to dependent requirements and artifacts
• defer baselining of affected requirements until analysis is complete

Simply documenting the issue or waiting passively does not provide controlled planning. The closest distractor is baselining the common requirements first, but that weakens baseline discipline because the suspected exception may alter the supposed common design.

This uses the business case assumptions to reshape elicitation and analysis planning while preserving traceability and preventing premature baselines.

Question 12

Topic: Analysis

A business analyst is preparing a requirements baseline approval package for a loan-origination process redesign. Operations, compliance, and IT leads will review it tomorrow, and the sponsor wants only baseline information needed to make an approval decision. Which item should NOT be presented as part of the approval request?

• A. Detailed technical design decisions and developer task assignments
• B. Acceptance criteria, priority, and approval-impacting open issues
• C. Baseline version, scope boundaries, assumptions, and dependencies
• D. Traceability to objectives, source, and rationale

Best answer: A

What this tests: Analysis

Explanation: Before requesting sign-off, stakeholders need to see exactly what requirements are being approved, why they exist, and what conditions could affect that decision. Technical design choices and developer assignments belong to later solution design or delivery planning, not to the requirements baseline approval package.

The core concept is that a requirements baseline approval request must give approvers enough information to evaluate the content, purpose, scope, and control of the baseline. That usually includes a versioned baseline, clear scope boundaries, traceability to business objectives and requirement sources, priorities, acceptance criteria, and any assumptions, dependencies, or unresolved issues that could influence approval.

Detailed technical design decisions and task assignments are different artifacts. They describe how the solution may be built, not what business requirements stakeholders are formally approving. Mixing implementation detail into baseline approval can distract from the approval decision and create confusion about what is actually baselined.

A close distractor is the inclusion of open issues, but those should be visible when they could affect approval or require conditions on sign-off.

These are implementation-planning details, not baseline information required for stakeholders to approve the requirements.

Question 13

Topic: Analysis

A business analyst is finalizing the first release baseline for a regulated insurance customer portal. The product owner says the draft allocation is ready for sign-off.

Exhibit: Allocation draft

ID    Requirement                       Depends on   Stakeholder note                         Proposed release
R-21  Update billing address online     R-27         Compliance approved only with audit log  Release 1
R-27  Audit log for customer changes    —            Required for regulated profile changes   Release 2
R-31  View invoice history              —            Desired if capacity remains              Release 1
R-34  Download annual statement PDF     R-31         No special commitment                    Deferred

Based on the exhibit, what is the best action?

• A. Keep Release 1 intact and validate the gap during user acceptance testing
• B. Baseline the draft and record the dependency as a project risk
• C. Revise the allocation before baselining Release 1
• D. Defer R-31 first because it is the least committed requirement

Best answer: C

What this tests: Analysis

Explanation: The draft allocation is not ready for baseline because one Release 1 requirement depends on a Release 2 requirement, and the stakeholder note makes that dependency a commitment condition. A BA should resolve that conflict before sign-off rather than treat it as a later delivery or testing issue.

This is a requirements allocation and dependency analysis issue. When creating a baseline, the BA must ensure that accepted requirements can be delivered in the proposed release without violating prerequisite relationships or explicit stakeholder commitments. Here, R-21 is placed in Release 1, but it depends on R-27, which is planned for Release 2. The exhibit also states that compliance approved R-21 only with the audit log, so the proposed allocation breaks both a dependency and a stakeholder commitment.

The appropriate response is to rework the allocation before baselining, such as moving both requirements into the same release or deferring the dependent requirement. Simply logging the issue, testing around it later, or deferring an unrelated item does not fix the baseline conflict.

R-21 cannot be committed to Release 1 because its required dependency and explicit compliance condition are both allocated later.

Question 14

Topic: Analysis

A BA is preparing a requirements package for a claims-processing portal. One requirement states: The claim summary screen shall be user-friendly and load fast enough for agents during peak periods. The development lead asks whether the requirement is ready to be baselined. Which review finding identifies the most serious defect in this specification?

• A. No measurable acceptance criteria define “user-friendly” or “fast enough”.
• B. The business rationale is not included in the requirement text.
• C. The requirement does not name the stakeholder who requested it.
• D. The specification excerpt does not include a screen prototype.

Best answer: A

What this tests: Analysis

Explanation: The key defect is that the requirement is not measurable or actionable. Terms like “user-friendly” and “fast enough” are subjective, so developers and testers cannot build or verify the feature consistently.

For a requirement specification to be suitable for development, it must be clear, testable, and measurable. In this case, the requirement uses vague terms that leave too much room for interpretation. Without defined acceptance criteria such as response-time thresholds, user tasks, error tolerances, or usability measures, the team cannot confirm whether the solution meets the requirement.

Missing rationale or requester information can weaken traceability, but those gaps do not usually prevent a team from understanding what to build if the requirement itself is precise. Likewise, a prototype can help clarify design, but it is not mandatory when the written requirement is already unambiguous. The most serious defect here is unverifiable wording.

This is the most serious defect because the requirement is ambiguous and not testable, so development and validation cannot reliably determine done.

Question 15

Topic: Needs Assessment

A BA is asked to provide input to a business case for a retail bank’s contact center problem within 2 weeks. Customer complaints and call abandonment have risen for 6 months, but operations, training, and IT each claim a different cause. Governance requires evidence of likely drivers before defining solution scope. What is the best business analysis action?

• A. Conduct a gap analysis between current and target service levels
• B. Use trend analysis on complaints and abandonment rates over time
• C. Perform 5 Whys with the contact center manager to isolate one root cause
• D. Facilitate a fishbone analysis with key stakeholders using recent performance data

Best answer: D

What this tests: Needs Assessment

Explanation: The situation calls for a technique that can organize and test several possible causes across functions. Fishbone analysis is most appropriate because stakeholders disagree on whether the issue is related to people, process, training, or technology, and the BA needs evidence before defining scope.

The core concept is choosing a problem analysis technique that matches the decision need. Here, the BA must identify likely causes of a worsening business problem, quickly, across multiple stakeholder groups, and before proposing solution scope. A fishbone analysis is designed for exactly that: it structures potential causes into categories such as process, technology, people, policy, and measurement so the team can examine competing explanations together.

A good fit exists when:

• several plausible causes exist
• stakeholders disagree on the source
• the BA needs structured cause exploration
• solution scope should not be defined yet

A 5 Whys approach is stronger when one symptom and one likely causal chain are being explored in depth, while gap analysis and trend analysis describe performance differences or patterns rather than systematically uncovering cross-functional root causes.

A fishbone analysis best fits a situation with multiple plausible contributing causes that must be explored across categories before scoping a solution.

Question 16

Topic: Traceability and Monitoring

On a hybrid claims-processing project, the business analyst must update requirement statuses in the traceability tool using four lifecycle states: approved, implemented, validated, and closed. Which status update practice is INCORRECT?

• A. Mark implemented after the linked story is delivered and the release lead confirms it is in the build.
• B. Mark approved after the designated approver signs the baseline and the decision is recorded.
• C. Mark validated after test results meet acceptance criteria and the process owner confirms business fit.
• D. Mark closed after coding finishes and no stakeholder raises new questions that week.

Best answer: D

What this tests: Traceability and Monitoring

Explanation: The incorrect practice is closing a requirement based only on development completion and lack of recent comments. A requirement should be closed only after objective evidence shows the needed lifecycle steps are complete and the traceability record supports closure.

In traceability and monitoring, each lifecycle status should be supported by evidence from the right source before the BA updates it. “Approved” typically needs formal authorization or baseline sign-off by the designated approver. “Implemented” needs proof the requirement was actually built, configured, or included in the delivered solution item. “Validated” needs test or review results showing acceptance criteria were met, often with confirmation from the appropriate business stakeholder. “Closed” comes after the requirement has completed the necessary prior states, any open issues are resolved or dispositioned, and the traceability artifact reflects that completion. Finished coding and stakeholder silence are weak proxies, not evidence.

The key takeaway is to update lifecycle status based on recorded, objective proof rather than assumption or elapsed time.

Closure requires objective evidence that the requirement completed its lifecycle, not just finished coding and temporary silence.

Question 17

Topic: Analysis

A business analyst is finalizing the Release 1 requirements baseline for a claims platform. The team can implement only three accepted requirements before peak season. The business case success measures are to comply with a new audit rule by October 1 and reduce claim triage time by at least 20%.

Which allocation proposal should the BA recommend for the Release 1 baseline?

• A. Baseline intake form, auto-routing rules, and photo upload
• B. Baseline intake form, auto-routing rules, and audit history log
• C. Baseline audit history log, photo upload, and duplicate-claim check
• D. Baseline intake form, audit history log, and duplicate-claim check

Best answer: B

What this tests: Analysis

Explanation: The BA should recommend the set that preserves the business case, not the one that satisfies the most vocal stakeholders. Including the intake form, auto-routing, and audit history log is the only proposal that delivers the required operational value and the mandatory compliance outcome.

This tests requirements allocation against the value proposition. When creating a baseline under scope constraints, the BA should first protect nonnegotiable outcomes, then select the mix of accepted requirements that best delivers the stated business value while honoring dependencies.

• The audit history log is mandatory because compliance is a stated success measure.
• Auto-routing provides the largest triage improvement, but it requires the intake form.
• Intake form plus auto-routing gives 20% total triage reduction, meeting the target.
• Adding photo upload instead of the audit log improves usability but breaks compliance.

A proposal that improves customer experience or reduces payment leakage can still be the wrong baseline if it does not preserve the business case measures.

This combination is the only one that satisfies the compliance requirement, achieves the 20% triage target, and respects the dependency for auto-routing.

Question 18

Topic: Planning

A business analyst is finalizing elicitation plans for a claims-processing improvement initiative when the sponsor changes the primary objective from reducing operating cost to improving customer retention through faster claim decisions. Workshops with operations are already scheduled, and the current business analysis plan emphasizes internal efficiency requirements. Which action should the business analyst NOT take?

• A. Adjust business analysis priorities and contingency plans to reflect the new objective
• B. Communicate likely impacts on stakeholder focus, requirements, and planned analysis work
• C. Revisit the business case and success measures before continuing detailed planning
• D. Continue with the original plan to avoid disrupting scheduled activities

Best answer: D

What this tests: Planning

Explanation: When project goals change after planning has started, the business analyst should realign business analysis work to the updated objective. The action to avoid is blindly following the original plan, because it can drive elicitation, prioritization, and contingency decisions toward outdated value expectations.

The core concept is maintaining alignment between business analysis activities and the current business case, goals, and success measures. Once the sponsor shifts the objective from cost reduction to customer retention, the BA should reassess what information is most important, which stakeholders now matter most, and what risks or contingencies need more attention.

A sound response is to:

• review the updated business case and expected value
• reprioritize planned BA work and elicitation focus
• adjust contingency planning for the changed objective
• communicate impacts to stakeholders and planned artifacts

The weak response is to preserve the original plan just because activities are already scheduled. That may be efficient administratively, but it is ineffective from a value-delivery perspective.

Continuing unchanged ignores the revised objective, so business analysis work may optimize for the wrong outcome.

Question 19

Topic: Planning

A BA is planning requirements work for a customer portal that will be delivered in 2-week iterations, with a first release due in 3 months. Product managers want a prioritized backlog, internal audit requires traceability and formal approval for regulatory requirements before release, and regional operations SMEs have limited availability. Adoption risk is high because support processes will change. What is the best BA action?

• A. Create a tailored requirements management plan using backlog refinement, user stories with acceptance criteria, targeted workshops/prototypes, defined roles and communication cadences, and formal approval for compliance-related requirements and release baselines.
• B. Begin sprint elicitation sessions immediately and let the team decide documentation and approval practices as requirements emerge.
• C. Require a complete BRD and formal sign-off on all requirements before backlog creation so governance is satisfied early.
• D. Ask the product owner to manage the backlog and priorities, and limit the plan to stakeholder communication since the delivery team can choose analysis methods later.

Best answer: A

What this tests: Planning

Explanation: The BA should define a requirements management plan that is tailored to iterative delivery and governance needs. In this case, the plan must cover backlog management, fit-for-purpose documentation, stakeholder roles, communication, and a formal approval path for regulated requirements.

The core concept is tailoring the requirements management plan to the delivery approach and constraints. Because the work is iterative, the BA should plan lightweight, ongoing elicitation and analysis methods such as workshops, prototypes, and backlog refinement, with requirements documented as user stories and acceptance criteria where appropriate. Because audit requires control, the plan must also specify traceability, which requirements need formal approval, when release baselines are established, and who approves them. Limited SME availability makes planned communication cadences and role clarity essential, while high adoption risk supports early validation with operations stakeholders.

A good plan here should define:

• elicitation methods suited to dispersed, limited-availability SMEs
• documentation standards for backlog items and compliance rules
• backlog ownership, prioritization, refinement, and change handling
• approval and traceability rules for regulated requirements

A purely agile or purely predictive approach misses one of the stated constraints.

This best fits iterative delivery while still defining how requirements will be elicited, documented, managed, traced, and formally approved where governance requires it.

Question 20

Topic: Planning

A bank is delivering a mobile loan application in a hybrid model: customer-facing features are built in two-week agile sprints, while the credit-decision engine upgrade follows a predictive vendor plan. Compliance requires proof that each regulation and business objective is implemented and tested before release, but the product owner says the team cannot maintain heavyweight traceability on every backlog item and go-live is in three months. What is the BEST business analysis action?

• A. Let each delivery team use its own traceability method until release planning.
• B. Use sprint acceptance criteria and demos as the main traceability evidence.
• C. Define a risk-based hybrid traceability approach across requirements and tests.
• D. Apply the same end-to-end traceability depth to every requirement and task.

Best answer: C

What this tests: Planning

Explanation: The BA should tailor traceability to the delivery approach, governance needs, and delivery constraints. Here, a risk-based hybrid strategy gives strong links for regulated and business-critical requirements across agile and predictive artifacts while keeping lower-risk tracing lightweight enough for the timeline.

The core concept is to define the necessary level of traceability, not the maximum possible level. In this scenario, the organization needs release-level proof that regulations and business objectives are covered and tested, but it also needs to preserve speed in an agile stream.

A good BA response is to design a hybrid, risk-based traceability strategy that connects high-risk and high-value requirements to the right downstream artifacts, such as features, user stories, vendor requirements, test cases, and release content. That approach supports monitoring, validation, and audit needs across both delivery methods without forcing the team to maintain deep links for every low-risk task.

The key takeaway is that traceability should be tailored by risk, governance, and delivery context rather than applied uniformly or left informal.

This provides the required end-to-end compliance and value visibility across both delivery streams without imposing unnecessary trace depth on low-risk items.

Question 21

Topic: Planning

A business analyst is drafting the requirements management approach for a hybrid project. The draft note says:

Requirements will be stored in separate spreadsheets on a shared drive.
File names will use the date and editor initials.
Any team member may update the files directly.
Design and test artifacts will remain in each team's folder.
The BA will compare files weekly to identify changes.

Which improvement is most important to support requirements traceability and versioning?

• A. Include approval meeting dates in each spreadsheet filename.
• B. Document the elicitation technique used for each requirement.
• C. Use a controlled repository with unique IDs, linked artifacts, and version history.
• D. Add a glossary so stakeholders interpret requirement terms consistently.

Best answer: C

What this tests: Planning

Explanation: The draft relies on manual file naming and weekly comparisons, which are weak controls for both traceability and versioning. The biggest gap is the absence of a managed repository that uniquely identifies requirements, links them to related artifacts, and preserves formal version history.

For this planning task, the core need is to select document control techniques that make requirements easy to trace across their lifecycle and easy to version without ambiguity. A shared drive with editable spreadsheets and date-based filenames does not provide dependable change history, relationship mapping, or control over simultaneous edits. The most important improvement is to use a controlled repository or tool that supports:

• unique requirement IDs
• links to design, test, and approval artifacts
• status and change history
• formal version control or check-in/check-out

That directly establishes the standard for traceability and versioning. Other documentation improvements may help quality, but they do not fix the main control weakness in the draft approach.

A controlled repository with unique identifiers and relationship links is the key mechanism for end-to-end traceability and reliable version control.

Question 22

Topic: Planning

A business analyst is drafting the requirements management plan for a new claims intake portal. The draft success measures are: number of workshops completed, percentage of requirements approved, and defects resolved during UAT. However, the business case expects fewer abandoned calls and faster claim setup after go-live. The sponsor wants the plan finalized today. What should the business analyst do next?

• A. Baseline the requirements package before clarifying solution success measures
• B. Finalize the plan now and refine business measures during UAT
• C. Define outcome-based business metrics and acceptance targets with stakeholders first
• D. Use schedule and defect trends as the primary success measures

Best answer: C

What this tests: Planning

Explanation: The best next step is to collaborate with stakeholders to define measurable business outcomes and acceptance criteria before finalizing the plan. Counts of workshops, approved requirements, or resolved defects are delivery or activity measures; they do not show whether the solution reduced abandoned calls or improved claim setup time.

This tests the difference between business metrics and delivery metrics. In planning, the business analyst should ensure success measures reflect the value the organization expects from the solution, not just whether project work was completed. Here, the business case already points to business outcomes: fewer abandoned calls and faster claim setup. Those should be converted into measurable targets and acceptance criteria with relevant stakeholders before the plan is finalized.

Useful next actions are:

• confirm the current baseline for the business outcomes
• define target measures and thresholds for success
• align those measures to requirements and evaluation plans

Finalizing the plan or baselining requirements first would lock in weak measures. Delivery indicators such as workshop counts, approval percentages, and defect trends can still be tracked, but they do not prove the solution met the business need.

The draft measures track project activity, not whether the solution delivers the business value promised in the business case.

Question 23

Topic: Evaluation

A BA is reviewing user acceptance test evidence for an expense reimbursement solution before recommending sign-off. The sponsor wants deployment this week to meet quarter-end processing. Based on the exhibit, what is the best interpretation/action?

Exhibit:

• A. Document the unmet requirement and require retest or a formal exception before sign-off
• B. Recommend sign-off because most criteria were met
• C. Revise the duplicate-claim acceptance criterion to match pilot results
• D. Defer the duplicate-claim issue to a later release

Best answer: A

What this tests: Evaluation

Explanation: The BA should compare each test result to its documented acceptance criterion, not rely on overall pass rate or schedule pressure. Because duplicate prevention required 100% success and only 92 of 100 attempts were blocked, the solution has not fully satisfied the approved requirements.

In solution evaluation, the BA validates whether test evidence meets the documented acceptance criteria for each requirement. Here, two requirements meet their criteria, but duplicate-claim prevention does not: the criterion is 100% blocking, while the test report shows 92 of 100 attempts blocked and eight duplicates submitted. That means the requirement is unmet, so the BA should document the gap and avoid recommending final sign-off based only on a majority pass rate or business urgency.

The appropriate next step is to obtain corrective action and retest evidence, or secure a formal exception through the agreed acceptance or change process. Simply treating the result as “good enough” is not supported by the documented criteria.

The duplicate-claim requirement has a 100% acceptance criterion, and the test evidence shows only 92% compliance, so the solution does not yet meet all documented acceptance criteria.

Question 24

Topic: Analysis

A business analyst is finalizing the requirements package for a claims intake improvement. The business case expects faster processing and fewer rework errors, but several requirements still use terms like “timely” and “accurate.” The test lead says the team cannot determine how success will be validated during user acceptance testing or after deployment. What should the business analyst do next?

• A. Get sponsor approval of the current requirements package
• B. Begin tracing the current requirements to design and training artifacts
• C. Define measurable acceptance criteria, target metrics, and measurement methods with stakeholders
• D. Have the test team set pass/fail thresholds during test planning

Best answer: C

What this tests: Analysis

Explanation: The next step is to remove ambiguity before approval or downstream work continues. Acceptance criteria and metrics must be documented in a measurable way so later validation and evaluation can confirm whether the solution meets requirements and delivers expected value.

This tests the analyst’s responsibility to elaborate requirements into measurable acceptance criteria and metrics before they are baselined or handed off for testing. Terms like “timely” and “accurate” are not yet testable because they do not define the expected result, target threshold, or how performance will be measured. The business analyst should work with stakeholders to document specific criteria such as the metric, target value, measurement source, and evaluation method in the requirements package.

That documentation enables consistent validation in user acceptance testing and later evaluation against the business case. Approving vague requirements, delegating threshold setting to testers, or tracing incomplete requirements forward would all move ahead without first making the requirements actionable and verifiable.

This creates testable, evaluable requirements by documenting exactly what will be measured, the target result, and how validation will occur.

Question 25

Topic: Analysis

A BA is preparing to baseline requirements for a bank’s new loan origination process. The package includes process changes for retail lending, audit and retention rules mandated by compliance, and new handoff steps for loan operations. A software vendor will build the solution after approval, and the contract states vendor staff may review for feasibility but do not approve business requirements. Whose sign-off should the BA NOT require on the requirements baseline?

• A. Vendor solution architect, provider of feasibility input
• B. Loan operations manager, owner of handoff acceptance
• C. Compliance manager, owner of audit requirements
• D. Retail lending director, the target-process owner

Best answer: A

What this tests: Analysis

Explanation: Requirements baseline sign-off should come from stakeholders who own the business process, control obligations, or operational acceptance of the requirements. Here, the vendor architect provides feasibility review only and is explicitly not an approval authority.

Baseline approval should be obtained from stakeholders who are accountable for the requirements content and the consequences of accepting it. In this scenario, the retail lending director owns the future-state process, the compliance manager owns the mandatory audit and retention controls, and the loan operations manager must accept the changed handoff requirements, so each is an appropriate signer. The vendor solution architect is still an important reviewer, but the stem states that vendor staff provide feasibility input only and do not approve business requirements. Requiring that sign-off would confuse technical review with decision authority and could delay baselining.

• Include business owners for process requirements.
• Include control owners for compliance or policy requirements.
• Include operational owners when downstream work must accept the change.

Use approval authority and accountability, not mere participation, to determine who signs the baseline.

Feasibility reviewers do not hold approval authority for the customer’s requirements baseline when business and control stakeholders own the requirements.

Questions 26-50

Question 26

Topic: Evaluation

A bank deployed an automated document-indexing solution for mortgage applications 8 weeks ago. The sponsor says the solution is already delivering value because staff adoption is high. Operations managers say turnaround times still feel unchanged because this is a seasonal peak period. The business analyst is asked to judge how well the deployed solution meets the business case. What should the business analyst obtain FIRST before making that determination?

• A. Business case targets, baseline metrics, and actual results for the same measures and period
• B. Open defects and production incident trends
• C. User satisfaction and training feedback
• D. Enhancement ideas for the next release

Best answer: A

What this tests: Evaluation

Explanation: Evaluating a deployed solution against the business case starts with benefits realization data, not impressions. The business analyst should first obtain the target benefits, original baseline, and actual post-deployment results measured the same way and over a comparable period.

The core concept is valuation against the business case. A deployed solution can only be judged by comparing actual outcomes to the expected benefits, baseline conditions, and measurement approach defined before implementation. In this scenario, adoption is high and stakeholder perceptions differ, but neither proves value. The business analyst first needs the benefit measures used in the business case, their baseline values, the target improvement, and current results gathered for the same scope and timeframe.

• Confirm which metrics the business case used.
• Verify the pre-deployment baseline and target values.
• Collect post-deployment results using the same definitions and period.
• Then assess variance and benefit realization.

Defects, satisfaction, and enhancement ideas may matter later, but they are secondary unless they help explain a gap in measured value.

A valuation judgment requires comparing actual post-deployment results with the business case baseline, targets, and measurement basis.

Question 27

Topic: Traceability and Monitoring

A business analyst is supporting an 8-week release for a customer onboarding portal. The scope includes audited KYC checks and data-retention rules, plus low-risk wording and layout changes. The project manager says the current traceability approach requires formal reviews for every requirement and will delay delivery. The audit team still needs evidence that regulated requirements were reviewed, approved, and linked to test cases. How should the BA tailor lifecycle monitoring?

• A. Apply the same detailed traceability and approvals to every requirement.
• B. Use deeper monitoring for regulated requirements and lighter tracking for low-risk changes.
• C. Keep monitoring minimal during build and reconstruct trace links before release.
• D. Prioritize monitoring for the most visible user-facing changes first.

Best answer: B

What this tests: Traceability and Monitoring

Explanation: Lifecycle monitoring should be scaled to the project’s governance and risk profile, not applied uniformly. Audit-sensitive requirements need stronger traceability, review evidence, and approval controls, while low-risk changes can use simpler monitoring so delivery is not burdened unnecessarily.

The core concept is risk-based tailoring of requirements monitoring. In this scenario, KYC and retention requirements carry audit and compliance exposure, so they need stronger lifecycle control: clear status tracking, links to supporting artifacts such as rules and test cases, and documented reviews and approvals. Low-risk wording and layout changes do not need the same depth of governance evidence, so lighter tracking is appropriate.

This approach balances two valid pressures in the stem:

• meeting governance and audit expectations for high-risk requirements
• avoiding unnecessary overhead on low-risk requirements
• preserving delivery speed for the 8-week release

Using maximum rigor for everything over-controls the work, while delaying traceability or focusing only on visible features ignores the stated governance need.

This best matches monitoring depth to governance and risk by preserving audit evidence where needed without slowing low-risk work.

Question 28

Topic: Analysis

A business analyst is reviewing a draft requirements package for a new retail banking onboarding workflow. Which is the most important improvement before the package is given to design and test teams?

Requirement R-17:
"The system shall support customer onboarding by capturing customer data,
verifying identity, checking sanctions lists, routing approvals, creating
the account, and sending a welcome email."

Acceptance criterion:
"Branch staff can complete onboarding without issues."

• A. Include a future-state process model
• B. Add priority and target release information
• C. Decompose it into separate testable requirements and measurable criteria
• D. Capture the originating stakeholder and business rationale

Best answer: C

What this tests: Analysis

Explanation: The main issue is that the draft requirement bundles multiple functions into one high-level statement and uses a vague acceptance criterion. For design and testing, the BA should first decompose it into smaller requirements that can each be validated objectively.

This item tests requirement decomposition and elaboration. The draft mixes several capabilities—data capture, identity verification, sanctions checking, approval routing, account creation, and email notification—into a single requirement. That makes design ownership unclear, hides dependencies, and prevents precise testing. The acceptance criterion is also not testable because “without issues” is subjective.

A stronger package would break the high-level need into discrete functional requirements, then attach clear acceptance criteria to each one. For example:

• capture required customer fields
• verify identity against approved sources
• perform sanctions screening
• route exceptions for approval
• create the account record
• send the welcome email after account creation

Adding source, priority, or a process model can help, but those improvements do not solve the core problem that the requirement is not yet testable as written.

The draft combines several distinct capabilities into one broad statement, so it must be broken into smaller verifiable requirements with specific acceptance criteria.

Question 29

Topic: Analysis

A retail bank is defining acceptance criteria for a new self-service password reset feature. The approved business metrics are to reduce password-reset calls by 30% while keeping customer satisfaction at or above 4.2/5, and the fraud team requires suspicious attempts to be routed to an agent. During analysis, the delivery team proposes detailed metrics of 90% of resets completed without agent transfer and an average completion time under 45 seconds. Branch managers say some high-value customers expect optional assisted service. Which action should the business analyst NOT take?

• A. Baseline the 90% no-transfer metric because it is easy to test
• B. Review the proposed targets with fraud, service, and branch stakeholders
• C. Revise acceptance criteria to measure both self-service and assisted-service outcomes
• D. Trace each detailed metric to a business metric and stakeholder rationale

Best answer: A

What this tests: Analysis

Explanation: Detailed metrics must support the approved business metrics and stakeholder expectations, not just be convenient for testing. A no-transfer target may undermine satisfaction and service expectations, so baselining it without reconciliation is the anti-pattern.

The core concept is alignment: detailed metrics and acceptance criteria should decompose business metrics into measurable solution outcomes without contradicting stakeholder needs. Here, reducing calls is only one business objective; the solution must also preserve customer satisfaction and allow agent routing for fraud or preferred assisted service. A strict no-transfer target can push behavior that harms those outcomes.

A sound BA response is to:

• trace each detailed metric to its business objective
• confirm the origin and rationale with key stakeholders
• adjust acceptance criteria so assisted-service and exception paths remain measurable

The closest distractors all support reconciliation and validation. The anti-pattern is locking in a detailed metric solely because it is easy to test.

A metric should not be baselined just because it is testable when it conflicts with business outcomes and stakeholder expectations.

Question 30

Topic: Needs Assessment

A BA is assessing needs for a customer self-service claims portal. The sponsor wants requirements prioritized for a single 4-month release. Compliance leaders value auditability and required disclosures, call center managers value reduced call volume, and customers value faster claim status updates. Governance requires later prioritization decisions to show how stakeholder value was captured and why tradeoffs were made. What is the BEST BA action?

• A. Store elicitation notes in meeting minutes and link them to the stakeholder register.
• B. Ask each stakeholder group to rank candidate features now and average the rankings.
• C. Create a stakeholder value matrix with value drivers, relative importance, rationale, and success measures by stakeholder group.
• D. Update the business case with overall project benefits and obtain sponsor approval.

Best answer: C

What this tests: Needs Assessment

Explanation: The best action is to document stakeholder value in a structured form that supports later comparison and prioritization. A stakeholder value matrix captures what each group values, how strongly they value it, and the rationale and measures behind it, which meets the governance need for transparent tradeoff decisions.

This question is about creating a usable baseline for later prioritization, not performing prioritization yet. In this situation, stakeholders value different outcomes, delivery is constrained to one release, and governance requires defensible tradeoff reasoning. The BA should therefore document stakeholder value information in a structured artifact that records each stakeholder group’s value drivers, relative importance, rationale, and success measures.

That approach helps the BA later compare requirements against explicit value criteria rather than relying on memory or informal notes. It also preserves the origin and reasoning behind stakeholder preferences, which is important when conflicts emerge between compliance, operational efficiency, and customer experience. The key is to capture stakeholder value at the level of decision criteria, so future requirement prioritization can be traced back to agreed stakeholder values.

A feature ranking exercise is the closest distractor, but it jumps ahead to solution choices before the underlying value criteria are properly documented.

This creates a documented, traceable baseline of stakeholder value criteria that can be used transparently in later prioritization decisions.

Question 31

Topic: Evaluation

Three months after deploying a self-service returns portal, a BA reviews the business case. Success measures were a 25% reduction in return-related calls and a 15% faster refund cycle. Actual results are 28% fewer calls and 6% faster refunds. Validation notes show the portal works as specified; most remaining delay comes from warehouse inspection, a separate process excluded from this project. Users also requested photo upload for damaged items. The sponsor asks what the BA should do next.

• A. Close the initiative immediately because the portal passed validation and reduced calls.
• B. Recommend closing this initiative and reprioritizing the warehouse process gap as follow-on work.
• C. Approve the photo-upload enhancement because one business metric was missed.
• D. Reopen elicitation with all users before deciding whether to act on the findings.

Best answer: B

What this tests: Evaluation

Explanation: The deployed portal met one business case target and is functioning as designed, while the remaining value gap is tied to an out-of-scope warehouse step. That means the findings do not justify enhancing the current solution first; they justify closing the current initiative and reprioritizing the separate process issue.

This is a post-deployment evaluation decision based on business value, not just user requests or test results. The portal achieved the call-reduction objective and validation confirmed it operates as specified. The missed refund-cycle target is important, but the evidence shows the shortfall comes from warehouse inspection, which was outside the approved solution scope. In that situation, the BA should document the delta against the business case, confirm the root cause is external to the deployed solution, and recommend closing the current initiative while submitting the warehouse process issue for reprioritization as follow-on work.

The key takeaway is that unmet value does not automatically justify an enhancement; the next action depends on whether the gap is caused by the deployed solution or by something outside it.

The unmet value is caused by an out-of-scope process, so the BA should close the delivered solution scope and route the remaining gap for reprioritization.

Question 32

Topic: Analysis

A business analyst is preparing a requirements baseline for Release 1 of a customer billing portal. The release has a fixed 4-month deadline, limited funding, and only one integration specialist. Several accepted requirements compete for the same resources, and one high-value reporting feature depends on an interface update that is not yet allocated. Which action should the business analyst AVOID when allocating requirements to Release 1?

• A. Defer a lower-value item that uses the scarce integration specialist
• B. Rank requirements by value, effort, and dependencies before release assignment
• C. Allocate the interface update with the reporting feature it enables
• D. Baseline all accepted requirements into Release 1 and let delivery trim later

Best answer: D

What this tests: Analysis

Explanation: Requirement allocation should create a realistic baseline by balancing value against schedule, budget, resource, and dependency constraints. Pushing all accepted requirements into the release and expecting the team to cut scope later bypasses prioritization and undermines controlled baseline decisions.

The core concept is disciplined allocation of accepted and deferred requirements before establishing the baseline. In this scenario, the business analyst already knows the release is constrained by time, funding, and a scarce specialist, so requirements must be assigned using value, effort, resource availability, and dependency logic. A valid baseline is not just a list of approved requirements; it is a feasible release commitment.

A sound approach is to:

• compare business value against implementation effort and resource demand
• keep dependent requirements together when one enables another
• defer lower-value items when they consume scarce capacity
• baseline only what can realistically be delivered within the constraints

The closest trap is thinking that prior acceptance automatically means inclusion in the next release, but allocation decisions still must reflect feasibility and the value proposition.

This is an anti-pattern because it ignores known scope, schedule, budget, and resource limits instead of making explicit allocation decisions before baselining.

Question 33

Topic: Analysis

A distributor is elaborating requirements for order entry. The requirements say: customers on credit hold must be blocked from placing orders; the sales screen displays customer account status; and sales managers can approve overrides for strategic accounts. Finance applies credit holds in the ERP, while the sales screen reads status from the CRM, which is updated nightly from the ERP. Before deciding whether the blocking requirement is clear and implementable, what should the business analyst verify first?

• A. Which system and refresh timing determine credit status at order entry
• B. Whether the sponsor wants a prototype of the sales screen
• C. How often managers approve overrides for strategic accounts
• D. Whether sales staff need training on the override workflow

Best answer: A

What this tests: Analysis

Explanation: This requirement set is ambiguous because the business rule relies on customer status, but the displayed status comes through an interface with a nightly delay. The first step is to clarify the authoritative source and timing of that data at the moment an order is entered.

The core issue is interface and data ambiguity. A rule that blocks orders for customers on credit hold can only be validated if the team knows which system is authoritative for credit status and how current that status is when the order-entry process runs. Here, Finance maintains credit holds in the ERP, but the sales screen reads from the CRM with nightly synchronization, so the requirement may behave differently depending on which data source drives the block.

A business analyst should first confirm:

• which application is the system of record
• whether the block uses ERP data, CRM data, or both
• what latency is acceptable for the business rule

Questions about override volume, training, or screen design matter later, but they do not resolve the ambiguity that makes the requirement unclear.

The blocking rule depends on timely, authoritative status data, so the first clarification is the source of record and interface latency.

Question 34

Topic: Analysis

A business analyst is finalizing sign-off for requirements package version 3.2. Operations agrees to approve if training materials are available before the pilot. Legal approves with a reservation that one retention rule must be updated after a policy revision next month. The sponsor wants two reporting enhancements deferred to a later release but still wants the current release baselined now.

Which action by the business analyst is INCORRECT?

• A. Log the legal reservation with owner, rationale, and follow-up date.
• B. Separate deferred enhancements from the approved release baseline.
• C. Capture each approval condition in the sign-off record.
• D. Treat the package as unconditional approval and resolve caveats later.

Best answer: D

What this tests: Analysis

Explanation: When stakeholders approve with conditions, reservations, or deferred items, the approval record must reflect those exact limits. The current release can still be baselined, but only with the caveats documented and traceable.

The core concept is that requirements sign-off must accurately record the decision that stakeholders actually made. If approval includes conditions, reservations, or deferred items, the business analyst should document them in the approval record, tie them to the affected requirements or release scope, and assign follow-up ownership as needed. That preserves stakeholder consensus while keeping the baseline truthful and controllable.

In this case, the current release may be approved, but the training prerequisite, the legal reservation, and the deferred reporting enhancements must remain visible in the baseline package or related approval artifacts. Recording the package as fully approved with no caveats would create a false baseline, hide unresolved limits, and make later disputes or changes harder to manage.

Verbal agreement to proceed is not the same as unconditional approval.

Conditional approval must be documented as given; converting it to unconditional approval misrepresents the baseline and weakens traceability.

Question 35

Topic: Needs Assessment

A BA is preparing for a sponsor workshop to finalize project goals and objectives. The draft note says:

Business need: Implement a customer self-service portal this year to reduce contact center cost, improve retention, speed claim handling, and strengthen the brand.
Reason: Customers complain about long resolution times.

What is the most important improvement before goals and objectives are finalized?

• A. Separate the business need from the portal solution and confirm the primary outcome.
• B. Identify which operations teams will support the portal after launch.
• C. Document interface dependencies with the claims platform.
• D. Add baseline and target measures for cost, retention, and cycle time.

Best answer: A

What this tests: Needs Assessment

Explanation: The draft note conflates a proposed solution with the business need and lists several possible benefits without identifying the main problem to solve. Before goals and objectives are set, the BA should clarify the underlying need and primary desired outcome so later measures and scope align to the right value.

The core concept is that project goals and objectives should be based on a clearly defined business need, not on an assumed solution. In the note, “implement a customer self-service portal” is already a solution choice, while the reason given suggests the underlying need may be to reduce long claim-resolution times. The note also names several outcomes—cost reduction, retention, cycle time, brand impact—without showing which one is most important.

A sound sequence is:

• clarify the business problem or opportunity
• confirm the primary value expectation
• then define goals, objectives, measures, and solution scope

Baseline metrics, support ownership, and interface details are useful, but they are secondary until the business need itself is clear.

The note mixes a presumed solution with multiple possible benefits, so the real business need and priority outcome must be clarified first.

Question 36

Topic: Traceability and Monitoring

A bank is implementing a new account-opening workflow in a hybrid project. The compliance manager requires audit evidence that approved regulatory requirements were delivered as stated, the product owner wants visibility to which high-value features are ready for release, and UAT starts in 2 weeks. The team already has a spreadsheet with requirement IDs, short descriptions, and owners. What is the best business analysis action?

• A. Publish the approved requirements package and obtain another stakeholder review before UAT
• B. Prepare a release checklist summarizing which features are planned for the next deployment
• C. Create a traceability artifact linking each requirement to its source, status, dependencies, solution components, and validating test results
• D. Expand the spreadsheet with priority rankings and stakeholder names for each requirement

Best answer: C

What this tests: Traceability and Monitoring

Explanation: The best action is to turn the existing reference list into a true traceability artifact. The scenario requires audit evidence, delivery status visibility, and dependency awareness, which means the BA must connect requirements to their origins, implementation elements, and validation results.

A simple reference list helps organize requirements, but it does not show whether requirements were delivered as approved or how they relate across the life cycle. Here, the BA must satisfy governance and release needs at the same time: prove regulatory requirements came from approved sources, show current status for decision-making, identify dependencies that affect readiness, and connect requirements to solution components and test results.

A true traceability artifact should capture items such as:

• source or origin
• current status
• relationships and dependencies
• downstream design, build, or solution elements
• validation evidence such as test cases or results

Adding only names or priorities improves a catalog, not traceability. Republishing requirements or making a release checklist supports communication, but neither provides end-to-end evidence that requirements were implemented and verified as stated.

This creates the evidence chain needed for governance and release decisions, unlike a simple list that only catalogs requirements.

Question 37

Topic: Analysis

A BA is finalizing sign-off on a billing portal requirements package. The sponsor and operations lead are ready to approve. The risk officer agrees to proceed only if one audit-log retention requirement is revised before test case design. The call center manager wants an optional export feature moved to a later release. Build starts next week, so the team needs a usable baseline now. What should the BA do?

• A. Delay sign-off until the retention revision and export request are fully resolved.
• B. Record conditional approval, document the retention issue as a reservation with follow-up, document the export as deferred, and baseline the package with those statuses.
• C. Record full approval and capture both comments in meeting minutes.
• D. Ask the sponsor to overrule the concerns so approval is not delayed.

Best answer: B

What this tests: Analysis

Explanation: The best response is to document the sign-off result exactly as given: approval is not unconditional, and not every requested item belongs in the current baseline. Recording the reservation and deferred item separately preserves schedule value without hiding risk or misrepresenting stakeholder approval.

When stakeholders are willing to proceed but attach conditions or defer lower-value scope, the BA should document the approval status precisely rather than forcing an all-or-nothing outcome. In this case, the requirements package can move forward, but the audit-log retention requirement has a stated reservation that needs follow-up, and the optional export belongs in a deferred backlog or later release record.

The right documentation approach is to:

• record the approval as conditional or approved with reservation
• capture the exact condition, owner, and follow-up timing
• mark the export feature as deferred rather than approved scope
• baseline the package using those documented statuses

This supports consensus, maintains traceability, and avoids losing time on already approved requirements. Delaying everything is the closest alternative, but it sacrifices value when the concerns can be managed transparently.

This preserves the approved baseline while accurately documenting the approval condition, reservation, and deferred item for traceability and follow-up.

Question 38

Topic: Traceability and Monitoring

A BA is monitoring a requirements traceability tool as a claims-processing project prepares for system testing. One high-risk requirement is marked Ready for Test, but the linked business rule model is still in draft, the process update document has not been reviewed, and no test cases are attached. The test lead wants to start anyway to avoid delay. What should the BA do next?

• A. Allow testing to start because the requirement is already marked Ready for Test in the tool.
• B. Ask the test lead to create test cases from the draft model and document the gap later.
• C. Escalate for formal sign-off on the requirement first, then address missing artifacts after testing begins.
• D. Change the requirement status to reflect the artifact gap and coordinate completion, review, and approval before testing proceeds.

Best answer: D

What this tests: Traceability and Monitoring

Explanation: The BA should use lifecycle monitoring and traceability to stop the requirement from moving forward with missing supporting artifacts. If the required model, documentation, and test cases are incomplete or unreviewed, the correct next step is to update status and drive artifact completion before testing.

In traceability and monitoring, the BA confirms that each requirement has the right supporting artifacts at the right lifecycle point before allowing it to advance. Here, the requirement is incorrectly marked Ready for Test even though key artifacts are missing or not yet reviewed. The best next step is to correct the status in the traceability tool and coordinate creation, review, and approval of the business rule model, process documentation, and test cases.

This protects quality and control by ensuring:

• artifact completeness matches lifecycle status
• reviewers approve the right content before downstream work
• testers execute against validated and traceable requirements

Starting testing anyway is premature, and jumping to sign-off does not fix the underlying readiness gap. The core point is to use the traceability artifact to verify readiness, not just record progress.

A requirement should not advance to testing until the required supporting artifacts exist and are reviewed at that lifecycle point.

Question 39

Topic: Analysis

A business analyst is preparing to request stakeholder approval of a requirements baseline for a loan origination process update. The sponsor wants evidence that the package is ready for sign-off, not just that elicitation is complete. Which artifact should the business analyst present before asking for approval?

• A. A summary of elicitation workshops completed and stakeholder attendance
• B. A count of requirements gathered and the percentage marked high priority
• C. A validated requirements package with traceability to business objectives, source and rationale, priority, and acceptance criteria
• D. A prototype walkthrough with stakeholder comments from the last review

Best answer: C

What this tests: Analysis

Explanation: Before requesting approval of a requirements baseline, the business analyst should present evidence that the requirements are ready to be baselined. A validated requirements package with traceability, rationale, priority, and acceptance criteria best demonstrates completeness, quality, and alignment to business need.

The key concept is baseline readiness. Stakeholders should approve a baseline only after they can evaluate whether requirements are complete enough, aligned to business objectives, and testable. A validated requirements package that includes traceability to business goals, source and rationale, priority, and acceptance criteria gives decision-makers the information needed to judge scope, value, and verifiability before sign-off.

This matters because baseline approval is not simply confirmation that meetings happened or that ideas were collected. It is formal agreement on a controlled set of requirements that can be managed through change control. The closest distractors show useful analysis activities, but they do not prove that the baseline itself is sufficiently validated and approval-ready.

This shows the baseline is complete, validated, and decision-ready because stakeholders can see why each requirement exists and how acceptance will be judged.

Question 40

Topic: Analysis

A business analyst must reconcile two release allocation proposals after a 15% budget cut. The approved business case promised to reduce contact-center return calls by 20% and maintain auditable refund approvals. One proposal keeps automated shipping labels and defers the approval workflow; the other keeps the approval workflow and defers automated labels. Which artifact best validates that the selected allocation still preserves the baseline’s business value?

• A. Updated benefits traceability matrix with deferral impact analysis
• B. Release team capacity report by role and sprint
• C. Stakeholder workshop notes ranking preferred features
• D. Prototype demo satisfaction scores from pilot users

Best answer: A

What this tests: Analysis

Explanation: To preserve baseline business value, the BA needs evidence that connects each requirement decision to the approved business case outcomes. A benefits-focused traceability artifact with deferral impact analysis shows whether the chosen allocation still supports the expected value and critical dependencies.

The core concept is validating allocation decisions against the value proposition, not against preference, effort, or popularity alone. When competing proposals defer different accepted requirements, the strongest evidence is an updated artifact that traces each requirement to business objectives, success measures, and dependencies, then shows the impact of deferral on those outcomes. That lets the BA compare proposals based on preserved value in the baseline.

• Link each requirement to a business objective or benefit metric.
• Identify dependency or compliance impacts of deferral.
• Compare which proposal still supports the approved success measures.
• Use that evidence to finalize the requirements baseline.

Capacity, workshop input, and demo sentiment may inform the decision, but they do not validate whether the baseline still delivers the business case value.

This directly shows how each allocated or deferred requirement affects business objectives, success metrics, and dependencies in the baseline.

Question 41

Topic: Analysis

A BA has baselined a requirement for a loan-servicing portal: “Customers can change a payment due date online.” The requirement already traces to UI mockups, process steps, and test cases. During compliance review, operations adds two mandatory rules: the change is allowed only once every 12 months, and accounts more than 30 days delinquent are ineligible. Development starts tomorrow. Which action best refines the specification while preserving traceability and baseline control?

• A. Process a formal change, update the baselined requirement with the rules, version the package, and assess linked impacts.
• B. Create a new enhancement requirement for the rules after the initial release.
• C. Edit the requirement text immediately and email the revised wording to the team.
• D. Leave the requirement unchanged and add the rules only to test cases.

Best answer: A

What this tests: Analysis

Explanation: The missing details are not optional clarifications; they are business rules and eligibility conditions that define when the requirement is valid. Since the requirement is already baselined, the BA should use formal change control, update the specification version, and analyze impacts on linked artifacts.

When a baselined requirement is found to be incomplete, the BA should refine the specification through controlled change rather than informal edits. The newly identified limits are core requirement content: one is a usage constraint, and the other is an eligibility business rule. If they are not added to the requirement package itself, the specification remains ambiguous and downstream artifacts can become inconsistent.

• Update the baselined requirement so the conditions are measurable and actionable.
• Version the requirements package under document control.
• Perform impact analysis on linked design, process, and test artifacts.
• Maintain trace links and lifecycle status after approval.

The closest distractor is directly editing the wording, but that bypasses baseline discipline and weakens traceability.

Because the requirement is already baselined, the missing business rules must be added through controlled change with versioning and impact updates to traced artifacts.

Question 42

Topic: Needs Assessment

A bank can submit only one onboarding improvement initiative for this quarter’s portfolio review. The steering committee requires a payback period of 18 months or less, no unresolved regulatory dependency at launch, and branch training limited to one 4-hour session. The BA used agreed weighted criteria covering revenue growth, cost reduction, and customer experience.

Exhibit:

What should the business analyst recommend as the initiative with the strongest value case?

• A. Recommend identity verification upgrade for its highest weighted score
• B. Recommend e-signature onboarding for the strongest feasible value case
• C. Recommend workflow dashboard for its shortest payback
• D. Request another valuation cycle before making any recommendation

Best answer: B

What this tests: Needs Assessment

Explanation: The strongest value case is not just the highest score; it is the best-valued option that also satisfies the decision gates. E-signature onboarding meets the payback, regulatory, and training constraints and has a stronger valuation result than the other feasible option.

When comparing competing initiatives, the BA should apply agreed valuation findings together with any governance and adoption gates. The identity verification upgrade has the top weighted score, but it cannot satisfy the stated requirement of having no unresolved regulatory dependency at launch, so it is not the strongest current value case. The workflow dashboard is feasible, but its weighted score is materially lower. E-signature onboarding is therefore the best recommendation because it remains within the 18-month payback limit, fits the training limit, and provides the highest overall value among the initiatives that can actually proceed.

• Eliminate options that fail mandatory gates.
• Compare valuation results among the remaining feasible options.
• Recommend the feasible initiative with the strongest overall value case.

The closest distractor focuses only on the shortest payback instead of the full valuation comparison.

It is the highest-valued feasible initiative because it meets the payback, governance, and training constraints.

Question 43

Topic: Traceability and Monitoring

A business analyst on a hybrid claims-processing project has been sending the same weekly requirements status report to the project manager, sponsor, and operations lead. The project manager says the report does not clearly show which requirement changes affect schedule, dependencies, and test readiness. The sponsor says the report is too detailed and does not show business impact or pending decisions. What should the business analyst do next?

• A. Ask the sponsor to approve the current report format
• B. Tailor requirements status reporting by stakeholder need
• C. Send the full traceability matrix to all stakeholders
• D. Wait until validation is complete before changing reports

Best answer: B

What this tests: Traceability and Monitoring

Explanation: The best next step is to tailor requirements status communication to each audience. The project manager needs status elements that support planning and control, while sponsors and operational stakeholders need concise information about business impact, risks, and decisions.

In requirements monitoring, status communication should be adapted to stakeholder information needs rather than sent as a single generic report. Here, the project manager specifically needs requirement status elements that help manage delivery, such as change impacts, dependencies, risks, lifecycle status, and effects on test readiness or schedule. The sponsor and operations lead need higher-level information, such as business impact, unresolved decisions, readiness concerns, and whether requirements changes affect expected value.

The next step is to review stakeholder needs and update the communication approach so each audience gets the right level and type of status information. Sending everyone the same detail either overwhelms some stakeholders or leaves others without the information needed to act. The closest trap is sharing the full traceability artifact, but that provides raw detail rather than targeted status communication.

This is correct because the project manager needs control-focused status elements, while other stakeholders need decision- and value-focused summaries.

Question 44

Topic: Analysis

A BA is defining acceptance criteria for a new expense-report app. The sponsor wants an early warning during a 3-week pilot if user adoption is trending poorly, but the release board will approve production only with objective go/no-go conditions. Which criterion set should the BA prioritize?

• A. Pilot completion rate rises at least 5 points weekly; release passes only with 95% final completion and zero critical defects.
• B. Release passes if final completion reaches 95%; pilot comments are reviewed weekly for possible issues.
• C. All pilot users complete training; release passes when the sponsor accepts remaining issues.
• D. Pilot support calls decrease each week; release passes if call volume drops below week-one levels.

Best answer: A

What this tests: Analysis

Explanation: The strongest acceptance criteria separate early monitoring from final approval. A quantified leading indicator gives the team time to react during the pilot, while explicit thresholds and pass/fail conditions support an objective release decision.

Acceptance criteria should clearly distinguish three elements: a leading indicator, a threshold, and a pass/fail condition. In this scenario, the business needs an early signal during the pilot and a defensible go/no-go decision at release. The best criterion set uses a trend measure during the pilot to show whether adoption is moving in the right direction, then defines measurable end-state targets and a clear failure boundary for release.

• A leading indicator gives early warning before the final result is known.
• A threshold makes the expected level measurable.
• A pass/fail condition states whether release is acceptable.

Options that rely only on final results, indirect proxies, or subjective approval do not fully support requirement evaluation.

It combines a leading indicator, measurable thresholds, and explicit pass/fail conditions for an objective release decision.

Question 45

Topic: Traceability and Monitoring

A business analyst is supporting a hybrid project to replace a manual claims intake process. The traceability artifact already shows each requirement’s source, status, and dependencies. Late in the current sprint, three high-priority compliance requirements were revised after legal clarification, and user acceptance testing starts in 5 days. The sponsor also wants better visibility to business objectives, the architect wants requirement-to-component links, and the release manager says deployment packaging will be finalized after UAT. The BA can close only one traceability gap before testing begins. Which connection should be prioritized?

• A. Link the revised requirements to design components
• B. Link the revised requirements to test cases
• C. Link the revised requirements to release items
• D. Link the revised requirements to business objectives

Best answer: B

What this tests: Traceability and Monitoring

Explanation: The most urgent need is proving that the revised compliance requirements will be tested before UAT starts. Traceability to test cases best protects requirement quality and delivery evidence under the immediate time constraint.

Traceability should connect requirements to the downstream artifact that best manages the current decision risk. Here, the immediate risk is not scope justification, future maintenance, or deployment packaging; it is whether recently changed, high-priority compliance requirements will actually be validated in UAT. Linking those requirements to test cases allows the BA and QA team to confirm coverage, update tests for the legal clarification, and show evidence that the requirements can be verified as stated.

Traceability to business objectives is most valuable when prioritizing scope against expected value. Traceability to design is most useful for impact analysis during solution design or technical change. Traceability to release items matters most when deciding what can safely be deployed in a phased or constrained release. Under these facts, test coverage is the highest-value connection to add first.

With high-priority requirements changed just before UAT, test traceability is the fastest way to verify coverage and provide evidence the revised requirements will be validated as delivered.

Question 46

Topic: Evaluation

A lender pilots a new loan-origination workflow. QA reports that all approved user story tests passed, yet pilot users find applications above a manager’s lending limit cannot be routed for secondary approval. A peer review shows that the lending-limit policy was mentioned in workshop notes but was never linked to a business rule, detailed requirement, or test case. What is the most likely underlying BA gap?

• A. Failure to trace a key policy rule into requirements and tests
• B. Insufficient user training on the approval workflow
• C. Too many stakeholder approvals during requirements review
• D. Incomplete defect logging during QA execution

Best answer: A

What this tests: Evaluation

Explanation: The strongest clue is that the lending-limit policy existed in source notes but never appeared in a business rule, detailed requirement, or test case. That points to a BA gap in translating and tracing a critical rule into build-and-test artifacts, not a training or testing-volume issue.

This discrepancy is best explained by missing traceability from a source policy to actionable requirements and test coverage. The solution passed the tests that existed, which means QA likely validated only what had been specified. Because the lending-limit rule stayed in workshop notes and was never formalized or linked downstream, the development team had no complete requirement to implement and testers had no basis to verify the routing behavior.

A good BA root-cause diagnosis here is:

• identify the source artifact containing the rule
• confirm it was not baselined into requirements
• verify no related test case or acceptance criterion exists
• communicate the gap and resulting solution delta

The key takeaway is that passed tests do not prove solution completeness when a required business rule was never traced into the requirements package.

The peer review shows the policy source was known but never carried into downstream requirements and validation artifacts, so the solution omitted that behavior.

Question 47

Topic: Needs Assessment

A retailer approved a project goal to reduce return-related call volume by 20% through a self-service returns portal. During needs assessment, the BA learns that new compliance rules require identity verification and manual review for regulated products, so the first release will support only domestic standard-item returns. The sponsor asks how the project goals and objectives should be handled. Which action is INCORRECT?

• A. Revise success measures to reflect only eligible return types
• B. Trace the scope change to affected objectives and recommend updates
• C. Reconfirm stakeholder value expectations and update business case assumptions
• D. Keep the original 20% call-reduction goal unchanged for executive support

Best answer: D

What this tests: Needs Assessment

Explanation: When solution scope or the underlying business need changes, the BA should recommend updates to goals, objectives, and success measures so they stay realistic and aligned to expected value. Keeping the original enterprise-level target despite a reduced release scope is the anti-pattern because it misrepresents what the solution can reasonably achieve.

The key concept is alignment between business need, solution scope, and project objectives. In this scenario, compliance constraints materially reduce what the first release will deliver, so the original objective tied to all return-related calls is no longer a sound measure of success. A BA should identify which goals, objectives, assumptions, and metrics are affected, then recommend revised wording and targets that match the narrowed scope and stakeholder value expectations.

• Assess how the scope shift changes expected outcomes.
• Update impacted objectives and success measures.
• Reconfirm assumptions and value expectations with stakeholders.
• Obtain agreement so downstream planning and evaluation use valid targets.

Preserving the original target for political reasons creates misalignment and weakens later traceability and evaluation.

Leaving the original target unchanged ignores the narrowed scope and creates objectives that no longer align with the actual business need and deliverable.

Question 48

Topic: Needs Assessment

A business analyst is assessing needs for a new customer returns platform. Sales, operations, and compliance leaders disagree on what matters most, and the analyst must uncover stakeholder values, priorities, and tradeoffs to create a baseline for requirements prioritization. Which elicitation approach should the analyst AVOID as the primary technique?

• A. Interview stakeholders with scenario-based tradeoff questions
• B. Facilitate a workshop with ranking and tradeoff exercises
• C. Infer priorities mainly from procedures and performance reports
• D. Run a focus group using prototypes and forced ranking

Best answer: C

What this tests: Needs Assessment

Explanation: To establish a prioritization baseline, the analyst needs techniques that directly surface what stakeholders value and how they make tradeoffs. Relying mainly on existing documents is weak because it infers priorities indirectly instead of eliciting them from stakeholders.

The core concept is choosing an elicitation technique that directly uncovers stakeholder values, priorities, and tradeoff decisions. In this scenario, stakeholders disagree across functions, so the analyst needs interactive techniques that prompt comparison, discussion, and explicit ranking. Workshops, interviews, and focus groups can all be structured to ask what matters most, what can be deferred, and what constraints are nonnegotiable. By contrast, procedures and performance reports mostly describe the current state, existing controls, and historical outcomes.

• Use direct elicitation when the goal is stakeholder value discovery.
• Use ranking, scenario questions, or forced-choice exercises to expose tradeoffs.
• Use document review as supporting context, not the main way to determine values.

The closest distractor is document analysis because it is useful preparation, but by itself it does not provide a reliable baseline for prioritization.

Existing documents show current rules and issues, but they do not directly elicit stakeholder values or reveal explicit tradeoff choices.

Question 49

Topic: Planning

A business analyst supports a customer portal delivered in two-week sprints. Most backlog items change frequently, but privacy and billing features must remain auditable through release. When tailoring the requirements traceability strategy, which approach should the BA AVOID?

• A. Apply one detailed trace matrix to all stories from draft to deployment.
• B. Update trace links when epics are split, merged, or moved between releases.
• C. Trace privacy and billing stories to objectives, rules, acceptance criteria, and tests.
• D. Keep lightweight tool-based links for low-risk stories until sprint commitment.

Best answer: A

What this tests: Planning

Explanation: Traceability should be tailored to delivery approach, risk, and governance needs. In iterative delivery, using the same exhaustive traceability for every draft and low-risk story adds maintenance overhead and quickly becomes stale, while deeper traceability for regulated items is appropriate.

The core concept is to establish only the level of traceability needed to monitor and validate requirements in the chosen delivery context. In adaptive delivery, many backlog items evolve as teams learn, so traceability should be lighter for volatile, low-risk work and stronger for items with compliance, audit, or validation demands. A tailored strategy considers change frequency, business risk, and the evidence needed for acceptance.

• Use stronger end-to-end links for regulated or high-impact requirements.
• Use lightweight backlog relationships for routine stories that are still evolving.
• Refresh traceability when stories are split, merged, reprioritized, or moved.

The predictive-style idea of maintaining identical detailed trace links for every story from the earliest draft is the anti-pattern because it maximizes effort instead of tailoring control.

An adaptive traceability strategy should vary by risk and stability, so forcing full detail on every evolving story creates waste without improving control.

Question 50

Topic: Traceability and Monitoring

A compliance requirement is currently marked Approved and traced to release 1. During change review, the board decides to move it to release 2 because a vendor interface will not be available in time. The traceability tool supports status history entries and rationale notes. What should the business analyst do next?

• A. Wait for release 2 planning to confirm scope before updating the tool.
• B. Add a Deferred history entry, cite the decision and reason, and notify impacted stakeholders.
• C. Email stakeholders about the deferral and leave the traceability record unchanged for now.
• D. Overwrite Approved with Deferred and remove prior rationale notes.

Best answer: B

What this tests: Traceability and Monitoring

Explanation: The best next step is to record a new lifecycle status entry instead of overwriting the existing one. Traceability updates should preserve history and rationale, and the change should be communicated to stakeholders who rely on the requirement’s current status.

The core concept is maintaining an auditable requirement lifecycle in the traceability artifact. In this scenario, the requirement was previously approved, but a formal decision moved it to a later release because of an external dependency. The BA should update the tool by adding a new status entry that retains the earlier approved state, documents the reason for the change, and references the governing decision. The BA should also notify impacted stakeholders so planning, testing, and downstream decisions reflect the new status.

Overwriting the old status destroys history, delaying the update leaves the artifact inaccurate after a decision has already been made, and relying on email alone creates a communication trail without maintaining the official traceability record.

This preserves the requirement’s lifecycle history, records the rationale for the change, and keeps affected stakeholders aligned.

Questions 51-75

Question 51

Topic: Needs Assessment

A business analyst is helping define project objectives for a regional bank. The approved solution scope includes an online small-business loan application, automated document completeness checks, and status alerts to applicants. Current performance is an average of 10 days to complete onboarding, and 18% of applications require rework because documents are missing. Credit policy changes are explicitly out of scope. Which project objective is the best fit?

• A. Implement an online application portal with automated applicant notifications.
• B. Increase small-business loan approval rates by 20% this year.
• C. Reduce onboarding time to 6 days and rework to 8% within 6 months of launch.
• D. Improve the customer onboarding experience for small-business applicants.

Best answer: C

What this tests: Needs Assessment

Explanation: The best project objective converts the scoped solution into measurable business outcomes, not just deliverables or broad intentions. It should stay within scope and define the operational improvement the solution is expected to achieve.

A strong project objective should translate solution scope into a clear business result with measurable targets. In this case, the scoped capabilities—online application intake, document completeness checks, and status alerts—are intended to reduce cycle time and rework. An objective framed around faster onboarding and fewer incomplete applications is outcome-focused because it defines the business performance change the project should produce, not merely what will be built.

The best fit should be:

• specific enough to guide planning and evaluation
• measurable against a current baseline
• achievable through the scoped solution
• limited to outcomes the project can reasonably influence

An option centered on approval rates is weaker because credit policy is out of scope, so that result is not directly tied to this solution.

This objective is specific, measurable, outcome-focused, and directly tied to the approved solution scope.

Question 52

Topic: Planning

A business analyst is reviewing a draft requirements package for a self-service insurance claims portal. Sponsors said the solution should reduce service cost and help customers resolve claim questions faster.

Draft note: Metrics and acceptance

Success measures:
- Publish 40 knowledge articles
- Train 120 service representatives
- Complete 95% of user stories by release
- Hold weekly stakeholder demos

Before the package is baselined, what is the most important improvement?

• A. Define business outcome metrics with baselines and targets
• B. Specify how often the measures will be reported
• C. Add document version control and approval owners
• D. Group the items by deliverable type for readability

Best answer: A

What this tests: Planning

Explanation: The draft lists activities and delivery progress, not business metrics. The most important fix is to add outcome-based measures tied to the business need, such as reduced call volume, lower servicing cost, or faster claim resolution, with clear baselines and target values.

This item tests whether the package distinguishes business metrics from delivery metrics or activity counts. Publishing articles, training staff, completing user stories, and holding demos may support delivery, but none proves the portal met the business need of lowering service cost and speeding customer resolution. Before baselining, the BA should collaborate with stakeholders to define measurable business outcomes and acceptance thresholds.

Good business metrics here would include items such as:

• reduction in claims-status call volume
• decrease in average servicing cost per inquiry
• improvement in average time for customers to resolve common claim questions
• baseline and target values for each measure

Versioning, formatting, and reporting cadence are useful planning details, but they do not correct the core flaw: the package cannot evaluate solution success if it only tracks project work instead of business value.

These items are delivery activities and project progress measures, so the package needs business metrics that show whether the solution achieved the intended value.

Question 53

Topic: Traceability and Monitoring

A business analyst on a hybrid claims-processing project must send a steering committee status report in 2 hours. A high-risk compliance requirement, R-27, shows conflicting statuses: the approved traceability tool lists it as Validated, the UAT defect log shows an open severity-1 defect tied to it, and the release readiness report says Ready for deployment. In this organization, the traceability tool is the system of record for requirement status, and other reports should reflect it. The product owner and test lead are available now. What should the business analyst do first?

• A. Wait for formal change control before changing any status fields.
• B. Set every artifact to failed until the defect is closed.
• C. Verify status with the owners, update the system of record, then refresh reports.
• D. Flag the mismatch in the steering report and reconcile artifacts later.

Best answer: C

What this tests: Traceability and Monitoring

Explanation: The best priority is to confirm the actual requirement status with the responsible stakeholders and update the traceability tool first because it is the approved source of truth. Once that record is correct, the BA can align downstream reports and communicate a consistent status.

This tests lifecycle status control across related artifacts. When requirement status is inconsistent, the BA should not optimize for speed of reporting alone or make assumptions from one artifact. The right move is to confirm the current state with the appropriate stakeholders who own the evidence, then record that status in the approved traceability repository before updating summary reports.

That sequence matters because:

• it preserves one authoritative status record
• it reduces conflicting messages to decision-makers
• it supports traceability toward closure
• it creates an auditable basis for follow-on reporting

Waiting for change control confuses a status update with a scope change, and forcing all artifacts to a negative status without validation may be inaccurate. The key takeaway is to correct the source record first, then synchronize dependent artifacts and communications.

This best preserves requirement status integrity by confirming the true lifecycle state, recording it in the authoritative traceability artifact, and then aligning dependent reports.

Question 54

Topic: Planning

A BA is supporting a regulated project in sprint 3. An operations manager requests a new exception-reporting feature that would change compliance logic and add an external data feed.

Exhibit:

Governance model: Hybrid
Requirements baseline: Approved for Release 1
Team may: refine stories and reprioritize work within approved features
Formal change control required if a request:
- adds/removes a baseline feature
- changes a compliance rule or external interface
- affects release date or vendor contract
Approval path: BA logs request, performs impact analysis, CCB decides

Based on the exhibit, what change control process best fits this request?

• A. Log a formal change request, assess impacts, and route it to the CCB
• B. Add the item to the backlog for product owner prioritization
• C. Update the baseline requirements after sponsor verbal approval
• D. Treat the request as story refinement within team authority

Best answer: A

What this tests: Planning

Explanation: The exhibit defines a hybrid governance model with clear limits on team autonomy. Because the request changes both a compliance rule and an external interface, it must follow formal change control with impact analysis and CCB review rather than normal backlog refinement.

The key concept is matching the change control method to the project’s governance rules, not to the team’s delivery cadence alone. Even in a hybrid model, some changes can be handled informally within the team, while others must follow formal governance. Here, the exhibit explicitly says formal change control is required for any request that changes a compliance rule or external interface. This request does both, and the approval path is also specified: the BA logs the request, performs impact analysis, and sends it to the CCB for decision.

A backlog-only path would fit reprioritization within approved features, but this request changes the approved baseline. The best fit is the formal process defined in the governance model.

The request changes compliance logic and an external interface, so it meets the stated triggers for formal CCB-based change control.

Question 55

Topic: Needs Assessment

A business analyst is reviewing a draft needs assessment package for a utility company.

Business need: Billing-related contact center volume increased 18% in 6 months.
Analysis shows 42% of calls are simple balance-check or due-date questions.

Approved solution scope: Add balance visibility and payment reminders
to the mobile app for retail customers.

Draft project objective: "Launch the new mobile billing features in Q2
to improve customer experience."

Which feedback is MOST important?

• A. Add the objective owner and reporting cadence for status reviews.
• B. State more explicitly that only retail customers are in scope.
• C. Rewrite the objective to state a measurable business outcome, not just feature delivery.
• D. Add dependencies on the mobile release and training activities.

Best answer: C

What this tests: Needs Assessment

Explanation: The draft objective is mainly an implementation milestone with a vague benefit statement. A strong project objective should express the intended business result from the scoped solution in measurable terms, such as reducing routine billing calls or increasing self-service use.

The core issue is that the draft objective is output-focused instead of outcome-focused. “Launch the new mobile billing features in Q2” describes delivery, and “improve customer experience” is too vague to guide decisions or measure success. In needs assessment, project objectives should translate approved solution scope into a specific business result that supports the business need.

A better objective would:

• link to the business problem identified in the package
• state the intended result of the solution
• include a measurable target or success measure
• remain within the approved solution scope

The scope tells the team what will be delivered; the objective should clarify why that delivery matters and how success will be recognized. Adding ownership, scope wording, or dependencies can help governance, but those are secondary to fixing the objective itself.

Project objectives should convert solution scope into a specific, targetable result tied to the business need, rather than restating implementation work.

Question 56

Topic: Planning

A BA is planning work for an insurer’s claims platform enhancement. The sponsor says the scope and depth of BA activities should be tailored to the project’s primary objective. Which objective should lead the BA to plan the most detailed requirements, end-to-end traceability, and formal sign-off?

• A. Improve adjuster satisfaction with a simpler claims screen
• B. Reduce average claim intake time by 15%
• C. Launch a new upsell offer before storm season
• D. Comply with new audit rules for all claim-payment overrides

Best answer: D

What this tests: Planning

Explanation: The project objective that most affects BA scope and depth is the one that demands the highest rigor. A compliance and audit objective expands stakeholder involvement, documentation detail, traceability, and approval needs far more than objectives focused mainly on usability, efficiency, or timing.

When reviewing project goals and objectives, the BA should identify which one changes the required level of certainty and control. A compliance objective tied to audit rules usually increases BA work the most because it requires precise business rules, exception handling, traceability from objective to requirements to test results, and formal validation with stakeholders such as compliance, operations, and audit. That drives deeper planning for requirements management, sign-off, and change control.

Objectives centered on usability, process efficiency, or market timing can still be important, but they often allow a lighter BA approach if the risk of noncompliance is low. The deciding factor is the objective’s need for evidence, approval rigor, and traceable coverage, not simply its business importance.

A compliance objective with auditability requirements drives the greatest need for detailed analysis, traceability, validation evidence, and formal approval.

Question 57

Topic: Evaluation

A bank is preparing enterprise rollout of a new loan origination solution in 2 weeks. After QA and user validation, four unresolved deltas remain:

• A manual interest-rate override saves correctly, but the system does not record approver ID and timestamp, despite a compliance requirement for a complete audit trail; this affects every branch and has no manual workaround.
• A manager dashboard loads in 8 seconds instead of the 3-second target for 20 regional managers.
• Customer welcome emails still use the old product branding.
• Training materials omit a rare refinance scenario that trainers can explain live.

Which gap should the business analyst recommend addressing first?

• A. Outdated branding in customer welcome emails
• B. Missing training content for a rare refinance case
• C. Missing audit trail for rate override approvals
• D. Slow response time on the manager dashboard

Best answer: C

What this tests: Evaluation

Explanation: The first priority should be the gap with the greatest combined business impact and deployment risk. A missing audit trail on a compliance-controlled approval process is more serious than performance inconvenience, branding issues, or a training gap with a workaround.

When prioritizing post-build gaps or deltas, the BA should weigh both severity of business impact and likelihood of deployment failure or unacceptable operational risk. The missing approval audit trail is the strongest candidate for immediate action because it violates an explicit compliance requirement, affects a core control used across all branches, and cannot be mitigated manually after go-live.

A practical prioritization lens is:

• Regulatory or control failure
• Breadth of affected users/processes
• Availability of a workaround
• Effect on go-live readiness

The dashboard delay matters, but it affects a smaller audience and is not described as blocking operations. The branding issue is cosmetic, and the training omission has a live workaround. The key takeaway is to escalate the gap that most threatens compliant and safe deployment, not merely the most visible inconvenience.

It has the highest business impact and deployment risk because it breaks a compliance control, affects broad operations, and lacks a viable workaround.

Question 58

Topic: Traceability and Monitoring

On a claims system project, requirements are baselined and traced to interface specifications, test cases, and training materials. The change control plan requires documented impact analysis and formal approval before any baselined change is implemented. A new legal disclosure is requested. The BA logs the request, updates a draft requirement, and asks architecture and QA to review impacts. After the product owner says the change is urgent, developers begin work even though interface and test impacts are still being analyzed. What is the most serious flaw?

• A. Involving architecture and QA before the change board review
• B. Logging the change request before detailed analysis is finished
• C. Starting implementation before impact analysis and approval are complete
• D. Updating a draft requirement before the final decision is made

Best answer: C

What this tests: Traceability and Monitoring

Explanation: The key problem is breaking change control discipline on a baselined requirement. Work started before the BA completed impact analysis of traced artifacts and before formal approval, which threatens the integrity of requirements, interfaces, and tests.

For baselined requirements, change management must preserve traceability and configuration integrity. In this scenario, the BA correctly logged the request and involved impacted disciplines, but the team began implementation while analysis of linked interface and test artifacts was still incomplete and before the required approval was finished. That is the most serious flaw because it can lead to partial changes, missed dependencies, inconsistent versions, and defects that are discovered late.

A sound sequence is:

• log the change request
• analyze impacts, dependencies, and risks across traced artifacts
• compare the proposed change to the current baseline
• obtain formal approval, then update the baseline and proceed

Using a draft for analysis is acceptable; implementing against an incompletely analyzed, unapproved change is not.

This bypasses controlled change on a baselined requirement and risks incomplete downstream updates to linked artifacts.

Question 59

Topic: Needs Assessment

A BA is supporting a new claims platform. Operations wants faster processing, compliance wants stronger auditability, and customer service wants fewer handoffs. The BA gathered each group’s desired features, but backlog priorities keep changing after every review, approved items are repeatedly reopened, and pilot users say high-value needs were missed. What is the most likely underlying BA gap?

• A. No agreed value-based prioritization baseline across stakeholders
• B. No decomposition of requirements into smaller components
• C. No detailed acceptance criteria for solution features
• D. No formal change control for approved requirements

Best answer: A

What this tests: Needs Assessment

Explanation: The symptoms point to a missing stakeholder value baseline, not just weak downstream control. When competing groups define value differently and the BA does not compare and reconcile those inputs, priorities churn and the solution can miss what matters most.

This is a stakeholder-value problem in needs assessment. The BA did elicit inputs, but simply collecting feature requests is not enough when stakeholder groups value different outcomes. The missing step is to compare those value drivers, identify relative importance, and establish a shared prioritization baseline that can guide later requirement ranking and trade-off decisions. Without that baseline, priorities shift based on influence or recency, approved items are questioned, and users later feel that important needs were overlooked.

A strong BA response would define common value criteria such as speed, compliance, and customer impact; reconcile stakeholder differences; and document the agreed basis for prioritization. Formal controls and detailed requirements help later, but they do not solve the core problem of competing value inputs that were never aligned at the start.

The BA collected inputs but did not reconcile stakeholder value criteria into a shared baseline for prioritizing requirements.

Question 60

Topic: Needs Assessment

A retail bank is considering an initiative that lets customers submit card disputes in the mobile app. Executives expect fewer branch visits and faster resolution, but operations managers argue most delays come from back-office rework. The investment committee wants a credible value estimate before approving the initiative. Which combination of source information would best help the business analyst evaluate the initiative’s value?

• A. Current dispute metrics, servicing costs, and customer complaint analysis
• B. Draft user stories, architecture estimates, and vendor demo notes
• C. Training needs, rollout dependencies, and branch readiness assessments
• D. Sponsor interviews, competitor feature lists, and industry trend reports

Best answer: A

What this tests: Needs Assessment

Explanation: To evaluate initiative value, the business analyst needs source information that connects the business problem to measurable benefits. Current performance data, unit costs, and customer pain points together support a realistic value proposition and help test whether the proposed initiative addresses the true cause of delays.

In needs assessment, initiative value is best evaluated by combining sources that show the current problem, its financial impact, and the stakeholder value expected if the problem is improved. Here, there is disagreement about the root cause of slow dispute resolution, and the investment committee wants a credible estimate, not just opinions. That makes baseline operational metrics, cost data, and customer-impact information the strongest mix.

Using these sources lets the BA:

• quantify the current pain with cycle time, volume, and rework data
• estimate economic impact through servicing cost and avoided effort
• confirm customer value through complaint themes and experience issues

The other combinations support strategy scanning, solution design, or deployment planning, but they do not provide the best evidence for valuing the initiative before approval.

This combination gives baseline performance, cost, and customer-impact evidence needed to assess whether the initiative will create measurable value.

Question 61

Topic: Analysis

A business analyst is defining requirements for a hospital patient-admission process redesign. Written procedures are 6 months old, and supervisors report that clerks handle insurance exceptions differently at each location. The project needs detailed current-state workflow steps and exception business rules before drafting requirements. What should the business analyst do next?

• A. Request sign-off on the existing procedures as the current-state baseline
• B. Send a questionnaire to clerks about issues and desired changes
• C. Run a workshop with supervisors to prioritize process improvements
• D. Conduct observation sessions with admission clerks and ask clarifying questions

Best answer: D

What this tests: Analysis

Explanation: Direct observation is the best next step because the analyst needs factual current-state steps and exception business rules, and the existing documents are already known to be unreliable. When work varies by location and includes tacit practices, watching users perform the process reveals what interviews or documents may miss.

The core concept is matching the elicitation technique to the stakeholder situation and the requirement type. Here, the analyst needs detailed current-state process behavior and exception rules from frontline users, while the documented procedures are outdated and actual practices differ across sites. That makes observation the strongest next step because it captures real work as performed, including undocumented workarounds and decision points.

• Use observation when work is procedural, variable, or partly tacit.
• Add clarifying questions to confirm origin and rationale for exceptions.
• Use the findings to build accurate workflow and business rule requirements.

A survey can collect broad opinions, but it will not reliably expose detailed exception handling, and prioritization or sign-off should wait until the actual process is understood.

Observation is best for uncovering actual workflow details and tacit exception handling when documented procedures are outdated or inconsistently followed.

Question 62

Topic: Planning

A BA is defining the minimum traceability needed for a customer onboarding project. The team already reviews requirement status weekly and plans user acceptance testing next month.

Exhibit: Traceability matrix excerpt

Based on the exhibit, which action is most essential to support monitoring and validate these requirements?

• A. Link each requirement to training deliverables.
• B. Link each requirement to budget line items.
• C. Link each requirement to stakeholder communications events.
• D. Link each requirement to acceptance criteria or test cases.

Best answer: D

What this tests: Planning

Explanation: The exhibit already shows origin, business purpose, solution mapping, and lifecycle status. What it does not show is how each requirement will be proven met, so the most essential missing trace is to acceptance criteria or test cases.

Traceability should be planned to support specific decisions. In this exhibit, the BA can already monitor requirements at a basic level because each requirement has a source, business objective, solution component, and lifecycle status. The missing downstream link is the one needed for validation: a connection from each requirement to acceptance criteria or test cases.

That link helps the team:

• confirm every approved requirement has planned verification
• identify gaps before UAT begins
• show whether delivered functionality satisfies the stated requirement

Links to training, budget, or communication activities may be useful for broader project management, but they do not directly establish whether the requirement can be validated as met.

These links provide the evidence path from requirement to validation, which is the key gap in the current traceability slice.

Question 63

Topic: Analysis

A business analyst is reviewing a draft requirements package for a CRM-to-billing integration. Developers say they cannot size the work yet.

Business objective: Reduce returned invoices.
Draft requirement: When an address change is approved in CRM, the system must send the update to Billing immediately.
Interface note: Send customer ID, service address, mailing address, effective date, and approval status. Billing updates the account and returns success or error to CRM.
Acceptance criterion: Approved changes are reflected in Billing without manual re-entry.

What is the most important improvement needed to make this interface requirement actionable for downstream development?

• A. Add document version history and approver names.
• B. Add field-level mappings, formats, required status, and validation rules.
• C. Add a specific response-time target for the update and confirmation.
• D. Add the exact CRM success and error message wording.

Best answer: B

What this tests: Analysis

Explanation: The core problem is that the interface is still too vague at the data-definition level. Listing a few fields is not enough for integration work; the package needs clear source-to-target mappings, formats, required versus optional fields, and validation or transformation rules.

For interface requirements, the most important quality goal is actionability: developers and testers must know exactly what data moves, in what structure, under what rules, and with what expected outcomes. In this draft, the requirement names several data elements but does not define how each field maps between CRM and Billing, what format each field uses, which fields are mandatory, or what validation and transformation rules apply. Without those details, the team cannot reliably estimate the effort or build the integration correctly.

Useful interface details often include:

• source and target field names
• data type and format
• required or optional status
• business rules, transformations, and validation
• error conditions and handling behavior

Performance targets, message wording, and document control are helpful, but they do not resolve the main ambiguity blocking downstream integration work.

Developers need unambiguous source-to-target data definitions and rules before they can estimate, build, and test an interface.

Question 64

Topic: Needs Assessment

A retailer is assessing a new omnichannel returns process that will change work for store associates, warehouse staff, finance, fraud, and customer service. Most workshops so far have been attended only by store operations managers. Which artifact would best validate that the correct stakeholder groups have been identified and that their influence and impact are understood before requirements are defined?

• A. Requirements elicitation calendar for the next four weeks
• B. Stakeholder matrix mapping roles to influence, impact, and RACI responsibilities
• C. Workshop attendance summary by department and meeting count
• D. Current-state returns process flow with handoff timings

Best answer: B

What this tests: Needs Assessment

Explanation: The best evidence is an artifact that analyzes stakeholder influence and impact, not one that only shows activity. A stakeholder matrix with role and RACI-style information validates whether the right parties are represented and how they should be involved before detailed requirements begin.

In needs assessment, stakeholder identification is validated by analysis of who is affected, who can influence outcomes, and who must participate in decisions. A stakeholder matrix that links roles or personas to impact, influence, and engagement responsibility provides that evidence directly. In this scenario, workshop participation is skewed toward store operations managers, so the BA needs an artifact that exposes whether warehouse, finance, fraud, and customer service are missing or underrepresented. RACI-style role mapping also clarifies who should be responsible, accountable, consulted, or informed as requirements are shaped. Attendance counts show effort, a process flow shows work steps, and a calendar shows planning, but none of those confirm that stakeholder coverage is complete and appropriate.

It directly shows who is affected, who has authority, and how each role should participate in the change.

Question 65

Topic: Analysis

A business analyst is supporting a hybrid release for a customer onboarding portal. A signed requirement states, “The portal must provide a fast and intuitive onboarding experience.” The sales sponsor expects lower abandonment, QA says release governance requires approved acceptance criteria before UAT, and the delivery team needs testable details in the current sprint because the release window is four weeks away. What is the BEST business analysis action?

• A. Have QA derive test cases from the approved wording now.
• B. Refine it with stakeholders into measurable metrics and acceptance criteria.
• C. Wait for a prototype and let users judge intuitiveness later.
• D. Trace it to the business case and measure value after go-live.

Best answer: B

What this tests: Analysis

Explanation: The requirement is too vague to support meaningful measurement because “fast” and “intuitive” are subjective and lack testable thresholds. The BA should work with stakeholders now to elaborate the requirement into detailed metrics and acceptance criteria that satisfy governance and guide delivery.

A requirement supports meaningful measurement only when it describes an observable outcome and the threshold for success. In this case, “fast” and “intuitive” are useful intent statements, but they are not specific enough for development, testing, or approval because different stakeholders can interpret them differently. Since QA needs approved acceptance criteria before UAT and the team needs actionable detail in the current sprint, the BA should immediately facilitate refinement with the relevant stakeholders to define measurable criteria such as completion time, abandonment rate, error rate, or satisfaction target, along with how each will be measured. Simply tracing the vague requirement, asking QA to guess at tests, or delaying clarification until a prototype exists leaves the requirement ambiguous. The key takeaway is that subjective wording must be converted into measurable criteria before it can be validated.

The requirement uses subjective terms, so the BA must collaborate now to define observable, testable measures before build and UAT proceed.

Question 66

Topic: Analysis

A business analyst is elaborating requirements for a claims-processing enhancement. The current requirement says, “Supervisors can override an auto-rejected claim when appropriate.” During review, operations asks which conditions allow an override and what audit data must be stored, while a senior manager starts specifying screen layout, button labels, and color coding. Development says the story is not ready for estimation. What should the business analyst do next?

• A. Send the requirement to developers and ask them to determine the missing business logic during design.
• B. Document all requested screen behavior and visual details to remove any ambiguity before estimation.
• C. Obtain stakeholder approval on the requirement as written so the team can estimate and refine later.
• D. Facilitate analysis to define override rules, required audit data, and interface needs while deferring nonessential UI design details.

Best answer: D

What this tests: Analysis

Explanation: The best next step is to analyze the requirement to uncover the missing business rules and data needed for implementation readiness. The manager’s layout and color preferences are design details that go beyond the essential requirement at this stage.

This situation tests the difference between missing detail and unnecessary over-specification. The requirement is missing important analysis detail because “when appropriate” does not define the business conditions for an override, the needed audit trail, or any relevant interface interaction. Those gaps prevent estimation and downstream validation. The business analyst should work with stakeholders to elaborate the requirement to the level needed for shared understanding and delivery readiness, while separating true business needs from design preferences.

• Clarify the business rules for when an override is allowed.
• Identify the required audit data and any compliance or traceability needs.
• Capture only interface details that affect business behavior or integration.
• Park visual design preferences for later UX or solution design work.

A strong analyst adds necessary precision, not every possible detail.

This adds the missing business detail needed for a usable requirement while avoiding premature design over-specification.

Question 67

Topic: Needs Assessment

A business analyst is assessing two first-release options for a regulated customer onboarding product. Elicitation showed these stakeholder values:

• The sponsor and compliance lead value avoiding regulatory findings more than maximizing first-release features.
• Operations requires at least a 20% reduction in onboarding time in the first release.
• Stakeholders are willing to defer lower-value features if the business benefit threshold is met.

Option Alpha delivers a projected 30% reduction but depends on a new vendor that has unresolved compliance and schedule risk. Option Beta delivers a projected 21% reduction on an approved platform, with lower risk, but defers advanced analytics. What should the business analyst recommend?

• A. Delay the decision until one option provides Alpha’s scope on Beta’s platform.
• B. Recommend Option Alpha and address compliance exposure after release.
• C. Recommend Option Beta because it meets the benefit threshold with lower risk.
• D. Recommend Option Alpha because the larger scope offers the highest projected benefit.

Best answer: C

What this tests: Needs Assessment

Explanation: Stakeholder values should drive the tradeoff, not just the largest projected benefit. Since stakeholders explicitly prioritize regulatory safety and accept deferred lower-value features, the option that still meets the 20% benefit threshold with less risk is the best fit.

This decision is about using elicited stakeholder values as the baseline for prioritization and tradeoffs. The key facts are that stakeholders value avoiding regulatory findings more than maximizing first-release scope, they require at least a 20% onboarding improvement, and they are willing to defer lower-value features. Option Beta satisfies the required benefit at 21% and does so on an approved platform with lower compliance and schedule risk, so it aligns with both the value hierarchy and the minimum success measure.

Option Alpha offers more scope and more projected benefit, but those extra gains do not outweigh the higher risks under the stated stakeholder priorities. The best choice is the option that clears the benefit threshold while honoring the more important stakeholder value.

It best matches stated stakeholder values by meeting the minimum required benefit while favoring lower compliance and delivery risk over extra first-release scope.

Question 68

Topic: Planning

A business analyst is drafting the review note for a requirements package on a hybrid project involving sales, operations, and compliance. Previous package reviews were delayed because managers disagreed and some reviewers did not respond on time.

Draft requirements package review note
- Distribution: Email package to stakeholders and post to SharePoint
- Review method: Reviewers send comments to the BA within 3 business days
- Update method: BA consolidates comments and issues a revised version if needed
- Status tracking: Final status will be recorded in the traceability matrix

Which improvement is most important to add?

• A. Include a glossary for business and compliance terms
• B. Add version numbering and document naming conventions
• C. Add a walkthrough meeting schedule for each package release
• D. Define approvers, response deadlines, and escalation steps for conflicts or nonresponse

Best answer: D

What this tests: Planning

Explanation: The draft note explains distribution and comment collection, but it does not define how review decisions are made. For requirements review, approval, and escalation, the key missing protocol is decision authority, timing, and what happens when reviewers disagree or do not respond.

In a requirements management plan, communication protocols need to do more than describe how documents are shared. They should also specify who reviews, who approves, when responses are due, and how issues are escalated if reviewers disagree or miss deadlines. That is the critical control point in this scenario because past reviews have already stalled from conflict and nonresponse.

A strong protocol typically clarifies:

• required reviewers and approvers
• response time expectations
• escalation path for overdue or disputed items
• how approval status is recorded

Version control, glossaries, and scheduled walkthroughs can improve quality, but they do not solve the main risk: requirements cannot be approved efficiently without clear decision and escalation rules.

A review protocol must identify who can approve and how unresolved or overdue reviews will be escalated so requirements can be formally decided and baselined.

Question 69

Topic: Planning

A business analyst must define the traceability strategy for four upcoming initiatives. For which initiative is full bidirectional traceability most warranted, rather than lighter traceability limited to key features and acceptance criteria?

• A. Adding filter and sort options to an internal knowledge base used by one department and delivered in a single sprint by one team
• B. Refreshing marketing email templates and campaign images with no integration or process changes
• C. Replacing an anti-money-laundering workflow across six systems with regulatory audit exposure, phased deployment, and formal approval by compliance, operations, and IT
• D. Creating a clickable prototype for a possible loyalty app to test customer interest before funding is approved

Best answer: C

What this tests: Planning

Explanation: Full bidirectional traceability is most appropriate when the change is high risk, highly governed, and dependent on many downstream artifacts. The anti-money-laundering initiative has regulatory scrutiny, multiple systems, phased release, and formal approvals, so requirement lineage must be controlled end to end.

The core decision is to tailor traceability to the level needed for monitoring, validation, change control, and approval. Full bidirectional traceability is warranted when a change has significant compliance exposure, multiple system and process dependencies, formal sign-off needs, and a strong likelihood that teams will need to trace backward from defects, tests, or design elements to the original requirement and business objective.

In this case, the anti-money-laundering replacement clearly justifies that level of rigor because it involves:

• regulatory auditability
• six-system dependency management
• phased deployment and status tracking
• multiple approval authorities

Lighter traceability is usually sufficient for low-risk, isolated, exploratory, or cosmetic work where the cost of maintaining full linkage outweighs the control benefit. The closest distractors may still need some traceability, but not the full bidirectional coverage required here.

This initiative has the strongest need to trace requirements forward and backward across approvals, designs, tests, interfaces, and regulatory obligations.

Question 70

Topic: Traceability and Monitoring

A retailer’s order-management project has an approved requirements baseline. During pilot testing, the sales director requests faster handling of high-value orders. The BA reviews this excerpt:

Requirements baseline v2.1
R-12: Orders over \$25,000 must enter manual credit review within 48 hours.
Status: Baselined
Links: BR-3, IF-2, TC-7, TC-8, TG-4
Dependent requirement: R-19 Customer receives hold/release notice after review

Change request CR-14
Requested change: Replace "48 hours" with "4 hours"
Change control plan:
- Do not edit baselined requirements before approval
- Assess impacts to linked artifacts and dependent requirements
- If approved, issue a new version and update traceability

What should the BA do next to preserve the integrity of the requirements baseline while incorporating the requested change?

• A. Assess all impacts, seek approval, then version the baseline
• B. Defer the request until after implementation because baseline is fixed
• C. Revise the baselined requirement now and update test cases
• D. Update only the dependent notification requirement after agreement

Best answer: A

What this tests: Traceability and Monitoring

Explanation: The exhibit states that baselined requirements cannot be edited before approval, and that impact analysis must cover linked artifacts and dependent requirements. Therefore, the BA should assess the change comprehensively, route it through change control, and only then create a new version of the baseline and update traceability.

The core concept is maintaining baseline integrity while allowing controlled change. A requirements baseline is the approved reference point, so it should not be overwritten just because a stakeholder requests a change. In this case, the exhibit explicitly requires impact analysis across the linked rule, interface, test cases, training material, and the dependent notification requirement before a decision is made.

A sound BA response is to:

• compare the requested 4-hour target to the current baseline
• analyze downstream impacts, dependencies, and risks
• submit the change for approval under the change control plan
• if approved, issue a new version and refresh traceability

Directly editing the current baseline may seem efficient, but it breaks configuration discipline and obscures what was originally approved.

This follows the change control plan by preserving the current baseline until the change is approved and then updating it through version control and traceability.

Question 71

Topic: Planning

A BA is planning analysis for a retailer’s returns-system update. The business case lists these objectives: reduce refund cycle time by 20%, improve customer satisfaction, and comply with a new refund regulation effective in four months. Internal audit requires rule-to-test traceability for any policy change, and the first release is limited to one region. Which BA action is best when deciding the scope and depth of business analysis work?

• A. Plan BA depth around the regulatory compliance objective.
• B. Plan BA depth around the customer satisfaction objective.
• C. Plan BA depth around the cycle-time reduction objective.
• D. Plan BA depth around the regional rollout limit.

Best answer: A

What this tests: Planning

Explanation: The objective that most affects BA scope and depth is the one that creates the strongest governance, risk, and verification demands. Here, regulatory compliance requires detailed rule analysis, end-to-end traceability, and formal validation, so it should drive the BA approach.

When reviewing a business case to plan BA work, the key is not simply which objective sounds most valuable or most visible. The main driver of BA scope and depth is the objective that creates the broadest analysis impact and the highest need for rigor. In this scenario, the compliance objective does that because it carries a fixed deadline, affects policy changes, and triggers internal audit expectations for traceability from business rules through testing.

That means the BA must plan for deeper analysis such as:

• identifying all impacted rules and processes
• tracing requirements to regulation and test evidence
• validating with audit, operations, and other stakeholders
• defining precise acceptance criteria

The cycle-time and satisfaction goals still matter, but they do not require the same level of formal control and proof.

The compliance objective drives the deepest analysis because it requires formal traceability, cross-functional validation, and audit-ready evidence.

Question 72

Topic: Evaluation

A BA is reviewing UAT evidence for an insurance renewal portal before production sign-off. The sponsor will allow one deferred defect, but any failed acceptance criterion tied to compliance must block release.

Acceptance criteria

• Premium shown in the portal must match the generated renewal notice.
• Paperless-delivery consent must store date, time, and channel.
• The renewal notice PDF must open within 2 seconds for 95% of users.
• A customer service representative must be able to resend a notice without supervisor approval.

Failed test result A customer enrolled in paperless delivery through the mobile app. The portal showed success, and the audit log stored the date and time, but not the channel. The premium matched, the PDF opened in 1.4 seconds, and a representative resent the notice successfully.

Which acceptance criterion did the failed test result violate?

• A. A customer service representative must be able to resend a notice without supervisor approval.
• B. Paperless-delivery consent must store date, time, and channel.
• C. Premium shown in the portal must match the generated renewal notice.
• D. The renewal notice PDF must open within 2 seconds for 95% of users.

Best answer: B

What this tests: Evaluation

Explanation: The failed result must be traced to the specific acceptance criterion that was not satisfied. Here, the consent record captured only two of the three required audit elements, so the paperless-consent criterion failed even though the other tested outcomes passed.

In solution evaluation, the BA compares actual test evidence to the exact wording of the acceptance criteria. This test failed because the consent audit record did not include the channel, while the criterion requires date, time, and channel. Since the stem also notes that compliance-related failures block release, this gap is especially important for the go/no-go decision.

The other observed results met their criteria:

• Premium matched the renewal notice.
• PDF response time was 1.4 seconds, which is within 2 seconds.
• The representative resent the notice successfully.

The key takeaway is to map the defect to the most directly violated acceptance criterion, not to a broader operational concern.

The test evidence shows the consent record is missing the channel, so that acceptance criterion is not fully met.

Question 73

Topic: Planning

A financial services company is delivering a hybrid project with 2-week increments. Some requirements support consumer-protection compliance and audit reporting, while others are low-risk usability improvements. The BA must define the traceability strategy before analysis begins. Which approach best determines the appropriate level of traceability for this context?

• A. Delay traceability planning until testing reveals which requirements need stronger control.
• B. Trace only approved user stories to final test cases to minimize team overhead.
• C. Use risk-based traceability with detailed end-to-end links for compliance and high-risk requirements, and lighter links for low-risk enhancements.
• D. Require full bidirectional traceability for every requirement from business need through deployment.

Best answer: C

What this tests: Planning

Explanation: The best choice is a tailored, risk-based traceability strategy. It provides stronger control where compliance, auditability, and failure impact are high, while avoiding unnecessary overhead for low-risk changes in a fast delivery cycle.

Appropriate traceability is not automatically the maximum possible level. In PMI-PBA practice, the BA plans traceability based on project context such as regulatory exposure, delivery cadence, stakeholder needs, and the consequences of missing or changing a requirement. Here, compliance and audit reporting require strong monitoring and validation, but the project also has frequent increments and low-risk usability work that would not justify the same depth.

A good strategy is to calibrate traceability by requirement type and risk, for example:

• detailed links from business objective or regulation to requirement, design, test, and release evidence for compliance items
• lighter links for low-risk usability changes where simpler monitoring is sufficient
• clear rules in the requirements management approach so the team applies the right level consistently

The closest distractor is tracing everything fully, which improves control but creates avoidable overhead that does not match the mixed-risk context.

This best balances compliance and audit needs with delivery speed by tailoring traceability depth to requirement risk and impact.

Question 74

Topic: Evaluation

A retailer is preparing to deploy a new returns solution. In user acceptance testing, all priority acceptance criteria passed. One issue remains: the fraud-review dashboard loads slowly for supervisors during peak volume, but the sponsor agrees go-live can proceed because supervisors will use the existing report for the first two weeks. The risk owner, operations manager, and sponsor all accept this workaround if the issue is fixed in the first post-deployment release.

How should the business analyst document the sign-off decision?

• A. Mark sign-off as pending until post-deployment monitoring confirms the workaround is effective.
• B. Conditionally approve deployment with the exception, workaround, risk owner, and required follow-up fix documented.
• C. Approve deployment and track the dashboard issue separately as an open defect.
• D. Reject deployment until all remaining issues are resolved and retested.

Best answer: B

What this tests: Evaluation

Explanation: When stakeholders agree to proceed despite a known issue, the BA should record a conditional approval, not a full approval, rejection, or vague pending status. The documentation should clearly state the exception, the approved workaround, who accepted the risk, and what must happen next.

The core concept is accurate sign-off documentation. Here, stakeholders have decided the solution is acceptable for deployment with a known exception, because acceptance criteria for priority needs were met and a temporary workaround was approved. The BA should therefore document a conditional approval that includes the exception, any constraints on use, the risk owner or approver, and the required corrective action after go-live.

A good sign-off record should show:

• what is being approved
• what exception is being accepted
• who accepted the risk
• what condition or workaround applies
• what follow-up action is required

Recording this as unconditional approval hides the exception, while rejection ignores the stakeholder decision to proceed. A pending status is also weaker than the actual governance decision already made.

This captures the actual decision to proceed while formally recording the accepted exception, temporary condition, and accountability for closure.

Question 75

Topic: Planning

A healthcare insurer is preparing for a compliance audit while business analysts in three locations refine requirements with an external vendor. A draft note in the requirements management plan states:

Requirements will be stored in a shared folder.
Editors will add the date to the file name.
Outdated copies may be replaced after an email notice.
Approvals and review comments will remain in email threads.
The BA lead will send the latest file link each Friday.

Before this approach is approved, what is the most important improvement?

• A. Publish a meeting calendar for distributed analysts.
• B. Set target turnaround times for stakeholder reviews.
• C. Use a controlled repository with version, status, and approval history.
• D. Add a glossary for claims and policy terms.

Best answer: C

What this tests: Planning

Explanation: The draft note lacks effective document control for an audited, distributed environment. Overwriting files, using date-based names, and keeping approvals in email do not provide a reliable audit trail or clear version status, so a controlled repository with formal history is the most important improvement.

The core concept is document control strong enough to support traceability, versioning, and auditability. In this scenario, the current approach depends on shared folders, file-name conventions, overwritten copies, and email threads. That may work informally, but it is too weak for compliance review and distributed collaboration because it does not reliably show which version is current, who approved it, what changed, when it changed, and whether a baseline was replaced through controlled change.

A sound improvement would establish:

• unique version identifiers and document status
• retained revision history rather than overwriting
• recorded approvals and review decisions
• one authoritative repository for current and prior baselines

The other suggestions may help team efficiency or clarity, but they do not solve the primary audit and control gap.

This fixes the core weakness by creating an auditable record of versions, baselines, and approvals instead of relying on overwritten files and scattered emails.

Questions 76-100

Question 76

Topic: Evaluation

After solution testing of a loan origination update, a business analyst drafts this discrepancy note for stakeholders:

Discrepancy: Debt-to-income exceptions were sent to manual review.
Evidence: UAT cases 14, 18, and 22 failed.
Observed result: 32% of applications were routed manually.
Expected result: Fewer manual reviews.
Recommendation: Fix the routing logic before release.

To help determine the root of the discrepancy, what is the MOST important improvement to this note?

• A. Include a screenshot of the manual review queue.
• B. Add the release delay risk if the issue remains unresolved.
• C. Trace each failed case to the approved requirement, rule, and acceptance criterion.
• D. List the testers and environment used for each failed case.

Best answer: C

What this tests: Evaluation

Explanation: The note shows a symptom, but it does not yet make the discrepancy diagnosable. To determine root cause, the failed test results must be linked to the exact approved requirement, business rule, and measurable acceptance criterion so stakeholders can compare expected and actual behavior accurately.

In evaluation, QA findings and test results should be documented so stakeholders can identify why a discrepancy exists, not just that one exists. This draft note reports failed UAT cases and a high manual-review rate, but the expected result is vague and not tied to any approved requirement artifact. The most important improvement is to add traceability from each failed test to the specific requirement, business rule, and acceptance criterion it was meant to verify.

That linkage lets stakeholders determine whether the issue comes from incorrect solution logic, a misconfigured rule, an incomplete requirement, or even a poor test design. By contrast, impact details, screenshots, and execution metadata can help communication or reproduction, but they do not establish the root of the mismatch between requirements and the developed solution.

Root cause analysis depends on comparing failed results to the exact approved expected behavior, not just noting that tests failed.

Question 77

Topic: Evaluation

A utilities company deployed a self-service billing portal 3 months ago. The business case said the solution would create value by reducing billing inquiry handling cost. The BA is reviewing the post-implementation evaluation.

Exhibit: Evaluation summary

Which evidence best reflects realized value?

• A. No critical production defects remain open.
• B. Billing inquiry calls decreased from baseline.
• C. Current monthly handling cost is below the business case target.
• D. Portal registration exceeded the adoption target.

Best answer: C

What this tests: Evaluation

Explanation: Realized value is best shown by an achieved business outcome that matches the business case benefit. Here, the promised value was cost reduction, and the current monthly handling cost shows that benefit has been realized and exceeded the target.

When evaluating a deployed solution, the strongest evidence of realized value is the actual outcome metric tied directly to the business case. In this scenario, the value proposition was monthly cost savings from handling fewer billing inquiries. The cost dropped from $180,000 to $136,000, which is a $44,000 monthly reduction and better than the target of at least $40,000.

Registration rate, call volume, and defect status are still useful, but they are supporting indicators. Adoption and operational activity can help explain why value occurred, and quality measures show the solution is stable, but neither is the clearest proof that the expected business benefit was achieved. The key takeaway is to prioritize post-deployment outcome metrics that directly represent the stated value proposition.

This directly measures the post-deployment financial benefit promised in the business case and shows the target has been exceeded.

Question 78

Topic: Analysis

A business analyst is preparing a requirements baseline for a two-release claims solution. To protect the Release 1 date, the sponsor wants to defer audit logging to Release 2 while keeping automated claim approval in Release 1. The compliance manager had previously agreed to Release 1 only if automated approval, audit logging, and segregation-of-duties controls were delivered together. Which artifact would best validate whether this proposed allocation breaks a dependency or stakeholder commitment before the baseline is approved?

• A. A team capacity report for the next two releases
• B. A traceability matrix showing dependencies, release assignments, and acceptance commitments
• C. A prioritized backlog ranked by business value
• D. Elicitation workshop minutes from the allocation discussion

Best answer: B

What this tests: Analysis

Explanation: The best validation evidence is a traceability artifact that links requirements to each other, to planned releases, and to stakeholder acceptance conditions. In this case, the issue is not just priority or capacity; it is whether deferring one control breaks a dependency and violates a compliance commitment.

When allocating accepted and deferred requirements, the BA must validate more than schedule fit. The key evidence is an artifact that shows how requirements relate to one another and what commitments were made by stakeholders for acceptance or approval. Here, automated approval was accepted for Release 1 only when paired with audit logging and segregation-of-duties controls, so splitting them across releases could invalidate the allocation.

A traceability matrix is the strongest evidence because it can show:

• requirement-to-requirement dependencies
• release or increment assignment
• source, rationale, and stakeholder commitment
• impacts of deferral on the baseline

A ranked backlog or capacity report may support planning, but neither proves that the proposed allocation preserves dependency integrity and agreed acceptance conditions.

It directly shows whether linked requirements or conditional stakeholder approvals are being split across releases.

Question 79

Topic: Analysis

A business analyst is reviewing draft requirements for a customer self-service portal before baseline approval. The team agreed that each requirement must be clear, measurable, and actionable for development and testing. Which draft requirement should NOT be approved?

• A. The system shall allow customers to upload PDF or JPG files up to 10 MB.
• B. The system shall display account status within 2 seconds for 95% of inquiries.
• C. The system shall retain submitted applications for 7 years from the submission date.
• D. The system shall provide a simple and intuitive dashboard for customers.

Best answer: D

What this tests: Analysis

Explanation: The dashboard requirement has the most serious defect because its wording is subjective and cannot be objectively verified. A well-written requirement must be specific enough for developers to implement and testers to confirm without relying on personal interpretation.

The core issue is requirement quality: a written requirement should be unambiguous, measurable, and actionable. In this scenario, “simple” and “intuitive” are vague quality statements, not verifiable requirements, unless they are backed by measurable criteria such as task completion rate, training time, or usability scores. Without objective criteria, different stakeholders could interpret success differently, which makes the requirement unsuitable for baseline and testing. By contrast, the other statements define clear limits or conditions: response time, supported file types and size, and a retention period. Those can be designed, built, and validated consistently. When a requirement sounds desirable but cannot be objectively verified, it is not ready for approval.

It uses subjective terms that are not measurable or testable, so the requirement is ambiguous and not suitable for consistent development or validation.

Question 80

Topic: Analysis

A BA is reviewing a draft requirements package for a retail support chatbot. The approved business case defines success as increasing self-service issue resolution from 32% to 50% while keeping post-interaction customer satisfaction at 4.2/5 or higher. The customer service director adds that customers should not be kept away from agents unless their issue is actually resolved.

Requirement: The chatbot shall provide automated support for
order-status and return-policy questions.

Acceptance criteria:
- 90% of customers receive a bot response within 5 seconds.
- 60% of chatbot sessions are deflected from live agents.

Before baselining the package, what is the most important improvement?

• A. Define how the 5-second response time will be tested.
• B. Replace deflection with confirmed resolution and satisfaction measures.
• C. Add a reporting period and sample size for session metrics.
• D. Split order-status and return-policy into separate requirements.

Best answer: B

What this tests: Analysis

Explanation: The main flaw is metric misalignment. The business case and stakeholder expectation focus on successful self-service resolution and satisfaction, but the draft acceptance criterion measures deflection from agents, which can improve even when customers remain unresolved or dissatisfied.

Detailed metrics and acceptance criteria should trace directly to the business metrics and stakeholder value expected from the solution. In this case, success is defined as higher self-service resolution with customer satisfaction preserved, and the service director explicitly expects customers to reach agents unless their issue is resolved. A target for chatbot session deflection does not measure that outcome; it could be met by blocking transfers, increasing abandonment, or ending chats without solving the problem.

A stronger acceptance approach would measure outcomes such as:

• confirmed self-service resolution rate
• post-chat satisfaction score
• response time as a supporting quality metric

The response-time criterion is useful, but it is secondary because speed alone does not prove the chatbot is delivering the business value expected.

The detailed metric should evaluate actual issue resolution and customer satisfaction, not merely prevent transfer to an agent.

Question 81

Topic: Traceability and Monitoring

A BA is preparing a traceability artifact for a compliance-related claims release. The team will baseline requirements tomorrow, and the artifact must show each requirement’s status, source, and relationships.

Exhibit:

Which action should the BA take next to correct the artifact?

• A. Remove the BR-01 to FR-07 link because business rules stand alone
• B. Document FR-08’s source and validate its relationship to BR-01
• C. Change BR-01’s source to FR-07 because implementation defines origin
• D. Set TR-03 to Approved because transition work follows development

Best answer: B

What this tests: Traceability and Monitoring

Explanation: A traceability artifact is reliable only when each requirement has a clear source and meaningful links to related requirements. FR-08 has no recorded source, and its behavior appears to challenge the approval rule, so the BA should resolve that gap before baselining.

The key traceability concept is that a requirement must be trackable back to its origin and across its relationships so the team can prove it was delivered as intended. In the exhibit, BR-01 is the governing business rule, and FR-07 appropriately traces to it as an implementing functional requirement. FR-08 is the problem: its source is missing, so its origin cannot be validated, and its stated behavior may contradict the approval rule. Before baselining, the BA should capture who requested FR-08 and confirm whether it is a valid exception, an error, or a conflicting requirement. Changing statuses based on timing or removing valid links weakens traceability instead of strengthening it.

FR-08 is missing its origin and may conflict with the approval rule, so its source and relationship must be clarified before baseline.

Question 82

Topic: Analysis

A requirements package for a new claims system has been baselined and placed under version control. Two weeks later, operations, compliance, and customer service leaders each request changes to the same exception-handling rule. The business analyst must uncover the origin and rationale for the change, identify dependencies across process steps and business rules, and build shared understanding before updating trace links or submitting a formal baseline change. Which elicitation technique is best suited?

• A. Facilitated workshop with impacted stakeholders
• B. Separate one-on-one stakeholder interviews
• C. Review of the baselined requirements documents
• D. Questionnaire sent to affected users

Best answer: A

What this tests: Analysis

Explanation: When a proposed change affects multiple stakeholders and linked requirements, the best elicitation technique is one that exposes dependencies and resolves differences quickly. A facilitated workshop is most effective because it helps build a common view before traceability artifacts and baselines are changed.

The key concept is selecting an elicitation technique that matches both the stakeholder situation and the requirement type. Here, the analyst is dealing with a proposed change to a baselined rule that has cross-functional impacts, so the immediate need is to elicit rationale, reveal dependencies, and align stakeholders before formal change control proceeds. A facilitated workshop fits best because it allows impacted parties to discuss the rule together, clarify conflicting needs, and identify downstream effects on processes and business rules in real time.

• Multiple stakeholder groups are involved.
• The change affects linked requirements and traceability.
• Shared understanding is needed before impact analysis and baseline revision.

Separate interviews can collect input, but they are slower and make reconciliation harder. Document review supports analysis, but it does not elicit missing rationale from people.

A facilitated workshop is best because it surfaces cross-functional rationale, dependencies, and conflicts in one session before controlled baseline updates are made.

Question 83

Topic: Needs Assessment

A business analyst is helping define objectives for a new customer self-service claims portal before solution options are assessed. The sponsor wants objectives that can be traced into requirements and later used to evaluate whether the solution delivered value. Which draft objective is NOT measurable enough for that purpose?

• A. Achieve an 80% first-time completion rate for online claim submission within 3 months of launch.
• B. Improve the customer experience with the new portal.
• C. Reduce claim status inquiry calls by 25% within 6 months of launch.
• D. Cut average online claim submission time from 12 minutes to 7 minutes within 90 days of release.

Best answer: B

What this tests: Needs Assessment

Explanation: Objectives should be specific enough to drive requirements and support post-implementation evaluation. A statement about improving customer experience is directionally useful, but without a defined measure, target, or timing, it is too vague to assess objectively.

In needs assessment, draft objectives should be measurable so they can guide solution analysis, define success criteria, and support later value evaluation. A usable objective typically includes a performance measure, a target, and often a timeframe or baseline. The statements about reducing inquiry calls, achieving a first-time completion rate, and cutting submission time all provide observable outcomes that can be traced into requirements and tested after implementation. By contrast, improving customer experience is a broad aspiration, not a measurable objective, unless it is tied to something like satisfaction score, task completion rate, or complaint reduction.

A good check is whether the team can answer three questions:

• What will be measured?
• What result is expected?
• By when or against what baseline?

If those details are missing, the objective will be weak for both analysis and evaluation.

It lacks a specific metric, target, and timeframe, so it cannot reliably guide analysis or later evaluation.

Question 84

Topic: Needs Assessment

A business analyst is preparing input to a business case for a regional bank. Customers abandon online loan applications at a high rate, but some stakeholders believe the real issue is branch follow-up. The sponsor asks for a concise problem, opportunity, and high-level scope summary that shows whether the gap is significant and what the initiative should cover. Which artifact would provide the best evidence for that summary?

• A. A log of stakeholder interviews and workshop attendance
• B. A prototype of a redesigned loan application interface
• C. A count of enhancement ideas submitted by branch managers
• D. A quantified current-state and future-state gap analysis with affected process boundaries

Best answer: D

What this tests: Needs Assessment

Explanation: For business case input, the strongest support is evidence that quantifies the business problem or opportunity and defines the scope at a high level. A current-state versus future-state gap analysis does both by showing the size of the issue and the boundaries of the affected process.

In needs assessment, the goal is not to prove that analysis activities occurred; it is to show that a meaningful business problem or opportunity exists and to frame the solution scope clearly enough for business case input. A quantified gap analysis compares current performance with the desired future state, identifies the business impact, and clarifies which processes or capabilities are in scope. That makes it the best basis for a concise problem, opportunity, and scope summary.

Evidence such as interview logs or idea counts may show engagement, but they do not validate the significance of the gap. A prototype is premature because it suggests a solution direction before the business need and scope have been sufficiently established. The best evidence at this stage is the artifact that ties impact, opportunity, and boundaries together.

This best supports a business case summary because it shows the problem magnitude, desired opportunity, and high-level scope limits in one evidence-based view.

Question 85

Topic: Planning

A retailer approved a project for a mobile returns app. The business case expects a 15% reduction in store counter wait times within 3 months of launch. The budget allows only one release before the holiday season, legal requires auditability of refund decisions, and store managers say associates handle return exceptions differently today. As the BA planning the work, which action is BEST?

• A. Center planning on interface prototypes
• B. Plan transition and acceptance work for exceptions and auditability
• C. Gather enhancement ideas for a later release
• D. Delay procedure analysis until after pilot feedback

Best answer: B

What this tests: Planning

Explanation: The best action is to plan BA work that directly supports the business case constraints, not just the desired feature set. Because value must be realized quickly in a single release while meeting legal and operational needs, the BA should address exception handling, readiness, and acceptance criteria up front.

When reviewing the business case, the BA should identify what must be true for the solution to deliver value within the stated constraints. Here, success is not only a mobile app launch; it is reduced wait time within 3 months, in a single funded release, while satisfying auditability and handling inconsistent store procedures. That makes transition requirements, operational process alignment, and acceptance criteria necessary planning activities.

A good planning decision is to connect BA work to the business case by asking:

• What outcomes define success?
• What governance or compliance conditions are mandatory?
• What operational differences could block adoption or value?
• What must be included in the first release?

Focusing only on features would miss key conditions for realizing the expected benefit. The closest distractor is the prototype-focused approach, but usability alone does not address compliance or inconsistent exception handling.

The business case depends on first-release operational consistency and legal compliance, so BA planning must include transition requirements and acceptance criteria for exception handling and auditability.

Question 86

Topic: Analysis

A business analyst is reviewing a draft requirements package for a new call center knowledge search tool.

Business need: Reduce average call handling time without lowering first-call resolution.
Requirement: Agents shall find approved policy answers faster using the new search tool.
Draft acceptance criterion: 95% of agents complete training before launch, and
supervisors see an upward trend in search usage during the 2-week pilot.

Before baselining, what is the most important improvement to this acceptance criterion?

• A. Assign an owner to monitor and report the metric
• B. Capture the source and rationale for the criterion
• C. Define measurable pass/fail thresholds for the required business outcome
• D. Add the pilot sample size and duration details

Best answer: C

What this tests: Analysis

Explanation: The draft criterion focuses on training completion and usage trend, which are leading indicators, not the pass/fail test for whether agents actually find answers faster. The key fix is to add measurable outcome thresholds tied directly to the requirement, such as search time or call handling performance.

Acceptance criteria should tell reviewers exactly how to determine whether a requirement has been met. In this scenario, the requirement is about agents finding approved policy answers faster, but the draft criterion measures adoption signals: training completion and increasing usage. Those measures can be useful leading indicators because they suggest readiness or likely uptake, but they do not establish a clear pass/fail condition for the requirement itself.

A stronger criterion would specify:

• the outcome metric to test
• the threshold to pass
• the condition or context of measurement

For example, it might state that agents locate approved policy answers within a defined time or that average handling time improves by a stated amount without reducing first-call resolution. Details like ownership, rationale, and pilot size may help governance, but they are secondary to fixing the missing pass/fail threshold.

The draft uses leading indicators of adoption, but acceptance criteria must state the threshold that determines whether the solution actually meets the requirement.

Question 87

Topic: Traceability and Monitoring

A retail bank is releasing online branch appointment booking. After UAT, stakeholders demand rework because the feature was reported as complete in sprint demos, but customers still cannot actually book a time slot. The BA reviews the traceability artifact:

What is the most likely underlying BA gap?

• A. BR-4 was marked complete without tracing BR-9 through build and test.
• B. UAT stakeholders changed scope after seeing the sprint demo.
• C. The team needed another approval cycle before development.
• D. Developers lacked enough UI detail for appointment scheduling.

Best answer: A

What this tests: Traceability and Monitoring

Explanation: The traceability artifact shows a dependency gap, not a late stakeholder change. The top-level business requirement was marked Done even though its dependent requirement has no linked build or test coverage, so delivery could not be verified as stated.

This tests whether the traceability artifact provides evidence that a requirement is truly delivered. A business requirement should not be considered complete just because one linked story was built and one test passed. Here, BR-4 depends on BR-9, but BR-9 has no downstream trace to solution work or testing.

That means the team verified only part of the need:

• a page exists to capture preferences
• the page-level test passed
• the actual time-slot capability was never traced to build or test artifacts

The underlying BA gap is incomplete end-to-end traceability and incorrect status roll-up. To verify delivery as stated, the BA should confirm dependent requirements are traced through build, test, and status before marking the parent requirement complete. A sign-off or demo alone does not replace that evidence.

BR-4 cannot be verified as delivered as stated because its dependency, BR-9, has no linked solution or test evidence even though BR-4 is marked Done.

Question 88

Topic: Needs Assessment

A business analyst is assessing a proposed claims intake solution. Interviews show that operations values fewer handoff errors, compliance values auditability, and finance values faster processing only if staffing does not increase. Detailed requirements will be prioritized later across multiple releases, and the sponsor wants those decisions to be traceable back to the original stakeholder value discussions. How should the business analyst document this information?

• A. Update the stakeholder register with each stakeholder’s level of influence.
• B. Store the interview notes in the repository and reference them during prioritization.
• C. Baseline an initial ranking of requirements before detailed analysis begins.
• D. Create a version-controlled traceability artifact linking values, sources, rationale, measures, and later requirements.

Best answer: D

What this tests: Needs Assessment

Explanation: Stakeholder value information should be captured in a structured, version-controlled traceability artifact, not left in informal notes. Linking each value to its source, rationale, and success measure creates a reliable basis for later requirement prioritization and change impact review.

The key concept is documenting stakeholder value so it remains usable later when requirements are compared, prioritized, changed, or deferred. In this scenario, the analyst needs more than a record of who said what; the information must support downstream decisions. A traceability artifact is best because it can capture each stakeholder value statement along with its origin, rationale, related business objective, and measurable success criteria, then connect those entries to requirements as they are defined.

This approach supports:

• later prioritization based on explicit value drivers
• controlled updates through versioning
• impact analysis when values or requirements change
• clear justification for tradeoff decisions

Meeting notes are too informal, baselining requirements is premature, and influence alone does not document value. The useful baseline here is the documented stakeholder value information, not an early requirement ranking.

This preserves stakeholder value information in a controlled, traceable form that can directly support later prioritization and impact analysis.

Question 89

Topic: Needs Assessment

A retail bank sponsor claims the business problem is that small-business customers abandon account opening because approval takes too long, and wants a business case for a new digital onboarding solution. The BA has 2 weeks and access to internal process data and recent applicants. Which evidence should the BA prioritize first to confirm the stated problem or opportunity?

• A. Cycle-time, abandonment, and early attrition trends by channel, plus interviews with recent applicants who dropped out
• B. A workshop with branch managers to rank what they believe causes customer loss
• C. An enterprise survey asking employees which onboarding improvements they want most
• D. A benchmark of competitors’ onboarding features and advertised turnaround times

Best answer: A

What this tests: Needs Assessment

Explanation: The strongest evidence directly validates the claimed problem, its scale, and its effect on the affected stakeholders. Combining internal performance data with feedback from recent applicants gives both quantitative and qualitative confirmation before investing in a solution.

In needs assessment, the best evidence for confirming a business problem is evidence that is closest to the stated cause-and-effect claim. Here, the claim is that long approval times are leading small-business customers to abandon account opening. Internal trend data can show whether cycle time, abandonment, and early attrition are actually correlated by channel or segment, while interviews with recent dropouts can confirm whether delay was a meaningful reason from the customer perspective.

This approach is strongest because it:

• tests the stated problem directly
• uses affected stakeholder evidence
• supports business case input with measurable impact
• avoids jumping prematurely to a preferred solution

Competitor data and stakeholder opinions may be useful later, but they do not confirm the bank’s own business problem as well as direct operational and customer evidence.

This directly tests whether long approval times are causing abandonment and links the problem to measurable customer impact.

Question 90

Topic: Needs Assessment

A BA is preparing a requirements prioritization workshop for a new order-entry solution. Review the stakeholder value summary and determine the best next action.

Stakeholder value summary
- Sales VP (High): Quote turnaround <= 15 minutes
- Operations Manager (High): Order rework < 3%
- Compliance Lead (High): 100% audit trail for price overrides
- CFO (High): Manual order handling reduced by 20%
Notes:
- Each stakeholder called their outcome "must have"
- No relative weighting among outcomes is documented
- No conflict-resolution decision maker is identified

• A. Prioritize by stakeholder influence because all outcomes are measurable
• B. Prioritize compliance-related requirements first for all releases
• C. Begin prioritization now and refine conflicts during change control
• D. Elicit trade-off criteria and decision authority before prioritizing

Best answer: D

What this tests: Needs Assessment

Explanation: There is not yet enough stakeholder value data to support defensible prioritization. The exhibit captures desired outcomes and measures, but it does not show relative value among competing objectives or who can resolve conflicts.

To begin prioritizing requirements, the BA needs a usable baseline of stakeholder value, not just a list of desired outcomes. In this exhibit, all key stakeholders are high influence, each has declared a different outcome as a must-have, and no weighting or conflict-resolution authority is defined. That means the BA cannot reliably compare requirements when trade-offs appear.

A sound next step is to elicit:

• relative importance or weighting of value drivers
• decision rules for resolving conflicts
• the authorized decision maker if consensus is not reached

Once those data exist, prioritization can be justified and traced back to stakeholder value rather than opinion.

The exhibit shows stakeholder outcomes, but not the relative value or authority needed to resolve competing must-have claims.

Question 91

Topic: Traceability and Monitoring

A requirement to “display customer credit-hold status during order entry” was approved, baselined, and prioritized for the current release. Development is complete, linked system test cases have passed, and no stakeholder has requested any change to the wording, acceptance criteria, or release priority. The traceability tool still shows the requirement status as Approved. What should the business analyst do next?

• A. Submit a formal change request to revise the baselined requirement before updating anything.
• B. Leave the status as Approved until deployment sign-off is obtained.
• C. Ask the product owner to re-prioritize the requirement now that testing is complete.
• D. Update the requirement to its next lifecycle status and notify relevant stakeholders.

Best answer: D

What this tests: Traceability and Monitoring

Explanation: This situation describes lifecycle progress, not a change to requirement content or business priority. The business analyst should update the requirement’s status in the traceability tool according to the defined lifecycle and communicate that progress to the appropriate stakeholders.

The key concept is separating a status change from a content change or reprioritization. Here, the requirement text, acceptance criteria, and release priority are unchanged. What changed is its progress through the lifecycle: development and linked system testing are complete. That means the business analyst should update the requirement’s status attribute in the traceability artifact or tool and communicate the update so progress can be tracked accurately toward closure.

A formal change request is typically needed when the requirement itself changes, such as its wording, scope, rationale, or acceptance criteria. Reprioritization is appropriate when business value, urgency, or release sequencing changes. Neither condition exists here. The closest mistake is leaving the status unchanged, which weakens traceability and gives stakeholders an inaccurate view of progress.

The requirement has progressed through its lifecycle without any content or priority change, so the next step is to record the status change in the traceability artifact and communicate it.

Question 92

Topic: Analysis

A business analyst is validating a draft requirements package for a new loan-origination portal using a prototype walkthrough. Underwriters say an override reason code is missing, compliance says the prototype displays customer data incorrectly, and operations notes there is no requirement for handling returned applications. What is the best next step?

• A. Get provisional sign-off and defer new items to change control.
• B. Record the comments and baseline the current requirements package.
• C. Start development and address remaining issues during user acceptance testing.
• D. Analyze the feedback, resolve conflicts, and update requirements before approval.

Best answer: D

What this tests: Analysis

Explanation: When validation exposes gaps, conflicts, or inaccuracies, the BA should not move forward with approval or build work. The right next step is to analyze the feedback, reconcile stakeholder differences, and revise the requirements package so it is complete and accurate before baselining.

Requirements validation is meant to confirm that requirements are complete, accurate, and aligned to the business need. In this scenario, the prototype walkthrough revealed three classic validation findings: a missing requirement, an incorrect requirement, and an unaddressed operational need. That means the requirements package is not ready for approval yet.

The BA should:

• document the feedback and its rationale
• assess impacts to the requirements and acceptance criteria
• resolve stakeholder conflicts and clarify the correct need
• update the requirements package, then continue validation as needed

Moving to sign-off, baselining, or development before resolving these issues would lock in defects and increase rework. The closest distractor is deferring the issues to change control, but change control is more appropriate after a baseline exists, not when current validation shows the draft is still incomplete or wrong.

Validation feedback showing missing, conflicting, and incorrect requirements should be analyzed and incorporated before the requirements are approved or baselined.

Question 93

Topic: Analysis

A business analyst is asked to document a new “expedite order” requirement for a distributor. Sales, warehouse, and billing each perform part of the work, but the product owner only says, “Use whatever format helps development start next sprint.” Before deciding whether to write a user story, use case, or process model, what should the analyst verify first?

• A. Whether future-state cycle-time metrics have been finalized by operations
• B. Whether interface mockups should be included with the requirement
• C. Whether sprint planning requires the requirement package to be approved this week
• D. Whether the requirement is a single user goal or a cross-functional workflow with triggers, handoffs, and exceptions

Best answer: D

What this tests: Analysis

Explanation: The first clarification is the nature of the process being specified. A BA should confirm whether the need is a simple user-level capability or an end-to-end workflow involving multiple actors and exception paths, because that drives the most suitable requirement format.

When writing a process requirement, the BA should first clarify the process scope and structure. A user story works well for a small slice of value centered on one user goal, while a use case is better when interactions, alternate flows, and business rules must be described. A process model is often best for cross-functional workflows with multiple roles, handoffs, and decision points.

In this scenario, the requirement spans sales, warehouse, and billing, but the exact level of detail is still unclear. Before choosing a format, the BA needs to understand:

• the trigger and outcome
• the actors involved
• whether there are handoffs across functions
• whether exceptions or alternate paths matter

Schedule pressure, mockups, and metrics may matter later, but they do not determine the most appropriate process-specification format.

The required format depends first on the process scope and interaction detail needed, which determines whether a story, use case, or process model is most actionable.

Question 94

Topic: Traceability and Monitoring

A business analyst is reviewing the traceability matrix for a hybrid project. Three high-priority requirements are marked validated and proposed for the next build cycle. The requirements management plan states that before a requirement can move to ready for build, it must have linked and approved supporting artifacts: an updated process model, business rule entries, and system test cases. For two requirements, the process model is outdated and test cases are missing. The delivery lead wants to move them forward to protect the schedule. What should the business analyst do next?

• A. Advance the requirements and finish artifacts during testing.
• B. Request sponsor approval to waive the missing artifacts.
• C. Hold progression, update status, and complete missing artifact reviews.
• D. Send reminders and recheck after sprint planning.

Best answer: C

What this tests: Traceability and Monitoring

Explanation: The best next step is to stop the requirements from progressing past their actual readiness and use the traceability artifact to trigger completion of the missing supporting artifacts. Monitoring is not just reporting status; it also ensures required models, documentation, and test cases are produced, reviewed, and approved at the right lifecycle point.

This situation is a lifecycle status mismatch: the requirements have progressed farther than their required supporting artifacts. In PMI-PBA traceability and monitoring, the BA should keep requirement status aligned with artifact readiness and take action when linked deliverables lag. Here, the requirements management plan explicitly defines the gate for ready for build, so the BA should update the traceability status to reflect the gap and coordinate completion, review, and approval of the missing process model and test cases.

That is stronger than simply notifying people, because monitoring includes ensuring the needed artifacts exist and are approved at the correct point in the lifecycle. It also avoids pushing incomplete requirements into build, where missing analysis and test coverage can cause rework and defects. The key takeaway is that when artifacts lag, the next step is controlled status correction and follow-through, not escalation for premature approval or passive reminders.

The BA should use traceability to show the requirements are not ready and drive completion, review, and approval of the lagging artifacts before build progression.

Question 95

Topic: Analysis

A business analyst is refining a user story for a retail returns system before development starts next week. The draft says, “As a service agent, I can approve a refund so customers are satisfied.” In review, finance states refunds above $500 need manager approval, and compliance states refunds after 90 days are prohibited unless the item is under recall. The product owner wants the smallest update that makes the requirement actionable now. Which refinement is BEST?

• A. Split the story into normal and manager-approval paths, and capture exceptions after UAT.
• B. Reference the finance and compliance policies without repeating the rule thresholds.
• C. Add interface mockups and keep the approval rules in operating procedures.
• D. Rewrite the requirement and acceptance criteria to state the 90-day limit, recall exception, and $500 manager-approval rule.

Best answer: D

What this tests: Analysis

Explanation: The best refinement is the one that turns a vague story into an actionable specification with explicit conditions and business rules. Stating the time limit, exception, and approval threshold directly in the requirement gives development and testing clear, measurable behavior without expanding scope unnecessarily.

When refining a specification, the priority is to make it suitable for build and validation by capturing the logic that governs behavior. Here, the missing information is not screen design or document linkage; it is the operational rule set: the 90-day condition, the recall exception, and the $500 approval threshold. Putting those rules into the requirement and acceptance criteria creates a shared, testable understanding of what the solution must do.

This is the best tradeoff because it:

• clarifies decision logic before development starts
• preserves compliance and financial control rules
• keeps the update small instead of redesigning the whole process

Splitting work can help later, but deferring exception logic leaves a known rule gap in the specification.

This makes the requirement measurable and actionable by embedding the key conditions, constraint, and business rules directly in the specification.

Question 96

Topic: Traceability and Monitoring

A business analyst is reviewing requirements in the traceability tool before the next status meeting. Which requirement most clearly appears stalled and should be escalated for clarification now?

• A. An interface requirement is waiting for a vendor workshop that is already scheduled for the next business day.
• B. A customer-data retention rule has conflicting approval comments from Legal and Sales, and no decision owner has resolved it for two weeks.
• C. A reporting field label needs final wording, and the operations SME committed to provide it tomorrow.
• D. A low-value dashboard request was intentionally moved to a later release and recorded as deferred.

Best answer: B

What this tests: Traceability and Monitoring

Explanation: A requirement is stalled when it cannot advance because of unresolved conflict, ambiguity, or missing decision authority. Conflicting approval input from Legal and Sales, combined with no owner and a two-week delay, shows the requirement needs escalation and a status update in the traceability record.

The key concept is recognizing when a requirement is no longer simply pending work and is instead blocked from progressing through its lifecycle. In this case, the retention rule has conflicting stakeholder comments, no identified decision maker, and has remained unresolved for two weeks. That combination signals a stalled requirement: the business analyst should communicate the issue to the appropriate authority, seek clarification or resolution, and update the traceability artifact with the current status and escalation history.

A requirement is usually stalled when:

• approvals conflict or are ambiguous
• ownership for the decision is unclear
• the requirement cannot move to the next state
• normal follow-up has not resolved the blockage

By contrast, a requirement with a scheduled next step or an intentional deferral is still controlled, not stalled.

Conflicting stakeholder direction with no clear decision owner means the requirement cannot move forward and requires escalation for clarification.

Question 97

Topic: Traceability and Monitoring

A business analyst reviews the weekly traceability report for a regulated claims-processing enhancement. The release baseline was approved 3 weeks ago, and any requirement change after baseline must follow formal change control. Which observation is the strongest evidence that requirements governance is functioning effectively?

• A. The baseline is still approved, so the team stopped updating requirement statuses until user acceptance testing begins.
• B. One new low-impact requirement was added to the backlog first, with trace links and approvals to be updated next sprint.
• C. All baselined requirements show current status, links to models and test cases, and an approved change record for the one revised requirement.
• D. Test cases exist for nearly all requirements, but several revised business rules still point to superseded model versions.

Best answer: C

What this tests: Traceability and Monitoring

Explanation: Effective requirements governance is shown by complete, current traceability plus disciplined baseline control. The strongest evidence is a report showing lifecycle status, downstream links to supporting artifacts, and formal approval for the only post-baseline change.

To judge whether requirements governance is functioning, look for evidence that each requirement is being monitored through its lifecycle and that any post-baseline change is controlled. Current status values show the team is actively tracking progress. Trace links to supporting artifacts such as models and test cases show dependency coverage and help confirm the right artifacts were produced, reviewed, and kept aligned. An approved change record for a revised requirement shows impact analysis, versioning, and baseline control are working as intended.

By contrast, adding work before approval breaks change discipline, leaving links to superseded artifacts creates unreliable traceability, and stopping status updates removes visibility into lifecycle progress. Strong governance is not just having a baseline; it is maintaining accurate trace links and controlled changes after that baseline is set.

This shows active lifecycle monitoring, complete downstream traceability, and controlled handling of a post-baseline change.

Question 98

Topic: Traceability and Monitoring

A business analyst is maintaining the traceability tool for requirements in an order management upgrade. Several stakeholders request updates after a release planning meeting and test cycle. Which request should be handled as a status change only, rather than as a content change or reprioritization?

• A. Move a reporting requirement from a later release into the next sprint.
• B. Mark a tested requirement as implemented after deployment with no wording changes.
• C. Expand a tax requirement to include county-level rules requested by compliance.
• D. Split one usability requirement into separate mobile and desktop requirements.

Best answer: B

What this tests: Traceability and Monitoring

Explanation: A status change reflects where a requirement is in its lifecycle, such as approved, tested, or implemented. When the requirement text, scope, or priority changes, the BA is no longer just updating status and must treat it as a content change or reprioritization.

The core concept is distinguishing lifecycle progression from changes to what the requirement means or how important it is. A pure status change occurs when the same requirement moves from one state to another, such as from validated to implemented, and the BA records that movement in the traceability artifact and communicates it to the right stakeholders.

In this scenario:

• Deployment after successful testing changes lifecycle state.
• Adding county-level tax logic changes requirement content.
• Moving a requirement into an earlier sprint changes priority.
• Splitting one requirement into two changes the requirement definition and trace links.

The closest distractor is the release move, because it may feel administrative, but it is still reprioritization, not status tracking.

This updates the requirement’s lifecycle state only, because the requirement content and priority remain unchanged.

Question 99

Topic: Planning

A regulated insurer is planning business analysis for a new claims platform. Draft requirements will be updated by several analysts and SMEs, but once approved, each requirement set must have a clearly accountable owner, limited edit access, full version history, and a 7-year retention period for audit review. Which document control approach is the best fit?

• A. Use a collaboration wiki where all stakeholders can revise approved requirements and old pages are overwritten.
• B. Use a shared team folder with open edit access and archive only the final release.
• C. Use a controlled repository with named artifact owners, role-based edit rights, read access for reviewers, and retention rules on approved baselines.
• D. Use email distribution lists with the project manager storing signed attachments for reference.

Best answer: C

What this tests: Planning

Explanation: The scenario requires formal document control, not just convenient sharing. A controlled repository with named owners, role-based permissions, preserved versions, and retention settings best supports approval rigor, traceability, and auditability.

The core concept is matching document control to the required level of governance. Here, several people may contribute to drafts, but approved requirements must be protected, attributable, and retained for audit review. That means the document control method must define who owns each artifact, who may edit versus only view it, how versions and baselines are preserved, and how long records are kept.

A controlled repository best fits because it supports:

• named ownership for each approved artifact
• role-based access for editing and review
• version history and baseline preservation
• retention rules tied to audit needs

Approaches built for informal collaboration or simple file sharing may help drafting, but they do not reliably enforce ownership, controlled changes, or required record retention after approval.

This approach directly supports ownership, controlled access, versioning, and required retention for auditable approved requirements.

Question 100

Topic: Analysis

During backlog refinement for a two-week sprint, a BA reviews a story the team plans to start tomorrow. The product owner says UX standards and technical architecture are already defined elsewhere; the team needs only enough detail to build and test this story now.

Draft requirement package note:

User story: As a policyholder, I want to change my mailing address
so I receive documents at the correct location.

Acceptance criteria:
- Show Street, City, State, ZIP in two columns.
- Place a blue Save button in the lower right.
- Call service ADR_CHG_02 and update table CUSTOMER_ADDR.
- Display "Address updated" after save.

What is the most important improvement?

• A. Add the story’s relative priority and dependency notes.
• B. Add a unique identifier and version for the story.
• C. Add the originating stakeholder and rationale to the backlog item.
• D. Replace UI/API specifics with business rules, validation, and effective timing.

Best answer: D

What this tests: Analysis

Explanation: The package is not at the right level of detail for this agile delivery context. It dictates UI placement and technical implementation while missing measurable business behavior, such as validation rules and when the address change should take effect, which are what developers and testers need now.

In an agile story ready for near-term delivery, the BA should provide just enough detail to make the work actionable and testable without locking the team into unnecessary design choices. Here, the draft tells the team where the button goes and which service and table to use, but those are solution design details already handled elsewhere. What is missing is the business behavior that defines done, such as what makes an address valid, whether all fields are required, how invalid ZIP codes are handled, and when the new mailing address becomes effective for outgoing documents.

That level of detail supports development and testing now, while avoiding over-specification. Administrative details like source, version, priority, and dependencies can help governance, but they do not fix the main readiness problem in this package.

The draft over-specifies design and implementation but still lacks the testable business behavior needed for the team to build and verify the story.

Questions 101-125

Question 101

Topic: Analysis

A business analyst is facilitating scope decisions for a bank’s first mobile account-opening release. Marketing wants personalized offers, Compliance wants an identity-verification audit trail, and Operations wants a manual-review queue. The team already agreed to weighted decision criteria: regulatory risk reduction, customer adoption, operational impact, and delivery effort. The release has fixed capacity and must meet a 10-week regulatory deadline. What is the BEST BA action?

• A. Escalate the competing requests to the sponsor for a final decision.
• B. Include one capability from each stakeholder group to maintain support.
• C. Score each capability against the agreed criteria and recommend a release fit.
• D. Choose the capability with the highest projected revenue impact.

Best answer: C

What this tests: Analysis

Explanation: The best action is to apply the already agreed weighted decision criteria to all proposed capabilities and compare them transparently. That lets the BA make a consistent recommendation that respects both the regulatory deadline and the fixed release capacity.

This tests consistent use of decision criteria when stakeholders favor different capabilities. Once stakeholders have agreed to weighted criteria, the BA should facilitate an objective comparison of each capability against those same factors, document the rationale, and recommend which requirements are accepted, deferred, or rejected based on fit with capacity and deadline. In this case, no single stakeholder preference should dominate because the decision must balance compliance, adoption, operational impact, and delivery effort.

A criteria-based evaluation helps the BA:

• apply the same standards to every option
• make tradeoffs visible and defensible
• align the recommendation to governance constraints
• reduce politically driven prioritization

Escalation may still be needed later, but only after the BA has used the agreed framework to produce an evidence-based recommendation.

Using the preagreed weighted criteria keeps evaluation consistent across stakeholder preferences and supports a defensible accept, defer, or reject recommendation within the release constraints.

Question 102

Topic: Needs Assessment

A company is assessing a new online onboarding solution for commercial lending. The goals are to reduce application turnaround time by 40% and increase completed applications. Draft requirements include electronic signatures, collection of financial documents, automated credit decisions, and issuance of legally required adverse-action notices. Current stakeholders are the lending product manager, branch operations manager, solution architect, and marketing lead.

Which additional stakeholder should the business analyst prioritize for representation first?

• A. Contact center supervisor
• B. Lending compliance officer
• C. Learning and development manager
• D. Strategic sourcing manager

Best answer: B

What this tests: Needs Assessment

Explanation: The best choice is the lending compliance officer because the stated goals and draft requirements include regulated lending activities, not just customer experience or operational efficiency. That stakeholder is needed early to ensure mandatory obligations are represented before needs and solution options are shaped.

In needs assessment, stakeholders are identified from the business goals, objectives, and requirements that must be represented. Here, the requirements include automated credit decisions, e-signatures, document collection, and adverse-action notices, which create direct regulatory and policy obligations. A lending compliance officer represents those mandatory business and legal needs and can clarify constraints, acceptance conditions, and risk exposure before the initiative advances.

Prioritizing this stakeholder is strongest because:

• The requirements already point to regulated decisioning.
• Missing this perspective could invalidate solution options later.
• Compliance needs are mandatory, while several other concerns are important but secondary.

The closer distractor is the contact center perspective, which helps usability and support readiness but does not represent the most critical requirement-driven obligation in the scenario.

This role must represent regulatory and policy obligations embedded in the draft requirements, especially credit decisions, e-signatures, and adverse-action notices.

Question 103

Topic: Evaluation

A BA is evaluating a new order-entry solution before rollout. In system testing, 27 of 150 orders that should qualify for straight-through processing were routed to manual review, threatening a promised 20% cycle-time reduction. Operations wants to keep the fixed quarter-end release date, and governance requires any post-baseline requirement change to go through change control. The BA also has peer review notes showing repeated questions about one eligibility business rule. What should the BA do FIRST to determine the root of the discrepancy?

• A. Log all failed cases as defects for immediate developer correction.
• B. Submit a change request to clarify the eligibility rule.
• C. Trace failed tests to the baselined rule and review findings with stakeholders.
• D. Recommend delaying rollout until operations adds review capacity.

Best answer: C

What this tests: Evaluation

Explanation: The BA should diagnose the discrepancy by linking the failed tests to the baselined business rule and prior review findings, then validating the cause with the right stakeholders. This uses QA evidence to distinguish a true defect from an unclear requirement or missing logic before triggering change control or release decisions.

When QA findings or test results reveal a mismatch between expected and actual behavior, the BA should first determine the source of the gap rather than immediately treating it as a build defect or a scope change. In this case, the discrepancy affects an important business value target, the release date is constrained, and governance applies if the requirement itself must change. The strongest first action is to connect the failed test cases to the specific baselined requirement or business rule, inspect the related peer review comments, and review that evidence with QA, SMEs, and delivery stakeholders.

• Confirm the expected outcome from the baselined rule and acceptance criteria.
• Compare actual test results and review findings against trace links.
• Classify the issue as implementation defect, requirement ambiguity, missing logic, or test-data problem.

That evidence-based analysis identifies the root cause before escalation, rebaselining, or remediation.

It uses test evidence, traceability, and review feedback to isolate whether the issue is a defect, a requirement gap, or a test-data problem before action is taken.

Question 104

Topic: Analysis

A business analyst is analyzing a requirement for an online retailer to let customer service agents change shipping methods after an order is submitted. Stakeholders agree on the goal, but workshops surfaced unresolved questions about payment adjustments, warehouse cut-off times, fraud checks, and updates to a carrier portal. The product owner asks for the best next step to make the needed options and capabilities clearer. What should the BA do next?

• A. Ask developers to estimate the feature and refine details during testing
• B. Conduct collaborative modeling to decompose requirements and identify dependencies
• C. Baseline the current requirements package for stakeholder approval
• D. Log the open questions and revisit them after development begins

Best answer: B

What this tests: Analysis

Explanation: The requirement is not yet actionable because key scenarios, rules, and interfaces remain unclear. The BA should continue collaborative analysis to decompose the need and expose dependencies so stakeholders can understand what capabilities are actually required.

This situation calls for requirements elaboration, not approval or deferral. The business goal is understood, but the requirement still hides important details across process flow, business rules, and external interfaces. A collaborative analysis session using techniques such as process modeling, interface analysis, and rule clarification will help the team break the requirement into specific scenarios and reveal what capabilities each option must support.

• Clarify normal and exception flows for shipping changes
• Identify business rules such as cut-off times and fraud checks
• Define interface impacts like carrier portal updates and payment adjustments

Once those details are understood, the BA can support option evaluation, estimation, and later baseline decisions with much less ambiguity. The closest distractor is baselining, but that should follow refinement, not replace it.

Collaborative decomposition with process, rule, and interface analysis is the next step because the requirement is still too broad to reveal complete capabilities and options.

Question 105

Topic: Analysis

A business analyst is refining requirements for a new order-fulfillment solution. In collaborative workshops, warehouse leaders identified split-shipment exceptions, finance added tax and refund rules, and customer service requested self-service status updates. The sponsor wants evidence that the requirements are now clear enough to compare solution options and baseline release scope. Which artifact would best provide that evidence?

• A. The total number of requirements documented so far
• B. Validated process and decision models showing rules, exceptions, and interfaces
• C. Prototype screenshots from the latest elicitation session
• D. Workshop attendance records from all stakeholder groups

Best answer: B

What this tests: Analysis

Explanation: The best evidence of refined requirements is an artifact that makes behavior, rules, interfaces, and exceptions explicit and reviewable. Validated process and decision models show whether stakeholders now share a clear understanding of the capabilities and option differences.

This tests whether requirements have been refined enough to support analysis, comparison, and baseline decisions. In PMI-PBA terms, collaborative elaboration should produce actionable, reviewable artifacts that uncover how the solution must work across process steps, business rules, exception paths, and interfaces. A validated set of process and decision models does exactly that: it exposes dependencies, clarifies capabilities, and gives stakeholders concrete evidence that the options are understood consistently.

When the goal is to confirm requirement quality and readiness, the strongest evidence is the artifact that reduces ambiguity and supports decision making. Counts, attendance, or screenshots may show activity or interest, but they do not prove that the requirements are complete, coherent, and clear enough to compare options and establish scope.

These validated models make option behavior and required capabilities explicit, which best demonstrates that the requirements are sufficiently elaborated for comparison and baselining.

Question 106

Topic: Analysis

A BA is defining the first release for a claims-processing solution with a fixed go-live date. To protect the schedule, the team allocates mostly low-complexity reports and screen enhancements, while deferring automated exception routing that the business case identified as the main source of cycle-time reduction. During validation, operations leaders say the release will not reduce manual rework, approvals are reopened, and lower-value items must be swapped out. What is the most likely underlying BA gap?

• A. Allocation favored build speed over value and dependencies
• B. Stakeholders resisted signing off the baseline
• C. Test cases missed key operational scenarios
• D. Developers caused rework during validation

Best answer: A

What this tests: Analysis

Explanation: The problem is not simply approval delay or test quality. The release allocation ignored the value proposition by deferring the requirement that delivered the primary business benefit, so the baseline met the date but not the business need.

In PMI-PBA terms, accepted and deferred requirements should be allocated by balancing schedule constraints with the value proposition, dependencies, and expected business outcomes. Here, the key clue is that the deferred capability was the main driver of cycle-time reduction in the business case. Choosing easier, faster items for Release 1 protected the date, but it undermined the intended value, so unmet needs, reopened approvals, and rework followed.

A sound allocation would have used prioritization and dependency analysis to keep the value-driving capability in scope or explicitly show that the release could not satisfy the business objective without it. Approval churn is a downstream symptom; the underlying gap is value-based allocation failure.

The release was baselined around schedule convenience instead of the value-driving requirement and its dependencies.

Question 107

Topic: Evaluation

A claims-processing solution has passed user acceptance testing except for one requirement: the audit report takes 9 minutes instead of the approved acceptance criterion of 5 minutes. The compliance manager agrees to deploy only if this exception is documented and corrected in the next release; the sponsor still wants deployment this week. The requirements baseline is already approved. What should the business analyst do to document this decision correctly?

• A. Mark the solution approved because most stakeholders support deployment and capture the concern in meeting notes.
• B. Update the requirement baseline to 9 minutes so the sign-off package matches the test outcome.
• C. Delay documentation until after deployment and ask the development team to fix the issue under normal defect tracking.
• D. Record a conditional approval with the exception, trace it to the failed requirement and test result, document impact and follow-up control, and keep the current baseline unchanged.

Best answer: D

What this tests: Evaluation

Explanation: When approval is conditional, the BA should document the decision, the exact exception, and its trace links to the affected requirement and validation evidence. The approved baseline should not be rewritten to fit an unmet result; the exception must remain visible and controlled.

The core concept is accurate sign-off documentation under baseline control. Here, one acceptance criterion was not met, but a stakeholder is granting deployment approval only with a stated exception and future correction. The BA should record that as a conditional approval, link the exception to the specific requirement and failed test result, note any deployment or operational impact, and route the follow-up through the organization’s controlled change or exception process.

This keeps lifecycle status and traceability intact:

• The requirement remains unmet against its current baseline.
• The sign-off reflects a condition, not full acceptance.
• The exception is visible for monitoring and closure.
• The baseline is changed only through formal control, not by editing history.

The closest distractor is revising the baseline to match actual performance, which breaks traceability by hiding that the original acceptance criterion was not achieved.

This preserves sign-off accuracy and traceability by documenting the condition and exception without silently changing an approved baseline.

Question 108

Topic: Planning

A BA is midway through planning analysis work for an e-commerce project when the sponsor changes the primary objective from increasing online conversion to meeting new customer privacy obligations before an audit in 3 months. The BA team size and budget will not increase, and several elicitation sessions for marketing features are already scheduled. Which action should the BA take first to best adjust priorities and contingency planning?

• A. Keep the current analysis schedule to avoid disruption and capture privacy needs after the planned feature workshops
• B. Reprioritize BA work toward privacy-critical requirements, add the newly impacted stakeholders, and revise the BA plan to defer lower-value marketing analysis
• C. Continue with the highest-revenue features first and rely on testing to catch any privacy gaps later
• D. Pause all analysis until the sponsor rewrites the full business case and the project charter is formally reissued

Best answer: B

What this tests: Planning

Explanation: When project objectives change after planning starts, the BA should immediately realign analysis priorities to the new business outcome. Here, the dominant driver is audit readiness under fixed capacity, so compliance-related requirements and stakeholders must take priority over previously planned growth features.

The core concept is to re-anchor business analysis work to the updated business objective, then adjust the plan to reflect value, risk, and stakeholder impact. In this scenario, the project no longer optimizes for conversion growth first; it now optimizes for privacy compliance before an audit, with no added team capacity or budget. That means the BA should quickly review the changed objective, identify newly critical stakeholders such as compliance and operations, and reprioritize elicitation and analysis toward requirements that reduce audit risk.

A practical adjustment is to:

• focus first on privacy-critical and mandatory requirements
• defer lower-priority marketing analysis
• update stakeholder engagement and analysis activities
• revise contingency planning around audit deadlines and requirement coverage

The closest distractor preserves momentum, but it delays response to the new primary objective and increases compliance risk.

This best aligns business analysis work to the changed project objective while addressing the highest compliance risk under fixed time and resource constraints.

Question 109

Topic: Analysis

A BA is validating requirements for a new warehouse receiving app. The requirement set includes screen flows, barcode-scan exceptions, and mandatory quality checks. Site supervisors who will use the app can attend only one 45-minute session during peak season, compliance requires approval before development starts, and no working software exists yet. Which validation method is the BEST choice?

• A. Run a low-fidelity prototype review with supervisors
• B. Request a peer review by senior BAs and architects
• C. Plan user acceptance testing with supervisors
• D. Facilitate a walkthrough of the written requirements package

Best answer: A

What this tests: Analysis

Explanation: A prototype is best when requirements are interaction-heavy and business users have limited time. It allows supervisors to validate flows, exceptions, and usability before development, which also satisfies the need for pre-build approval.

The best validation method should match both the requirement set and the stakeholder situation. Here, the requirements are highly visual and workflow-driven: screen navigation, barcode exceptions, and quality-check steps are easier for supervisors to assess when they can see and react to a concrete model. A low-fidelity prototype lets the BA validate completeness, accuracy, and usability in one short session before any build begins. That timing matters because compliance approval is required before development, and there is no working solution yet to test. Compared with text-based review methods, a prototype reduces misunderstanding faster for operational users and exposes gaps in the future-state process more effectively. The key takeaway is to use an early, visual validation technique when user interaction and limited stakeholder availability are the main constraints.

A prototype makes workflow and exception requirements tangible for end users in a short pre-build session, which fits both the requirement type and stakeholder constraints.

Question 110

Topic: Planning

A business analyst is preparing a requirements package for vendor selection. Stakeholders have been editing documents through email, and a prior decision to exclude mobile reporting was later disputed because no one could find the approved version or the rationale. The sponsor wants an initial scope baseline next week, but expects later changes to be formally evaluated. What should the business analyst do next?

• A. Continue elicitation until stakeholders stop suggesting updates, then save one final copy
• B. Set up document control with version IDs, baseline markers, and a decision/change history
• C. Obtain sponsor approval on the current draft and handle later edits informally
• D. Wait until vendor selection is complete before creating traceability and version records

Best answer: B

What this tests: Planning

Explanation: The best next step is to establish document control that supports both baselines and historical decisions. A controlled versioning approach lets the team mark an approved baseline now while preserving the rationale and change history needed for future evaluation.

When a baseline is needed but future changes are expected, document control should do more than store the latest file. It should identify each version, clearly mark the approved baseline, and preserve the history of decisions, approvals, and changes. In this scenario, the team already has confusion from email edits and lost rationale, so the immediate need is a standard versioning and history approach that supports traceability and controlled change.

A good next step is to establish document control that includes:

• unique version identifiers
• baseline status or approval markers
• retained prior versions
• decision and change history linked to requirements

Immediate approval without control weakens the baseline, and waiting until later loses traceability. The key takeaway is that baselines are only useful when historical decisions and subsequent changes can be reliably reconstructed.

This creates a controlled baseline while preserving prior decisions and rationale so later changes can be traced and evaluated properly.

Question 111

Topic: Traceability and Monitoring

A requirements baseline for Release 2 was signed off yesterday.

Exhibit: Change control plan excerpt

BA may approve a change only if all are true:
- no compliance or policy impact
- no external interface impact
- estimated rework is 16 hours or less

Escalate to the change control board if any are true:
- compliance or policy rule changes
- traced impacts to interfaces, reports, test cases, or training
- change affects the current release baseline

Defer only if the change is not needed for the current release objective and the sponsor agrees.
Reject only if the request duplicates or conflicts with an approved requirement.

During UAT, the compliance lead requests capturing consent timestamp and source for online enrollments before go-live. Impact analysis shows updates to the CRM interface, audit report, six test cases, and training materials. Estimated rework is 10 hours. What should the business analyst do?

• A. Defer the change to the next release
• B. Approve the change and update the baseline
• C. Reject the change as out of scope
• D. Escalate the change to the change control board

Best answer: D

What this tests: Traceability and Monitoring

Explanation: The change must be handled according to the approved change control plan, not just by effort size. Although the rework is only 10 hours, the request affects compliance and several traced artifacts tied to the current release baseline, which triggers escalation.

This question tests controlled requirements change after baselining. Once the baseline is signed off, the business analyst should compare the requested change to the plan’s decision rules and use traceability results to determine the correct path.

Here, the request is needed before go-live, so it supports the current release objective rather than a future enhancement. The impact analysis also shows downstream effects to an external interface, a report, test cases, and training materials. Under the plan, any compliance or policy change and any such traced artifact impact require change control board review, even if the estimated effort is small.

The key takeaway is that low rework hours do not override escalation triggers tied to baseline integrity and downstream dependency coverage.

Escalation is required because the request changes a compliance rule and affects multiple traced downstream artifacts in the current release baseline.

Question 112

Topic: Analysis

A claims-processing solution is in UAT. A compliance officer submits a change request to add a state-specific disclosure. Requirements are baselined, and the repository includes version-controlled business rules, interface specifications, and a traceability matrix linking requirements to test cases and training materials. SMEs recall the current rule differently, and a workshop would delay the compliance date. What is the best source for the BA to identify the change impact first?

• A. Review baselined requirements, versioned rules, and trace links first.
• B. Facilitate an SME workshop to re-create the current requirement set.
• C. Interview the compliance officer and developer, then revise requirements.
• D. Submit the change for approval and let testers find affected items.

Best answer: A

What this tests: Analysis

Explanation: When requirements are already baselined and supported by version-controlled traceability artifacts, those approved documents are the best first source for change impact analysis. They show the current agreed state and downstream dependencies without relying on conflicting stakeholder memory.

The core concept is using the most authoritative source for elicitation in context. In change control, once requirements are baselined, existing approved artifacts often provide better information than interviews or workshops for identifying what will be affected. Here, the repository already contains the current business rules, interface details, and trace links to test cases and training materials, so the BA can analyze the approved state and dependency coverage before engaging stakeholders further.

A sound sequence is:

• Confirm the current baseline and document version.
• Use trace links to find impacted downstream artifacts.
• Identify gaps or conflicts that need stakeholder clarification.
• Then discuss only unresolved items through targeted follow-up.

A workshop or interview may still help later, but starting there risks using inaccurate recollections and weakens baseline discipline.

Approved, version-controlled artifacts provide the most reliable source for impact analysis when requirements are already baselined and traceable.

Question 113

Topic: Analysis

During a review of draft requirements for a claims portal, the sponsor states, “The portal must be intuitive and provide fast status updates for customers.” Developers ask whether this requirement is ready to baseline. Before deciding, what should the business analyst obtain first?

• A. Vendor estimates for notification performance
• B. Agreed task success measures and response time thresholds
• C. Relative business priority of portal features
• D. Preferred screen layouts for the portal pages

Best answer: B

What this tests: Analysis

Explanation: The statement is not yet actionable because “intuitive” and “fast” are subjective. The BA should first obtain specific success measures, such as task completion targets and timing thresholds, so the requirement can be developed and tested consistently.

For a requirement to be suitable for development, it must be clear, measurable, and testable. In this scenario, the words “intuitive” and “fast” are vague because different stakeholders could interpret them differently. The first step is to clarify the expected outcome in measurable terms, such as which customer tasks matter, what completion rate or error rate is acceptable, and how quickly status updates must appear.

Once those criteria are defined, the BA can express the requirement in actionable wording that supports design, build, and validation. Items like screen layouts, feature priority, or vendor estimates may still be useful, but they come after the business need has been translated into specific acceptance criteria. The key takeaway is that vague adjectives should be replaced with observable results and thresholds.

This converts subjective wording into measurable acceptance criteria that development and testing can implement and verify.

Question 114

Topic: Traceability and Monitoring

On a claims-processing project, the BA team uses a requirements repository with Description, Priority, and Status fields. Reviewers notice many “changes” only add notes such as “approved,” “deferred to release 2,” or “in testing” to the Description, while the Status field is often blank. Developers and testers now re-review items because they cannot tell whether a requirement’s content changed, its delivery order changed, or it simply moved through the lifecycle. What is the most likely underlying BA gap?

• A. No formal change control for post-baseline scope changes
• B. No stakeholder agreement on release priority
• C. No business validation of requirements before approval
• D. No clear separation of lifecycle status from content and priority tracking

Best answer: D

What this tests: Traceability and Monitoring

Explanation: The problem is not mainly weak validation, missing priority decisions, or generic scope control. The key clue is that lifecycle labels are being written into the requirement description while the Status field is left blank, which mixes status updates with content changes and reprioritization.

This scenario tests whether the BA can distinguish three different kinds of updates: lifecycle status, requirement content, and priority. Terms such as approved, in testing, and implemented describe where a requirement is in its lifecycle and should be recorded as status attributes in the traceability tool. Terms such as deferred to release 2 affect sequencing or target release and should be handled as priority or planning data. Only changes to the actual requirement wording, rule, or acceptance criteria are content changes.

When the team writes all of these into the description field, the audit trail becomes unclear and stakeholders cannot tell what actually changed. That causes unnecessary re-review, approval churn, and confusion. The right BA practice is to maintain separate fields and update the traceability artifact so each type of change is visible and controlled appropriately. The closest distractor is missing change control, but first the team must correctly classify what kind of change occurred.

The repository is being used to record status movement inside the requirement text, so stakeholders cannot distinguish status updates from real content changes or reprioritization.

Question 115

Topic: Planning

In a hybrid project for an insurer’s claims portal, the product owner proposes dropping formal links between approved requirements, user stories, test cases, and change requests to speed delivery. The project manager asks the business analyst whether this lighter approach is acceptable. Before recommending a traceability strategy, what should the business analyst verify FIRST?

• A. Stakeholder preferences for document detail and sign-off format
• B. The required trace links for change impact, test coverage, and audits
• C. Defect trends from similar recent releases
• D. The team’s preferred backlog tool and reporting features

Best answer: B

What this tests: Planning

Explanation: The first decision is not about tools or documentation style; it is about why traceability is needed. The business analyst should confirm the level of traceability required to support change control, testing, and auditability before recommending a lighter approach.

In PMI-PBA planning, the traceability strategy should be tailored to the solution context and the decisions it must support. Here, the key missing information is whether the project needs end-to-end links to perform impact analysis on changes, prove test coverage against approved requirements, or provide audit evidence. If those needs exist, reducing traceability can weaken change control, leave requirements insufficiently tested, and make it hard to show what was approved, built, and validated.

A sound sequence is:

• Confirm compliance, governance, and audit expectations.
• Confirm how requirement changes will be assessed and approved.
• Confirm how test cases and results must map to requirements.

Tool capability, document preferences, and historical defects matter later, but they do not determine the minimum traceability needed as directly as downstream control and verification needs do.

Traceability depth should be based first on downstream needs for impact analysis, validation, and audit evidence, because missing links create control and verification gaps.

Question 116

Topic: Planning

A BA is defining the traceability strategy for a customer onboarding initiative. The sponsor wants to show, for every approved requirement, the originating stakeholder need, the design artifact and build component that implement it, the test evidence that validates it, and the business objective of cutting onboarding time from 5 days to 1 day. Audit reviews are expected, and changes must be assessed quickly. Which traceability approach is the best fit?

• A. Links from approved requirements only to design documents and code modules
• B. Links from business objectives only to release plans and training materials
• C. Links from each requirement only to user stories and test cases
• D. Bidirectional links from each requirement to source, design, build, test, and outcome metric

Best answer: D

What this tests: Planning

Explanation: The scenario calls for full lifecycle traceability, not a partial delivery view. Because the organization needs audit support, rapid change impact analysis, and proof of business value, each requirement should be traceable backward to its source and forward through design, build, test, and business outcome.

The key concept is defining the necessary level of traceability before detailed requirements work begins. In this case, the traceability strategy must support three needs at once: origin transparency, implementation control, and value validation. That means each requirement should connect back to its source or rationale and forward to the design artifact, implemented component, validating test evidence, and the business objective or metric it is meant to influence.

This end-to-end structure helps the BA and team:

• assess change impacts quickly
• confirm that all approved requirements were implemented and tested
• support audit and approval reviews
• evaluate whether delivered functionality contributes to the expected business outcome

Approaches that trace only to delivery artifacts or only to high-level planning artifacts leave gaps in monitoring and validation. The closest distractors help execution, but they do not provide full requirement-to-value traceability.

This creates end-to-end traceability for auditability, impact analysis, validation, and confirmation that the requirement supports the intended business result.

Question 117

Topic: Analysis

A business analyst is documenting a new vendor onboarding workflow for a regulated healthcare company. The process includes requester, procurement, compliance, and finance roles, plus exception paths for missing tax forms, sanctions hits, and urgent one-time purchases. Developers need enough detail to automate routing and status changes, and approvers need a package suitable for formal review. Which format is the best fit for writing this process requirement?

• A. A use case with actors, trigger, flows, and postconditions
• B. A user story with brief acceptance criteria
• C. A screen prototype of the onboarding form
• D. A swimlane process model only

Best answer: A

What this tests: Analysis

Explanation: A detailed use case is the best fit because the requirement centers on process behavior across multiple actors with several exception paths and formal review needs. Use cases make the workflow actionable by documenting the trigger, preconditions, main flow, alternate flows, and outcomes.

The core concept is choosing a process requirement format that matches the level of detail and control the situation requires. In this case, the workflow spans several roles, must support automation, and includes multiple exception paths that matter to both developers and approvers. A use case is the strongest fit because it can describe the end-to-end interaction in a structured, reviewable way.

• identifies actors and trigger
• defines preconditions and postconditions
• describes the main success path
• captures alternate and exception flows

A user story is usually better for a smaller, lighter-weight backlog item. A swimlane model is useful to visualize handoffs, but by itself it often does not provide enough detail on system behavior and branching logic for development. A prototype focuses on interface design rather than the full workflow. The closest distractor is the swimlane model, but it is less complete as a build-ready process specification here.

A detailed use case best fits an exception-heavy, multi-actor workflow because it captures normal and alternate flows in a form suitable for development and formal review.

Question 118

Topic: Planning

A BA is tailoring the traceability approach for two releases at a health insurer. One release only relabels internal dashboard fields; the other automates prior-authorization decisions that must satisfy state regulations and annual audits. Which artifact would best support recommending full bidirectional traceability for the authorization release, while using lighter coverage for the dashboard change?

• A. A pilot training report showing strong user attendance
• B. An elicitation log showing interviews completed with all stakeholders
• C. A compliance matrix linking regulations, rules, requirements, tests, and controls
• D. A sprint burndown chart showing stable delivery velocity

Best answer: C

What this tests: Planning

Explanation: Full bidirectional traceability is most justified when requirements carry compliance, audit, or high-risk obligations that must be proven from source through delivery and back again. A compliance matrix provides that evidence; the other choices show project activity or adoption indicators, not the need for deeper trace coverage.

The key concept is to tailor traceability depth to risk, complexity, and proof needs. A minor internal label change can often use lighter trace links because the impact is limited and formal audit evidence is usually unnecessary. In contrast, a regulated prior-authorization process needs stronger control over requirement origin, downstream implementation, and validation.

A compliance matrix is the best evidence because it supports both directions of traceability:

• from each regulation or business rule forward to requirements, tests, and controls
• from each delivered control backward to an approved requirement and source obligation

That level of coverage is what allows the team to monitor change impact, demonstrate completeness, and satisfy audit questions. Measures such as completed interviews, team velocity, or training participation may be useful in other contexts, but they do not establish the necessity for full bidirectional traceability.

It shows the need to prove each regulatory source is implemented, tested, and traceable back from each control, which warrants full bidirectional traceability.

Question 119

Topic: Planning

A business analyst is reviewing a draft requirements package note for a baselined requirement in an order management project. Before this change is approved, what is the most important improvement needed in the note?

Draft note:

Change request: CR-27
Business reason: Sales leaders want urgent orders released faster
Revised requirement: Supervisors can override an automated fraud hold
Acceptance criterion: An authorized supervisor can release a held order and record a reason
Assessment recorded:
- Estimated effort: 5 story points
- Priority: High
- Proposed release: Iteration 6
Decision recommendation: Approve

• A. Define exactly which supervisor roles may use the override.
• B. Add impact analysis for value, traced dependencies, delivery impact, and compliance risk.
• C. Add the change requester name and document version.
• D. Rewrite the business reason as a user story.

Best answer: B

What this tests: Planning

Explanation: The note is missing the core impact analysis needed for requirement change approval. A baselined change should be evaluated for business value, affected traced items, delivery consequences, and risk or compliance effects before recommending approval.

For a baselined requirement, approval should be based on impact analysis, not just priority or estimated effort. The key question is what the change will affect: whether it still supports the business need and expected value, which traced requirements, business rules, interfaces, test cases, controls, or process artifacts are impacted, and what happens to schedule, cost, resources, risk, and compliance.

In this note, the analyst recorded effort, priority, and a proposed release, then jumped to an approval recommendation. That is incomplete because it does not show the decision-makers the full effect of adding a manual override to an automated control. Clarity and document control matter, but they do not replace evaluating approval-impact criteria.

Approval requires documented impact criteria, and the note only shows urgency and effort without assessing business, downstream, and risk effects.

Question 120

Topic: Needs Assessment

A BA is preparing a discovery package for a self-service claims portal. The team plans to use the package next week to prioritize requirements for the first release. One draft note reads:

Stakeholder input:
- Claims director: "Use a guided wizard."
- Operations manager: "Keep one-page entry."
- Compliance lead: "Require document upload before submit."
- Sales VP: "Do not add extra steps."
Purpose: prioritize release 1 features

What is the most important improvement to this note?

• A. Add a version number and approval status to the note
• B. Rewrite each statement as a measurable acceptance criterion
• C. Assign a unique identifier to each requested feature
• D. Document each preference’s underlying value and desired business outcome

Best answer: D

What this tests: Needs Assessment

Explanation: The draft captures what stakeholders say they want, but not why they want it. To prioritize effectively, the BA needs the underlying values and expected outcomes behind each preference, such as speed, compliance risk reduction, or customer conversion.

This item tests the difference between stated preferences and underlying stakeholder values. The note lists preferred solution approaches, but several conflict with each other, and there is no rationale showing what each stakeholder is trying to protect or achieve. Before using the note for prioritization, the BA should capture the value behind each request, such as reducing incomplete claims, maintaining processing speed, lowering compliance exposure, or minimizing customer abandonment.

Once those values are explicit, the team can compare options against business objectives instead of debating preferred designs.

The closest distractors improve documentation quality, but they do not solve the core problem that the package lacks the value baseline needed for prioritization.

Prioritization should be based on stakeholder values and rationale, not just conflicting solution preferences.

Question 121

Topic: Analysis

A business analyst on a hybrid project is preparing work for a two-week sprint to add an address-change feature to a customer portal. The product owner wants the story ready for sprint planning tomorrow. Developers need clearer completion conditions. Compliance requires an audit trail and postal-code validation. A draft screen mockup exists, but the external address-verification interface will not be designed until next sprint. What should the business analyst do next?

• A. Keep the story high level and let developers define details during build.
• B. Send the draft story for stakeholder sign-off before adding more detail.
• C. Write a full end-to-end use case and complete interface specification now.
• D. Add acceptance criteria and key business rules now; track interface details for later refinement.

Best answer: D

What this tests: Analysis

Explanation: The best next step is to add the detail needed for sprint readiness now: measurable acceptance criteria and known business rules. Since the interface design is planned for next sprint, capturing it for later refinement avoids unnecessary detail and rework.

In a hybrid or iterative delivery context, requirements should be specified at the level needed for the immediate decision and work horizon. Here, the story must be ready for sprint planning tomorrow, so it needs clear acceptance criteria and the known rules that determine completion, including audit trail and postal-code validation. Those details make the requirement actionable for development and testable for validation. The external interface is not yet designed and is scheduled for later refinement, so producing a complete interface specification now would add detail the team cannot yet use and may have to rewrite. The right approach is to document what is known, note the dependency or future elaboration, and avoid over-specifying beyond the current context.

This provides just enough detail to make the story measurable and actionable for the upcoming sprint without over-specifying future interface work.

Question 122

Topic: Needs Assessment

A BA is helping executives choose one of three initiatives. The estimated costs and high-level benefits are stable, but each review meeting ends with a different preferred option because sales emphasizes revenue growth, operations emphasizes cycle-time reduction, and compliance emphasizes auditability. The shortlist keeps changing, and approval is repeatedly deferred. What is the most likely underlying BA gap?

• A. The requirements should be baselined before initiative selection.
• B. The solution needs operational readiness validation first.
• C. No weighted comparison criteria were defined around stakeholder value drivers.
• D. The cost estimates need another round of refinement.

Best answer: C

What this tests: Needs Assessment

Explanation: The core issue is not missing numbers but missing decision structure. When stakeholders value different outcomes, a weighted criteria approach helps compare initiatives consistently against agreed value drivers and reduces repeated preference shifts.

This scenario points to a valuation gap in needs assessment. The options already have stable cost and benefit estimates, yet the preferred choice changes because each stakeholder group is judging value through a different lens. In that situation, the BA should use a weighted criteria model so stakeholders first agree on the evaluation factors and relative importance, then score each initiative consistently.

A weighted comparison is especially appropriate when options differ across multiple dimensions such as revenue, efficiency, compliance, and customer impact. Without that structure, meetings often produce approval churn, subjective debate, and rework rather than a clear value proposition. The closest distractor is refining cost estimates, but the stem says the estimates are already stable; the instability is coming from unaligned valuation criteria.

The recurring approval churn shows the options were not evaluated with an agreed weighted criteria model tied to stakeholder priorities.

Question 123

Topic: Needs Assessment

A business analyst is beginning a needs assessment for a redesigned returns process. The sponsor needs an initial problem and opportunity assessment within one week. The analyst already has the business goals and a current-state summary showing impacts to stores, e-commerce, finance, customer service, and compliance. More than 30 possible stakeholders have been named, but there is not enough time for individual outreach to everyone. What should the business analyst do next?

• A. Interview the most senior managers first and identify other stakeholders only if gaps appear
• B. Ask the sponsor to approve a shortened stakeholder list before any outreach begins
• C. Group stakeholders by impact area and select representatives from each group for initial outreach
• D. Send the same questionnaire to all named stakeholders and wait for responses

Best answer: C

What this tests: Needs Assessment

Explanation: When time is limited, the analyst should still ensure broad representation by prioritizing outreach across affected stakeholder groups rather than by title or convenience. Using goals and impact areas to choose representatives is the best next step because it is fast, structured, and aligned to needs assessment.

The core concept is stakeholder identification and prioritization based on the business goals, objectives, and areas affected by the change. In this scenario, the analyst already knows which functions are impacted, so the next step is to map those impact areas to stakeholder groups and choose representative participants from each one for initial outreach. That approach preserves broad coverage while fitting the one-week constraint.

• Review the impacted functions and goals.
• Identify stakeholder categories tied to those impacts.
• Select representative stakeholders with decision authority, operational knowledge, or affected-user perspective.
• Begin outreach with that balanced set.

Choosing only senior leaders, waiting for blanket survey responses, or seeking approval on a reduced list too early risks missing key perspectives and weakens the needs assessment.

This balances limited time with broad representation by using the goals and impact areas to prioritize representative stakeholders.

Question 124

Topic: Analysis

During validation of a near-final loan-origination demo, compliance and operations discover that the solution cannot store the reason for an overridden credit decision. Without that data, the bank cannot satisfy audit requirements or measure the business case benefit of reducing manual review. The approved requirements baseline does not include this need. What is the best corrective action?

• A. Log it as a defect and ask the delivery team to fix it within the current baseline.
• B. Initiate impact analysis and formal change control to update the baseline requirements and acceptance criteria.
• C. Continue validation using a manual workaround while stakeholders reprioritize lower-value requirements.
• D. Approve the release and place the missing capability in a future enhancement backlog.

Best answer: B

What this tests: Analysis

Explanation: A major gap found during validation means the current requirements are not complete or aligned to business objectives. When the gap affects compliance and expected value, the BA should trigger impact analysis and formal change control, then update the baseline and acceptance criteria before approval.

Requirements validation confirms that documented requirements are complete, accurate, and aligned with goals, constraints, and value expectations. Here, the demo exposed a missing capability that is essential for auditability and for realizing the stated business benefit. Because the approved baseline omitted a material need, the issue is not just a build defect or a minor clarification.

The appropriate response is to assess the impact and route the change through the agreed control process so affected artifacts can be updated and revalidated:

• assess business, compliance, schedule, and solution impacts
• update the requirement set and acceptance criteria if approved
• maintain traceability to objectives, tests, and solution components
• revalidate before sign-off

The closest distractor is treating the issue as a defect, but a missing baseline requirement requires controlled requirements correction, not just technical rework.

Because the gap is material to compliance and value realization, it must be analyzed, approved, and incorporated into the baseline before sign-off.

Question 125

Topic: Traceability and Monitoring

A business analyst is preparing a one-page weekly requirements status update for the project manager and sponsor. They asked to see only the most important status signals and any items needing immediate action. The current draft note reads:

Requirements status
- Total: 126
- Approved: 92
- In review: 18
- Draft: 10
- Deferred: 6
- Open change requests: 4
- Failed validation: 3

One failed item is a regulatory reporting requirement on the release critical path; the other failed items are low-impact enhancements. What is the most important improvement before sending this update?

• A. Visually highlight high-impact exceptions, risks, and needed decisions
• B. Add percentages for each status category
• C. List IDs and versions for all approved requirements
• D. Split the counts by requirement type

Best answer: A

What this tests: Traceability and Monitoring

Explanation: The draft is an inventory of counts, not a signal-focused status report. Because one failed requirement is regulatory and on the critical path, the update should visually emphasize that exception, its risk, and any decision needed so stakeholders can act quickly.

When stakeholders ask for the most important requirements status signals, the report should use exception-based summary reporting rather than just totals. In this case, aggregate counts hide the fact that one failed validation result threatens compliance and the release path, while the other failures are minor. The best improvement is to visually flag high-impact items and show why they matter, who needs to act, and what decision is required.

A strong summary would highlight:

• critical or high-risk requirements
• failed or blocked items affecting release or compliance
• open changes needing approval
• owners and immediate next actions

Adding more detail or better formatting can help, but it does not solve the main problem if the most important signal is still buried.

This makes the summary action-oriented by surfacing the critical failed requirement instead of burying it in aggregate counts.

Questions 126-150

Question 126

Topic: Analysis

A business analyst has baselined Release 1 requirements for an order-to-cash initiative. Two automation requirements and one interface requirement trace directly to the business case goal of reducing order rework by 25%, and the interface is a dependency for planned UAT scenarios. During iteration planning, the operations manager proposes deferring those items to add three executive dashboard requirements because the reporting team is available now, and the sponsor supports the swap for visibility. What should the BA do next?

• A. Reallocate to dashboard work because resource availability is the immediate constraint.
• B. Run trace-based impact analysis, then baseline any approved reallocation through change control.
• C. Record the dashboard request separately and keep current allocations unchanged.
• D. Let the sponsor choose the preferred set and update the baseline document.

Best answer: B

What this tests: Analysis

Explanation: The best response is to evaluate both allocation proposals through traceability before changing the baseline. Because the automation and interface requirements are tied to the business case and downstream UAT dependencies, any swap must be justified by impact analysis and processed through formal change control.

The core concept is controlled reallocation of baselined requirements. Once requirements are accepted into a baseline, competing proposals should be reconciled by tracing each affected item to business objectives, value measures, dependencies, and downstream artifacts such as test scenarios. In this case, the proposed dashboard swap may improve visibility, but the deferred items currently support the stated value target and a required interface dependency.

A sound BA response is to:

• assess impact using existing trace links
• compare value and dependency consequences of each proposal
• recommend the allocation that best preserves the business case
• update baseline version and lifecycle status only after approval

The closest distractor is leaving the baseline unchanged, but that avoids evaluating a legitimate change request rather than managing it properly.

This preserves business value by comparing both proposals against traced objectives and dependencies before any baseline change is approved and versioned.

Question 127

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?

• A. Baseline the requirement as mandatory and track the issue as a delivery risk.
• B. Defer the requirement as a low-priority backlog item for a future release.
• C. Classify the requirement as infeasible, trace the constraints, and propose a viable alternative login option.
• D. Ask the sponsor to reprioritize the requirement against other enrollment features.

Best answer: C

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:

• confirm and document the governing constraints
• classify the requirement as infeasible for the current scope
• trace the rationale to legal and architecture sources
• propose an alternative that still supports the business goal

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.

Question 128

Topic: Needs Assessment

A subscription insurer needs a digital retention portal live before the annual renewal campaign in 6 months. The BA compares two vendor solutions:

• Solution A: $220,000 upfront, 4-month deployment, integrates with the current CRM, 2 weeks of supervisor training
• Solution B: $170,000 upfront, 4-month deployment after the enterprise customer data hub is available, 3 weeks of supervisor training

The customer data hub is planned for next fiscal year and is not yet funded. The business case assumes benefits start during this renewal campaign. Which difference most materially affects the initiative’s value proposition?

• A. Solution A’s integration with the current CRM
• B. Solution B’s extra week of supervisor training
• C. Solution B’s dependency on the unfunded customer data hub
• D. Solution A’s higher upfront price

Best answer: C

What this tests: Needs Assessment

Explanation: The most material factor is the one that can change whether projected benefits are achieved in the required time frame. Solution B’s lower cost is outweighed by its dependence on an unfunded prerequisite that may prevent benefits from starting during the renewal campaign.

In needs assessment, a cost, risk, or dependency is material when it can significantly change expected value, timing of benefits, or delivery certainty in the business case. Here, the initiative’s value depends on going live in time for the renewal campaign. Although Solution B has a lower upfront cost, it cannot proceed until the customer data hub is available, and that prerequisite is not yet funded and sits outside the initiative’s control.

That dependency creates a direct threat to time-to-value and benefits realization. By contrast, the higher purchase price, a one-week training difference, and current-CRM integration may influence implementation effort or cost, but they do not by themselves undermine the core assumption that benefits begin within the needed window. The key takeaway is that an external, unfunded dependency is more value-critical than a modest cost advantage.

An unfunded external dependency can delay or prevent benefit realization, making it the most material risk to the business case.

Question 129

Topic: Traceability and Monitoring

A business analyst is monitoring a traceability matrix for a claims-processing solution. Team policy states that requirements must have approved models before leaving analysis, approved documentation before entering build, and linked approved test cases before test execution. Which action should the BA NOT take when confirming supporting artifacts exist at the proper lifecycle point?

• A. Escalate requirements lacking linked test cases before system testing begins.
• B. Use lifecycle status fields to spot requirements missing approved models.
• C. Include artifact readiness gaps in regular requirements status reports.
• D. Let urgent requirements enter build and complete missing documentation later.

Best answer: D

What this tests: Traceability and Monitoring

Explanation: Supporting artifacts must exist, be reviewed, and be approved before a requirement moves to the next lifecycle state. Allowing an urgent requirement to enter build without the required documentation breaks traceability control and weakens downstream quality and readiness checks.

The core concept is lifecycle-based requirements monitoring: the BA uses traceability to confirm that each requirement has the supporting artifacts required for its current and next state. In this scenario, approved models are needed before leaving analysis, approved documentation before build, and approved linked test cases before testing. That means readiness is not based on urgency alone; it is based on whether the required artifacts exist and have the right review and approval status.

A sound monitoring approach is to:

• check artifact links and status in the traceability tool
• flag missing or unapproved artifacts before handoffs
• communicate gaps that block progression

The tempting mistake is treating documentation as something that can be finished after build starts, but that defeats the control point the policy establishes.

This bypasses the required artifact readiness checkpoint and allows a requirement to advance without the approved documentation needed at that lifecycle stage.

Question 130

Topic: Planning

A business analyst is choosing between two traceability strategies for upcoming work:

• A lightweight approach that links features to user stories and sprint acceptance results
• A rigorous bidirectional approach that links business objectives, regulations, requirements, approvals, test cases, and release versions

For which initiative is the rigorous bidirectional approach most appropriate?

• A. An internal marketing dashboard built by one agile team with informal stakeholder reviews
• B. A knowledge base refresh using existing content and manager approval before launch
• C. A claims-processing rules update with regulatory audit exposure, multiple vendors, and formal UAT sign-off
• D. A mobile expense app pilot with minor UI changes that can be quickly rolled back

Best answer: C

What this tests: Planning

Explanation: The rigorous traceability approach fits work that has high compliance exposure, several parties contributing to delivery, and formal validation gates. In that context, the BA needs clear end-to-end links from business and regulatory sources through requirements, testing, approvals, and release decisions.

The core concept is tailoring traceability to project context rather than applying the same level everywhere. When work carries regulatory audit risk, involves multiple vendors, and requires formal UAT approval, the BA needs stronger bidirectional traceability so each requirement can be traced backward to its source and forward to validation and release evidence.

This level of traceability helps the team:

• prove compliance coverage
• assess change impact across handoffs
• confirm every approved requirement was tested
• support audits and sign-off decisions

A lightweight story-level approach is usually sufficient for lower-risk, reversible, single-team work, but it is not strong enough when compliance and approval rigor drive the need for monitoring and validation.

High compliance risk, multiple delivery handoffs, and formal approval needs justify end-to-end bidirectional traceability.

Question 131

Topic: Traceability and Monitoring

A business analyst is updating the requirements communication approach for a hybrid project. The steering committee meets monthly and wants decision-focused status on requirement changes, risks, and business impact. The delivery team works in weekly iterations and needs prompt clarification of detailed requirement issues. Which communication practice should the business analyst AVOID?

• A. Sending the steering committee a periodic summary of changes, impacts, and decisions needed
• B. Using one detailed daily requirements report for all audiences
• C. Sharing frequent detailed updates with the delivery team on open questions and dependencies
• D. Escalating major requirement risks to governance outside the normal reporting cycle when needed

Best answer: B

What this tests: Traceability and Monitoring

Explanation: Requirements status communication should be tailored to the audience. Governance stakeholders typically need summarized, decision-oriented information at a lower frequency, while working teams need more frequent, detailed updates to resolve issues quickly.

The core concept is audience-based tailoring of requirements communication. In this scenario, the steering committee needs concise information about changes, risks, impacts, and decisions, while the delivery team needs frequent operational detail to keep work moving. A single detailed daily report for everyone is an anti-pattern because it ignores stakeholder needs, creates noise for governance, and can bury the information each audience actually needs.

A good communication approach aligns:

• frequency to how quickly the audience must act
• detail to the decisions or actions expected
• escalation timing to the urgency of the issue

The closest trap is assuming that consistency means sending identical content to everyone; effective communication is consistent in message, but tailored in format, timing, and depth.

This should be avoided because governance and working-team audiences need different levels of detail and different communication frequency.

Question 132

Topic: Planning

A business analyst is finalizing a traceability strategy for a hybrid customer onboarding project. The strategy will track each requirement’s unique ID, source, rationale, priority, owner, version, and links to business objectives and solution components. The operations lead adds that, before go-live, the team must show during UAT that every approved requirement was verified. What should the business analyst do next?

• A. Begin elicitation and defer validation links to the QA lead
• B. Submit the strategy for sponsor approval as written
• C. Add links from requirements to acceptance criteria and test cases
• D. Start reporting traceability status using the current strategy

Best answer: C

What this tests: Planning

Explanation: The strategy already covers upstream context and some downstream links, but it misses the validation path needed to prove requirements were verified. The best next step is to extend traceability to acceptance criteria and test cases before baselining the approach.

A traceability strategy should define enough linkage to monitor requirements across their lifecycle and validate that the delivered solution meets them. In this scenario, the strategy already traces requirements to their origin and to solution components, but the stated business need is to demonstrate in UAT that every approved requirement was verified before go-live. Without planned links to acceptance criteria and test cases, the team cannot reliably show that validation coverage exists for each requirement.

The next step is to add those validation relationships to the traceability strategy before approval or reporting. That keeps monitoring and validation built into the plan rather than leaving them to ad hoc test execution later. Seeking approval or issuing reports first would formalize an incomplete strategy, and deferring the gap to QA weakens end-to-end requirements ownership.

This closes the key gap by enabling each approved requirement to be monitored through validation and demonstrated as verified before release.

Question 133

Topic: Evaluation

A claims-processing solution is in final UAT. Users find that claims flagged for possible fraud are routed to payment instead of manual review, which conflicts with an approved requirement and a compliance procedure. The sponsor asks whether to deploy with a temporary workaround. Which output should the business analyst communicate to best enable stakeholders to resolve this gap?

• A. A traceable gap analysis with failed criteria, impact, and workaround risk
• B. The latest approved requirements package with version history
• C. A training readiness report with attendance and job-aid completion
• D. A UAT dashboard with total scripts run and overall pass rate

Best answer: A

What this tests: Evaluation

Explanation: The best communication is a traceable gap analysis that links the unmet requirement to failed acceptance evidence and business impact. Stakeholders need decision-quality information about the delta’s significance and the risk of any workaround, not just activity status or baseline documents.

When a solution gap must be resolved, stakeholders need a communication artifact that shows more than the existence of a problem. A traceable gap analysis connects the approved requirement, the failed acceptance or test evidence, the operational or compliance impact, and the risk of proposed workarounds. That combination supports an informed decision about whether to remediate, defer, accept, or reject deployment.

In this case, the issue affects a compliance-related routing rule, so the key need is not general progress reporting but a clear view of the discrepancy’s significance. A useful gap communication typically includes:

• the specific requirement or acceptance criterion not met
• the evidence showing the developed solution’s actual behavior
• the business, regulatory, or operational impact
• the severity, workaround, and decision needed

High-level status measures or readiness reports may be useful elsewhere, but they do not enable resolution of this discrepancy.

This gives stakeholders the exact discrepancy, supporting evidence, and business impact needed to decide whether to accept, fix, or defer the gap.

Question 134

Topic: Analysis

A BA is eliciting requirements for a new hospital medication administration app. Nurses work in fast, interruption-heavy bedside settings and often use informal workarounds for urgent cases. The BA interviewed department managers and sent questionnaires to nurses, and the requirements package was approved. During pilot testing, many missed exception paths are discovered, and the screens do not match actual bedside workflow, causing significant rework. What is the most likely underlying BA gap?

• A. Obtaining approval from the wrong stakeholder group
• B. Defining acceptance criteria too early
• C. Using questionnaires instead of observing bedside work
• D. Baselining requirements too late in the project

Best answer: C

What this tests: Analysis

Explanation: The main problem is a poor fit between the elicitation technique and the requirement type. Actual bedside workflow, interruptions, and workarounds are best discovered through observation, not mainly through questionnaires and manager interviews.

When requirements depend on how people actually perform work in a real environment, the BA should favor observation or contextual inquiry. In this scenario, nurses operate in a fast, interruption-heavy setting with informal workarounds, which means key requirements are tacit and situational rather than easy to self-report. That is why approved requirements still missed exception paths and real workflow needs.

A good way to reason through this is:

• Identify the requirement type: operational workflow and exceptions
• Identify the stakeholders: frontline users in their work context
• Match the technique: direct observation of real tasks

Late baselines or sign-off issues can worsen rework, but they do not explain why the requirements failed to reflect actual bedside behavior in the first place.

Observation was better suited to uncover tacit workflow steps, interruptions, and exception requirements that questionnaires and manager interviews missed.

Question 135

Topic: Needs Assessment

A BA is reviewing this draft needs-assessment note for a regional insurer:

Business need: New policy issuance is too slow, and brokers are frustrated.
Impact: We may be losing growth opportunities to faster competitors.
Status: Sponsor wants to use this statement as input to the business case this week.
Current package: No supporting metrics or voice-of-customer evidence is attached.

What is the most important improvement before this note is used?

• A. Add baseline issuance-time data, quote-loss trends, and broker feedback themes.
• B. Add a stakeholder list for underwriting, sales, and operations.
• C. Add high-level scope boundaries for products and channels.
• D. Add target turnaround goals and expected benefit measures.

Best answer: A

What this tests: Needs Assessment

Explanation: The note states a problem and possible impact, but it does not yet prove either one. Before using it to support a business case, the BA should add current-state quantitative and qualitative evidence that confirms the issue exists, how severe it is, and why it matters to stakeholders.

In needs assessment, the first priority is to validate the stated business problem or opportunity with evidence. This draft says policy issuance is slow and hurting growth, but without baseline data or stakeholder evidence, decision makers cannot tell whether the issue is significant, widespread, or only anecdotal.

The strongest improvement is to add evidence such as:

• average issuance cycle time
• trend data on quote or broker loss
• recurring themes from broker interviews or complaints

That combination gives both quantitative proof and qualitative context for the business case. Scope boundaries, target goals, and stakeholder lists are useful next, but they do not confirm that the stated problem is real and worth addressing.

The draft claims a business problem and impact, so it most needs quantitative and qualitative evidence that the problem is real and material.

Question 136

Topic: Planning

A health insurer is replacing its claims intake system. The BA team baselined requirements, controlled versions, and approved several requirement changes during delivery. In UAT, failed tests could not be tied to specific regulatory requirements, and the sponsor could not tell which delivered features still supported the original cycle-time reduction goal. Rework and repeated approval discussions followed. What is the most likely underlying BA gap?

• A. Stakeholder status communication about defects was insufficient
• B. Baseline sign-off was performed too early in the delivery cycle
• C. Missing trace links from requirements to objectives, acceptance criteria, and tests
• D. Inadequate elicitation technique selection for current-state pain points

Best answer: C

What this tests: Planning

Explanation: The core issue is a weak traceability strategy, not a lack of approvals or reporting. To monitor and validate requirements, the BA needs essential links from business objectives and regulatory drivers through requirements to acceptance criteria and test cases.

This scenario points to a traceability gap. The team already had baselines, version control, and approved changes, so the problem is not that requirements were unmanaged. The real failure is that people cannot see how a failed test affects a regulatory requirement or whether a delivered feature still supports the original business goal.

A fit-for-purpose traceability strategy should define links that let the team:

• connect requirements to business objectives or compliance drivers
• connect detailed requirements to acceptance criteria and test cases
• assess change impact across the lifecycle
• confirm that validated results support the intended value

When those links are missing, approval churn and rework increase because stakeholders must manually reconstruct impact and coverage. The closest distractors may improve communication or discovery, but they do not solve the inability to monitor and validate requirements end to end.

Without end-to-end trace links, the team cannot monitor change impact or validate that tested features still satisfy the approved business need.

Question 137

Topic: Traceability and Monitoring

A business analyst is maintaining the traceability matrix for a hybrid project implementing a new customer onboarding portal. A requirement to capture beneficial-owner data is traced to a regulatory objective and needed for UAT in 2 weeks. It has remained in “pending approval” for 10 business days because Legal and Sales disagree on the required fields. The requirements management plan states that unresolved cross-functional conflicts affecting release scope must be escalated within 2 business days, and design cannot proceed without an approved baseline. What should the BA do next?

• A. Ask the delivery team to build the Sales-preferred version now and confirm the details later
• B. Keep the requirement in pending approval and schedule more workshops until the stakeholders agree
• C. Mark the requirement as blocked pending decision, record the issue and impacts, and escalate through the defined governance path
• D. Remove the requirement from the release backlog and revisit it after go-live

Best answer: C

What this tests: Traceability and Monitoring

Explanation: This requirement is no longer just under review; it is stalled. Because the conflict threatens a time-sensitive, high-value requirement and the management plan defines an escalation trigger, the BA should update the status, document the blockage, and escalate to the appropriate decision-makers.

The core concept is recognizing when a requirement has stopped progressing through its lifecycle and requires formal clarification or escalation. Here, the requirement has remained unresolved beyond the escalation threshold, affects a regulatory objective, and cannot move into design without baseline approval. That means the BA should treat it as blocked or pending decision, capture the blocker and downstream impact in the traceability artifact, and communicate it through the defined governance path.

This action does three things:

• reflects the true lifecycle status
• preserves traceability and decision history
• gets the right authority involved before delivery is delayed further

Continuing informal discussion is too slow once the agreed escalation rule has already been met.

The requirement is clearly stalled, so the BA should update its lifecycle status, document the blocker and impacts, and escalate according to the agreed process.

Question 138

Topic: Planning

A BA is finalizing the requirements management plan for a claims platform replacement. The new platform must be supported by the IT service desk and operations team at go-live.

Exhibit: Draft stakeholder responsibilities

Which action is best supported by the exhibit?

• A. Add operations and service desk stakeholders for transition/support requirements.
• B. Move all baseline approvals to the lead BA.
• C. Remove the compliance manager to avoid duplicate approvals.
• D. Assign the QA lead to prioritize feature requirements.

Best answer: A

What this tests: Planning

Explanation: The requirements management plan should clearly name the stakeholders, roles, and responsibilities for each requirement type. Because transition and support needs are unassigned, the BA should add the operational stakeholders who will define, review, and approve those requirements before the plan is finalized.

The core issue is incomplete stakeholder coverage in the requirements management plan. A good plan does not just describe how requirements will be handled; it also identifies who is responsible for defining, reviewing, approving, and managing each major requirement category. Here, business, priority, regulatory, and test-related responsibilities are assigned, but transition and support requirements have no owner or approver even though service desk and operations readiness is required at go-live.

That gap should be closed by adding the operations and service desk stakeholders with clear responsibilities for eliciting, validating, and approving transition/support requirements. Reassigning approvals to the BA or QA lead would misuse those roles, and removing compliance would weaken governance for regulatory requirements. The best interpretation is to fill the missing stakeholder and responsibility assignment, not to restructure unrelated roles.

The exhibit shows an unassigned requirement area, so the plan must identify stakeholders and approval responsibility for transition and support needs.

Question 139

Topic: Traceability and Monitoring

A business analyst is supporting a claims portal project. The requirements baseline was approved 3 weeks ago when the legal team requests a new consent timestamp field on claim submission to address a policy interpretation issue. The product owner wants the team to add it immediately, but the change control plan requires assessment of impacts, dependencies, and risks against the approved baseline before any change is approved. What should the business analyst do next?

• A. Update the requirements package and baseline, then notify stakeholders.
• B. Assess impact against the baseline and traceability, then recommend action.
• C. Get sponsor approval first, then analyze downstream effects.
• D. Ask developers to estimate and start design while approval is pending.

Best answer: B

What this tests: Traceability and Monitoring

Explanation: Once requirements are baselined, changes must be handled through the defined change control process. The best next step is to assess the request’s impact on the baseline, related artifacts, dependencies, and risks so decision-makers can approve or reject it with full information.

The core concept is controlled change after baselining. A baseline should not be changed simply because a new request seems important or urgent. The business analyst should first compare the requested consent field to the approved requirements baseline, trace related processes, rules, interfaces, test assets, and downstream dependencies, and assess delivery and business risks.

A sound next step is to:

• document the change request
• analyze impact, dependencies, and risks
• determine affected requirements and artifacts
• provide a recommendation for formal approval

Only after the change is reviewed and approved under the change control plan should the requirements package and baseline be updated. Starting design or getting approval before analysis weakens control and can damage traceability.

This preserves baseline integrity by evaluating the requested change through formal impact analysis before any approval or update occurs.

Question 140

Topic: Needs Assessment

A retailer is replacing its call-center order entry screen. Sales agents helped define the workflow, and managers approved the requirements. During solution readiness review, the service desk and infrastructure team say they were never consulted: the new screen creates alerts they cannot diagnose, needs new password-reset procedures, and requires updated support articles. Launch is delayed while new requirements are added. What is the most likely underlying BA gap?

• A. Decision-makers were not authorized to approve the baseline.
• B. Support groups were not identified and engaged early.
• C. Regulators were not consulted on mandatory compliance controls.
• D. End users were not adequately involved in workflow elicitation.

Best answer: B

What this tests: Needs Assessment

Explanation: The key clue is that the solution workflow was already defined with sales agents and approved by managers, yet launch is blocked by unresolved support needs. That points to a stakeholder identification gap involving support groups, not end-user workflow input, approval authority, or compliance review.

This scenario tests stakeholder identification in needs assessment. The business process users and managers were involved, so the main workflow and approvals were covered. The late discovery of monitoring, password-reset, and knowledge article needs shows the BA did not identify operational support stakeholders who must maintain and support the solution after launch.

Support groups often surface nonfunctional, transition, and operational readiness requirements such as incident handling, access support, monitoring, support documentation, and handoff procedures. When they are missed, teams often see late rework and launch delays even if business users are satisfied. The closest distractor is weak end-user involvement, but the stem specifically shows user workflow input was already obtained.

The rework is driven by missed operational support needs, which indicates the BA failed to include support groups as stakeholders early.

Question 141

Topic: Needs Assessment

A BA is reviewing draft product goals for a bank’s new account-opening solution. The sponsor asks whether the draft is aligned with the approved business case.

Exhibit: Business case excerpt

Which interpretation is best supported by the exhibit?

• A. Remove automated document checks because compliance is outside product scope.
• B. Postpone abandonment tracking until after the first release is deployed.
• C. Revise the mandatory live video goal to a risk-based review step.
• D. Expand prepopulation to all applicants before approving the goals.

Best answer: C

What this tests: Needs Assessment

Explanation: The exhibit shows one draft product goal that works against the stated organizational objectives. A mandatory live video session for every applicant adds manual work and customer friction, so the BA should challenge that goal and seek an approach that supports compliance without undermining digital adoption and cost reduction.

In needs assessment, the BA helps ensure product goals support the business case and organizational objectives. Here, prepopulation supports easier digital onboarding, automated document checks support compliance, and abandonment tracking supports the objective of understanding drop-off causes. The clear misalignment is the requirement that every applicant complete a live video session with a branch specialist. That introduces a manual handoff, increases effort per account, and makes the process less digital, which conflicts with the goals to increase digital account opening and reduce onboarding cost.

A stronger aligned goal would keep reviews targeted, such as using risk-based escalation only when automated checks detect exceptions. The BA should surface that conflict before goals are finalized rather than accept a blanket activity that weakens the value proposition.

Requiring every applicant to use a specialist adds friction and manual effort, conflicting with the digital-adoption and cost-reduction objectives.

Question 142

Topic: Evaluation

During final evaluation of a claims workflow solution, the business analyst compares the baselined requirements, UAT results, and defect log. One gap remains: supervisor alerts were required to refresh every 15 minutes, but the built solution refreshes every 30 minutes. Correcting it now would delay deployment by 3 weeks. Pilot users still met cycle-time and compliance targets, and supervisors can manually refresh alerts during peak periods. The sponsor will approve go-live only if the risk is controlled and ownership is explicit. What should the business analyst recommend?

• A. Remove the refresh requirement from the baseline.
• B. Correct the discrepancy before deployment.
• C. Accept the discrepancy with conditions for go-live.
• D. Defer the discrepancy to a future release.

Best answer: C

What this tests: Evaluation

Explanation: This discrepancy should be accepted with conditions, not ignored or automatically fixed. The solution is meeting business and compliance outcomes, but the remaining gap still creates operational risk, so go-live needs explicit controls, ownership, and sign-off.

In evaluation, the business analyst should recommend discrepancy treatment based on business impact, acceptance criteria, and deployment risk. Here, the developed solution does not fully match the stated requirement, but the evidence shows that key business metrics and compliance targets are still being achieved. Because a manual workaround exists and the sponsor is willing to proceed only with controlled risk, the best recommendation is conditional acceptance.

That typically means:

• document the gap and temporary operating procedure
• assign an owner for monitoring impact after go-live
• obtain stakeholder sign-off on the residual risk
• plan follow-up correction if conditions are no longer met

Immediate correction is stronger than necessary, while simple deferral is too weak because the sponsor requires explicit controls before release.

A conditional acceptance fits because the gap does not currently block value or compliance, but it still requires a documented workaround, monitoring, and formal stakeholder approval.

Question 143

Topic: Evaluation

A business analyst is preparing a validation summary for stakeholders after user acceptance testing of a new claims workflow. The test report shows a 94% pass rate and four open defects, and the sponsor asks whether the solution satisfies requirements and can move forward. Before communicating a recommendation, what should the business analyst obtain first?

• A. A developer estimate for when the open defects will be fixed
• B. The approved acceptance criteria traced to the failed tests and open defects
• C. The sponsor’s preferred level of risk for release
• D. A new round of testing focused on the failed scenarios

Best answer: B

What this tests: Evaluation

Explanation: The first need is to connect the test evidence to the approved acceptance criteria. A pass rate and defect count alone do not tell stakeholders whether unmet items affect mandatory requirements, so the analyst needs traceability before communicating a recommendation.

In solution evaluation, validation findings must be communicated in a way that lets stakeholders decide whether the solution satisfies requirements. That means the analyst should first verify the basis for that decision: the approved acceptance criteria and how failed tests or open defects map to those criteria. Without that comparison, summary metrics such as overall pass rate can be misleading because a small number of failures may still block acceptance if they affect critical or regulatory requirements.

A sound sequence is:

• confirm the approved acceptance criteria
• trace failed tests and defects to requirements
• summarize which criteria are met, unmet, or at risk
• present that impact so stakeholders can make the acceptance decision

Timing, rework, and release risk matter, but they come after establishing whether the current evidence shows the solution meets the stated requirements.

Stakeholders can only judge solution acceptability when the reported test results are explicitly compared with the approved requirement acceptance criteria.

Question 144

Topic: Analysis

A business analyst is defining requirements for a claims-processing solution involving operations, underwriting, compliance, and IT. All key stakeholder groups participated in elicitation, but the BA asked everyone to approve the entire requirements package in one final review. Process requirements were tentatively accepted, then later reopened when compliance reviewed business rules and operations saw interface details. Version churn and rework increased with each review cycle. What is the most likely underlying BA gap?

• A. No plan for staged sign-off at logical baseline points
• B. The requirements traceability artifact was not detailed enough
• C. The stakeholder list omitted critical business areas
• D. The team failed to enforce change control after baseline

Best answer: A

What this tests: Analysis

Explanation: The main issue is not missing stakeholders or weak documentation; it is the approval approach. When different groups own different decisions and review requirements at different levels of detail, staged sign-off is more appropriate than a single approval event.

This scenario points to a sign-off strategy problem. The stakeholders were identified and involved, but the BA treated approval as one large event after the full package was assembled. Because process requirements, business rules, and interface details mature at different times and are owned by different stakeholders, a single approval point caused late discoveries, reopened decisions, and repeated rework.

A stronger approach is to baseline and obtain approval in stages, such as:

• process requirements with process owners
• business rules with compliance and policy owners
• detailed interface requirements with operational and technical reviewers

Staged sign-off reduces approval churn by matching each decision to the right stakeholders and the right level of requirement maturity. Traceability and change control still matter, but they do not best explain why approvals keep being reopened before a stable baseline is reached.

The approvals are cycling because different stakeholder groups should have been asked to sign off in stages as requirements reached the right level of maturity.

Question 145

Topic: Analysis

A business analyst is helping prioritize requirements for the first release of a supplier onboarding portal. Stakeholders proposed four high-level features, but the delivery team can only build two before a contract-driven launch date. The sponsor asks which requirements should be accepted now and which should be deferred or rejected. The backlog has no prioritization criteria, benefit statements, or rationale. What should the BA verify first before making a recommendation?

• A. Detailed effort estimates for all proposed requirements
• B. Prototype feedback from a sample of end users
• C. A comparison of each requirement’s value, urgency, dependencies, and effort
• D. Formal sign-off on the current high-level backlog

Best answer: C

What this tests: Analysis

Explanation: Before accepting, deferring, or rejecting requirements, the BA needs objective prioritization information that combines value with constraints. Since the backlog lacks criteria and rationale, the first step is to obtain a comparative view of each requirement’s expected benefit and limiting factors.

The core concept is requirements evaluation through valuation and constraint analysis. A BA cannot make a sound accept/defer/reject recommendation from a list of high-level requests alone. The first thing to verify is how each requirement contributes to business value and how each is affected by constraints such as urgency, dependencies, and implementation effort.

That comparison creates an evidence-based basis for prioritization, for example:

• expected business outcome or benefit
• time sensitivity or contractual urgency
• dependencies or sequencing limits
• effort or capacity impact

Detailed estimates alone are too narrow because they address effort without showing value. Sign-off is premature when the backlog has not been evaluated. Prototype feedback may help refine usability but does not resolve which requirements best fit value and constraint tradeoffs.

This gives the BA the minimum decision basis needed to judge each requirement against both business value and delivery constraints.

Question 146

Topic: Planning

Two weeks before a fixed quarter-end release, a compliance manager requests a new requirement: sales orders above 20% discount must route to both regional and finance approval. The requirements baseline was signed off last month, and the current solution already supports one manager approval. Which impact criteria should the business analyst evaluate before the change is approved?

• A. Alignment to compliance need, impacts on related requirements and test assets, affected stakeholders and operations, and resulting cost, schedule, and release risk
• B. Development effort, remaining contingency budget, and whether overtime can preserve the release date
• C. Workflow tool feasibility, number of screens affected, and the current defect rate
• D. Sales leadership support, expected user satisfaction, and whether customers will notice the change

Best answer: A

What this tests: Planning

Explanation: Before approving a baselined requirement change, the BA should assess more than delivery effort. In this scenario, the request has a compliance driver and a fixed release date, so the decision must consider business justification, downstream requirement and test impacts, stakeholder and operational effects, and schedule/cost/risk tradeoffs.

The core concept is requirements change impact analysis. Before a change is approved, the BA should evaluate whether the change supports the business objective or compliance need, what existing requirements, rules, designs, test cases, and acceptance criteria it affects, which stakeholders and operational areas are impacted, and what the change does to cost, schedule, resources, and delivery risk. Because this request modifies an already baselined approval rule close to release, approval cannot rest on feasibility or effort alone.

A sound review typically covers:

• business value or obligation
• downstream traceability impacts
• stakeholder and transition impacts
• implementation risk and release constraints

The closest distractor is the effort-and-budget view, but that is only one slice of the approval decision.

A change approval decision should be based on full impact analysis across business value, traceability, stakeholder effects, and delivery consequences.

Question 147

Topic: Planning

A retailer has approved a project to launch curbside pickup before the holiday season. The BA has five days to prepare the business analysis plan. The business case says the initiative will “improve customer convenience” and “support growth,” identifies a mobile app and parking sensors as likely solution components, assumes store staff can absorb new pickup tasks, and names only the digital commerce director as sponsor. Store operations, fulfillment, and finance will be consulted after initial planning. Which concern should the BA prioritize first because it creates the greatest risk to effective business analysis planning?

• A. Clarify measurable business objectives and success criteria.
• B. Confirm whether parking sensors are in scope.
• C. Test the staffing assumption with store operations.
• D. Schedule finance for the first elicitation round.

Best answer: A

What this tests: Planning

Explanation: The biggest planning risk is the business case’s vague objectives. Without clear, measurable outcomes, the BA cannot properly tailor scope, prioritize stakeholders and requirements, or define the right analysis and validation approach. The other concerns are real, but they are narrower than the missing value definition.

Reviewing the business case is supposed to give the BA enough context to plan business analysis work. In this scenario, the stated benefits are too vague: “improve customer convenience” and “support growth” do not define what success looks like, how it will be measured, or which needs should drive requirements. That weakness affects nearly every planning decision, including stakeholder focus, elicitation depth, prioritization criteria, traceability, and acceptance planning.

By clarifying measurable objectives first, the BA creates a basis for evaluating the staffing assumption, judging whether proposed solution components matter, and deciding which stakeholders must be engaged early. The other concerns are valid, but they are secondary because they can be planned more effectively once the business value and success measures are explicit.

The key takeaway is that weak business objectives create a planning risk that is broader than any single scope, assumption, or stakeholder issue.

Vague objectives create the broadest planning risk because the BA cannot align scope, stakeholder engagement, prioritization, or validation without measurable outcomes.

Question 148

Topic: Evaluation

A bank deployed an automated loan approval workflow to reduce approval time by 30% and manual reviews by 40%. In the first quarter after go-live, approval time improved by only 5% and manual reviews increased, so executives say the solution is not delivering value. However, during that same quarter, a temporary bank-wide fraud policy required extra manual checks for all loan applications, including branch applications still using the old process. What is the most likely underlying BA gap?

• A. The operations team needs more training on the new workflow.
• B. The requirements baseline was not formally approved before deployment.
• C. The requirements package omitted needed fraud-review steps.
• D. The evaluation did not isolate external policy effects from solution performance.

Best answer: D

What this tests: Evaluation

Explanation: The main issue is not necessarily that the deployed solution failed, but that its value was judged using distorted results. Since a temporary fraud policy affected all channels, the BA should separate that external influence before concluding the solution missed its business case.

This is an evaluation problem: apparent underperformance may be caused by an external factor rather than by the deployed solution itself. The key clue is that the temporary fraud policy increased manual checks for all loan applications, including those still using the old branch process. That means the post-deployment metrics were influenced by a broader operating condition, so comparing raw results to the original business case overstates the solution gap.

A sound BA evaluation would adjust for the external policy change by using normalized measures, trend comparisons, or a control comparison with unaffected periods or channels. The goal is to determine how much of the outcome came from the solution versus from outside forces. The closest distractors focus on process or requirements defects, but the stem’s cross-channel impact points first to distorted valuation, not a solution design failure.

Because the temporary fraud policy affected both the new and old processes, raw post-deployment results alone do not show the solution’s true value.

Question 149

Topic: Analysis

A business analyst is helping leaders choose Phase 1 capabilities for a customer self-service portal. Sales wants cross-sell prompts, operations wants call deflection, and compliance wants consent capture. After two review cycles, accepted capabilities were replaced, user stories were rewritten twice, and stakeholders said the shortlist “doesn’t reflect what matters most.” The team already has a capability list, estimates, and active stakeholder participation, but each decision meeting uses different reasons to rank options. What is the most likely underlying BA gap?

• A. Requirements were too detailed for early prioritization
• B. No agreed decision criteria were applied consistently
• C. Stakeholders were not sufficiently engaged in reviews
• D. Requirements changes were not recorded in a change log

Best answer: B

What this tests: Analysis

Explanation: The core problem is inconsistent evaluation, not missing participation or missing documentation. When stakeholders favor different capabilities, the BA should use agreed decision criteria consistently so options are compared on the same basis each time.

This scenario points to a prioritization and option-evaluation gap. The team already has candidate capabilities, estimates, and stakeholder participation, but decisions keep changing because each meeting uses different reasons to judge value. That means the BA has not established and applied a common set of decision criteria, such as business value, risk reduction, compliance necessity, customer impact, or implementation effort.

Using consistent criteria helps stakeholders compare competing capabilities objectively, reduces approval churn, and makes accepted, deferred, or rejected requirements easier to justify. It also creates transparency when different stakeholder groups value different outcomes. A change log or more documentation may help track decisions, but those tools do not solve the underlying problem if the basis for comparison keeps shifting.

The churn is driven by evaluating the same capabilities with changing priorities instead of using a shared, consistent decision framework.

Question 150

Topic: Needs Assessment

A business analyst is supporting a customer-service modernization initiative. The executive sponsor wants a premium self-service feature set, operations managers want faster handling time, and the organization’s strategy emphasizes cost reduction through platform standardization. During needs assessment, which action should the business analyst AVOID to align goals, objectives, and solution scope?

• A. Keep all stakeholder requests in scope until delivery decides trade-offs
• B. Recommend phased scope for strategic essentials and optional enhancements
• C. Reconfirm business objectives, measures, and constraints with all groups
• D. Compare scope options using criteria tied to strategy and value

Best answer: A

What this tests: Needs Assessment

Explanation: When stakeholder priorities conflict, the BA should make trade-offs explicit by clarifying the business need, success measures, and scope boundaries. Keeping every request in scope to avoid conflict is an anti-pattern because it delays alignment instead of supporting it.

The key concept is that alignment means helping stakeholders connect solution scope to the business need and organizational strategy, even when their preferences differ. In needs assessment, the BA should clarify goals, expected value, measures of success, and constraints, then use that information to evaluate scope choices. Reconfirming objectives across stakeholder groups is appropriate because it exposes real differences. Using strategy-based criteria is appropriate because it creates an objective basis for comparing options. Recommending a phased scope is also acceptable when it preserves strategically necessary outcomes while deferring lower-value items. Deferring trade-offs by keeping everything in scope creates ambiguity and increases the risk of building a solution that satisfies requests but misses strategic intent.

Leaving every request in scope postpones alignment and prevents the solution scope from being clarified against business objectives and strategy.

Questions 151-175

Question 151

Topic: Planning

During requirements workshops for a hybrid CRM upgrade, the sales director, compliance lead, and product owner each make conflicting decisions about which requirements are mandatory. The sponsor asks the business analyst to update the requirements management plan so future decisions are handled consistently. Before defining the plan’s approval rules, what should the business analyst verify first?

• A. Who has final approval authority and conflict escalation rights
• B. How requirements will be prioritized into releases
• C. Which elicitation technique each stakeholder prefers
• D. What repository and versioning tool the team will use

Best answer: A

What this tests: Planning

Explanation: The first clarification is the governance structure for requirements decisions. When stakeholders conflict, the requirements management plan must define who can approve, who can decide, and how unresolved disagreements are escalated so decisions stay consistent.

This question is about requirements governance in the requirements management plan. When multiple stakeholders are making competing decisions, the BA should first clarify decision authority: who can approve requirements, who can resolve conflicts, and what escalation path applies if agreement is not reached. Those governance rules create consistency across elicitation, analysis, approval, and change control.

Without clear decision rights, other planning details such as elicitation methods, release prioritization, or tools may improve execution but will not prevent contradictory decisions. In this scenario, the core problem is not lack of information capture; it is lack of an agreed rule for making and enforcing requirements decisions. The closest distractor is prioritization, but prioritization still depends on knowing whose judgment is binding.

Consistent requirements decisions depend first on clear decision rights, approval authority, and escalation paths among stakeholders.

Question 152

Topic: Needs Assessment

A business case and weighted criteria matrix identified a customer portal enhancement as the preferred initiative over outsourcing and process redesign. Before approval, the business analyst discovers a new privacy compliance requirement and an integration dependency that affect the options differently. The original comparison package is already baselined. What should the business analyst do next to compare the options appropriately?

• A. Compare only the added compliance costs because the preferred initiative was already selected.
• B. Ask key stakeholders to choose again informally instead of revising the baselined analysis.
• C. Keep the original scores and add the new requirement as a project risk for later review.
• D. Perform impact analysis through trace links, update the criteria scores, and issue a new version of the comparison package.

Best answer: D

What this tests: Needs Assessment

Explanation: A weighted criteria matrix is the best valuation technique here because the new information affects multiple decision factors, not just cost. Since the original comparison was baselined, the business analyst should use traceability and impact analysis to update the evaluation in a controlled, versioned way.

When new information changes the assumptions behind an initiative comparison, the business analyst should reapply the valuation technique that fits the decision. In this case, a weighted criteria matrix is appropriate because the options are affected across several dimensions, such as compliance fit, integration dependency, risk, and value.

The disciplined approach is to:

• trace the new requirement and dependency to affected objectives and option assumptions
• perform impact analysis on each initiative option
• rescore the options using the agreed criteria and weights
• version the updated comparison package and seek a revised decision

This preserves traceability from business need to recommendation and respects baseline control. Treating the issue as a later risk, narrowing the review to cost only, or using informal stakeholder voting would weaken the value-based comparison.

This uses the appropriate valuation technique again with controlled baseline change, so the options are re-compared using updated traced impacts.

Question 153

Topic: Needs Assessment

A business analyst has completed a needs assessment for an insurer. The business need is to reduce claim-submission delays and customer abandonment. The proposed solution scope includes a self-service web/mobile intake, document upload, and status notifications, but excludes changes to claim adjudication. The sponsor drafts this project objective: “Implement a modern digital claims portal.” Before the charter is finalized, what should the business analyst do next?

• A. Obtain approval of the drafted objective and refine it later
• B. Create a traceability matrix from scope items to deliverables
• C. Begin detailed requirements elicitation for portal capabilities
• D. Facilitate definition of measurable objectives tied to in-scope outcomes

Best answer: D

What this tests: Needs Assessment

Explanation: The drafted statement describes a solution, not a project objective. Before charter approval or detailed analysis, the business analyst should work with stakeholders to convert the solution scope into specific, measurable outcomes that reflect the business need.

The key concept is translating solution scope into project objectives that are outcome-focused, not feature-focused. “Implement a modern digital claims portal” says what will be built, but it does not define the business result the project is expected to achieve. Since the needs assessment already identified the problem and clarified scope boundaries, the next step is to collaborate with stakeholders to define measurable objectives and success criteria for the in-scope outcomes.

Examples would include reducing average claim-submission time, lowering abandonment rates, or increasing completed digital submissions for the channels included in scope. Those objectives help align the charter, guide later requirements work, and provide a basis for evaluating value. Starting requirements, approvals, or traceability first would move forward without clear outcome targets.

This is correct because the next step is to turn the feature-oriented scope into specific, outcome-focused objectives and success measures.

Question 154

Topic: Analysis

A business analyst is elaborating requirements for a customer self-service portal. Operations requested that shipment status update in real time. During interface analysis, the logistics provider confirms that, for this release, status data can be sent only every 4 hours. The requirement package is still under review and has not been baselined. What should the business analyst do next?

• A. Ask the development team to build a custom workaround to preserve the original request
• B. Baseline the real-time requirement and track the limitation as a risk
• C. Facilitate a gap review, assess feasible options, and revise the requirement and acceptance criteria
• D. Add the issue to the traceability matrix and revisit it during user acceptance testing

Best answer: C

What this tests: Analysis

Explanation: When analysis shows that a requested capability is not feasible, the BA should not baseline or defer the issue. The best next step is to make the gap explicit, work with stakeholders to evaluate realistic options, and adjust the requirement package and acceptance criteria accordingly.

The core concept is recognizing a gap between stakeholder desire and feasible product capability during analysis, then resolving that gap before requirements are finalized. Here, interface analysis has already shown that real-time updates are not possible in this release because the external provider only supports 4-hour data transfers. That means the original request cannot simply move forward unchanged.

The BA should now:

• confirm the impact of the constraint with relevant stakeholders
• evaluate realistic product options or tradeoffs
• revise the requirement, rationale, and acceptance criteria to reflect the agreed capability
• prepare the updated requirement package for review and baseline

This is stronger than simply recording the issue, because the requirement itself is currently misaligned with what can actually be delivered.

Analysis has exposed a capability gap, so the next step is to collaborate on feasible options and update the requirement before baselining.

Question 155

Topic: Traceability and Monitoring

A business analyst sends a weekly 20-page requirements log for 180 requirements. The log lists IDs, owners, and last update dates, but project stakeholders still miss pending approvals, high-impact changes, and requirements blocked by external dependencies until rework is already needed. What is the most likely underlying BA gap?

• A. The requirements were documented with too much detail for the delivery team.
• B. The project has accepted too many requirement changes before scope was frozen.
• C. The status reporting lacks visual or summary indicators that emphasize exceptions, risks, and decisions needed.
• D. The BA is holding stakeholder review meetings too infrequently.

Best answer: C

What this tests: Traceability and Monitoring

Explanation: The core issue is not the existence of status data, but how it is communicated. PMI-PBA reporting should help stakeholders quickly see the most important requirements signals, such as approvals at risk, blocked items, high-impact changes, and decisions needing escalation.

This scenario points to a communication gap in requirements monitoring. The BA is providing raw status data, but stakeholders are still missing the items that matter most until rework occurs. That means the reporting method is not surfacing the critical signals through concise summaries, visual indicators, or exception-based views tailored to stakeholder needs.

Effective requirements status communication should make it easy to spot:

• requirements awaiting approval
• changed requirements with impact
• blocked or at-risk items
• decisions or escalations needed

A detailed log can still exist as a supporting artifact, but leaders usually need a dashboard-style summary or prioritized status view. The closest distractors focus on symptoms or secondary process issues, while the main clue is that important status information exists but is not being highlighted.

A long log without highlighted status signals does not help stakeholders quickly identify the requirements issues that need action.

Question 156

Topic: Planning

A BA supports a new loan-origination workflow. One requirement states that branch staff must issue a credit decision for standard applications within 15 minutes. During the pilot, reports show 98% training completion, 120 defects closed, and 1,400 applications processed. Even so, operations managers keep rejecting sign-off because they cannot tell whether the solution actually meets the requirement, leading to review churn and rework. What is the most likely underlying BA gap?

• A. The pilot processed an insufficient number of applications.
• B. Too few stakeholders participated in defect triage meetings.
• C. No metric directly measures decision time against the 15-minute requirement.
• D. Pilot reports lacked formal document version control.

Best answer: C

What this tests: Planning

Explanation: The problem is not missing effort data; it is missing the right evaluation metric. When a requirement sets a performance target, the BA must define a business metric and acceptance criteria that directly show whether that target is being achieved.

This scenario points to a gap in metric definition, not in delivery activity. The requirement is explicit: standard applications must receive a credit decision within 15 minutes. But the pilot reports only show training completion, defects closed, and volume processed. Those measures may be useful for readiness and quality tracking, yet they do not confirm whether the solution satisfies the requirement itself.

A sound BA approach is to define a business metric and acceptance criteria that directly map to the requirement, such as average or percentage of standard applications decided within 15 minutes. Without that linkage, stakeholders cannot objectively approve the solution, which leads to sign-off churn and rework. The closest distractors address process issues, but the key clue is the inability to tell whether the requirement was met.

The team is tracking activity and quality measures, but not the requirement-specific business metric needed to evaluate whether the solution meets the stated target.

Question 157

Topic: Traceability and Monitoring

A business analyst on a hybrid CRM project has already baselined requirements. During a sprint review, sales requests a new approval rule, but compliance says it conflicts with an existing regulatory reporting requirement. The traceability matrix shows the proposed change would affect six user stories and could delay UAT. The requirements management plan states that significant requirement impacts must be communicated promptly to the project manager and affected stakeholders using a concise status summary with impact, risk, and decision needed.

What should the business analyst do next?

• A. Finish all downstream impact updates before reporting anything
• B. Request sponsor approval for the new rule immediately
• C. Log the conflict and wait for the next status meeting
• D. Send a concise impact and risk status update to stakeholders

Best answer: D

What this tests: Traceability and Monitoring

Explanation: The best next step is to communicate the requirements issue promptly using the agreed method in the requirements management plan. The BA already knows there is a conflict, identified impacts, and schedule risk, so stakeholders need a clear status summary to support timely decisions.

This tests requirements status communication in traceability and monitoring. Once the BA has enough information to state the issue, affected items, and risk, the next action is not approval or more delay; it is targeted communication to the project manager and affected stakeholders in the agreed format. That communication should be concise and decision-oriented: what changed, what conflicts, what is impacted, what risk exists, and what action or decision is needed.

A strong status update here would include:

• the conflicting requirement and requested change
• the traced impacts to user stories and UAT
• the delivery or compliance risk
• the decision or follow-up needed from stakeholders

Waiting for complete downstream updates or the next routine meeting weakens control, while seeking approval before informing stakeholders skips necessary communication and analysis context.

This follows the defined communication approach and informs decision makers promptly about the conflict, affected requirements, risk, and needed action.

Question 158

Topic: Needs Assessment

A business analyst is preparing a needs assessment for a retailer’s new online returns solution. A draft requirements package note says:

Business need: Reduce average return resolution time from 8 days to 3 days.
Stakeholders to involve: VP of Digital Commerce, Product Manager,
Enterprise Architect, Integration Lead, Security Analyst.
Planned workshops: solution scope, interface needs, and approval flow.
Current-state note: Store associates receive returns, warehouse teams inspect items,
and finance issues customer credits.

What is the most important improvement before using this package to plan elicitation?

• A. Add more detail on interface performance requirements
• B. Add a customer survey to confirm the target cycle time
• C. Add a version number and document control owner
• D. Add operational stakeholders who perform return handling and credit processing

Best answer: D

What this tests: Needs Assessment

Explanation: The draft note identifies business and technical stakeholders, but it leaves out operational groups that actually receive returns, inspect items, and issue credits. In needs assessment, stakeholder representation must cover business, operational, and technical perspectives so the real process, constraints, and value expectations are understood early.

The core issue is stakeholder imbalance. The note already lists business decision-makers and technical specialists, but the current-state summary shows that store associates, warehouse teams, and finance staff carry out the work that the new solution will change. If those operational stakeholders are missing, elicitation may miss exception paths, handoffs, policy workarounds, and readiness concerns.

A sound stakeholder set for needs assessment should represent:

• business value and priorities
• operational execution and process realities
• technical feasibility and constraints

Document control, performance detail, and customer input can all matter, but they are secondary until the right stakeholder groups are represented. The closest distractor improves package quality, not stakeholder coverage.

The package is unbalanced because it names business and technical roles but omits operational roles that execute the process and know day-to-day constraints.

Question 159

Topic: Analysis

A retailer wants a holiday release for curbside returns. The sponsor provides one high-level requirement: “Store associates must process any online return in under 2 minutes while enforcing refund policy checks.” Build starts next sprint. Operations, fraud, and POS teams all need changes, and QA says the requirement is too broad to test. To create smaller, testable requirements while managing delivery risk, what should the BA do first?

• A. Split the requirement by team ownership so each group can define its own changes independently.
• B. Decompose the return flow into process steps, decision rules, data and interface needs, and acceptance criteria for each step.
• C. Keep one user story and let QA derive detailed test conditions during sprint planning.
• D. Define only the fastest happy-path return and defer policy exceptions until later.

Best answer: B

What this tests: Analysis

Explanation: The best choice is to decompose the high-level requirement by business process and decision points, then add rules, data, interfaces, and acceptance criteria. That turns a broad statement into smaller components that are testable and usable by multiple teams before development begins.

Requirement decomposition should convert a broad need into smaller components that can be analyzed, built, and tested. In this case, the key constraints are cross-team dependencies, policy risk, and QA’s inability to verify the requirement as written. Breaking the requirement into process steps such as identify return, validate purchase, apply refund rules, and complete the refund—while specifying the needed data, interfaces, business rules, and acceptance criteria for each step—creates testable requirements and reveals dependencies early.

This approach best balances value and risk because it preserves the end-to-end business outcome while making compliance-related checks explicit. Decomposing by organizational ownership, focusing only on the happy path, or postponing detail until sprint planning may feel faster, but each leaves important behavior unclear and increases rework or coverage gaps.

This creates discrete, verifiable requirements across the end-to-end process and exposes the policy and system dependencies QA and delivery teams must test.

Question 160

Topic: Analysis

A retailer is replacing its order-entry system. The business analyst documented requirements from sales managers and obtained sponsor approval. During each sprint demo, customer service representatives identify missing fields, incorrect validation rules, and screen flows that do not match how orders are actually entered. The developers show that they built exactly what the approved requirements described, yet rework continues and sign-off keeps slipping. What is the most likely underlying BA gap?

• A. Requirements were not prioritized well enough before development started.
• B. Requirements were not validated with prototypes, demos, or structured reviews involving actual users.
• C. Requirements changes were not routed through a formal change control process.
• D. Business value metrics were not defined in the business case.

Best answer: B

What this tests: Analysis

Explanation: The main issue is not that the team is changing direction; it is that approved requirements were incomplete and inaccurate for real users’ work. Using prototypes, demos, or document reviews earlier with customer service representatives would have exposed the missing fields, rules, and workflow gaps before build rework.

This scenario points to a requirements validation gap. The developers built to the approved requirements, but end users keep finding missing data, wrong business rules, and incorrect workflow behavior. That means the problem is upstream: the requirements were approved without being sufficiently checked for completeness and accuracy by the people who actually use the process.

Prototypes, demos, and structured document reviews are validation techniques used to confirm that documented requirements reflect real user needs and business rules before costly rework occurs. In this case, involving customer service representatives in those reviews would likely have revealed the gaps earlier. The closest distractor is change control, but the stem indicates the core need is not changing; the approved requirements themselves were deficient.

The repeated discovery of missing and incorrect details after approval indicates the requirements were not adequately validated for completeness and accuracy with the people who perform the work.

Question 161

Topic: Needs Assessment

A bank is assessing a proposal to automate customer onboarding with e-signature and automated fraud checks. The sponsor wants to speed up elicitation by inviting only sales managers and one product owner to the first workshop. The change will alter branch staff work, affect the IT service desk, require compliance review, and replace a step performed by an outsourced identity-verification vendor. Before finalizing the stakeholder list, what should the business analyst obtain FIRST?

• A. The expected benefits from the business case and target ROI
• B. The sponsor’s preferred list of experienced subject-matter experts
• C. Clarification of who will decide, use, support, regulate, or be externally affected by the new onboarding process
• D. The current organization chart for all departments involved

Best answer: C

What this tests: Needs Assessment

Explanation: The first step is to identify stakeholder categories based on how the change affects the future-state process. That means clarifying who has decision authority, who performs the work, who supports the solution, who governs compliance, and which external parties are impacted.

In needs assessment, stakeholder identification starts with understanding how the proposed change touches the business process and who must be represented, informed, or involved. The scenario already hints that several distinct stakeholder types may exist: decision-makers, end users such as branch staff, support groups such as the service desk, regulators or compliance reviewers, and affected external parties such as the outsourced vendor. Before scheduling workshops, the business analyst should first verify which groups fit those roles in this change and who has authority within them.

That clarification drives a complete stakeholder list and prevents early workshops from being biased toward managers or a narrow SME group. An org chart or business case can help later, but neither replaces identifying the affected stakeholder categories first.

This is the first information needed to distinguish the full stakeholder set and ensure the right parties are represented early.

Question 162

Topic: Analysis

A BA is helping select a workflow platform from three vendors. After each demo, different stakeholders favor a different product, and the decision is reopened repeatedly. Security and operations later identify important needs that were overlooked, while business managers keep re-ranking features based on personal preference. Requirements were documented, but there is no stable basis for accepting, deferring, or rejecting product capabilities. What is the most likely underlying BA gap?

• A. No change control process to stop stakeholders revisiting decisions
• B. No solution evaluation metrics for post-deployment benefits
• C. No formal baseline approval of all requirements before demos
• D. No agreed weighted criteria and decision method for option comparison

Best answer: D

What this tests: Analysis

Explanation: The problem is not missing documentation but missing structure for comparing alternatives. When stakeholders use personal preferences instead of agreed criteria and a decision-making technique, product decisions churn and important needs are inconsistently considered.

This scenario points to a gap in options analysis and valuation, not a downstream control issue. When a BA must help stakeholders accept, defer, or reject product capabilities across multiple vendors, the BA should define how options will be compared before decisions are made. That usually means agreed evaluation criteria, relative weighting, and a decision-making approach such as consensus building, multi-voting, Delphi, or a weighted decision matrix.

Without that structure:

• stakeholders revisit the same decision based on opinion
• different groups emphasize different factors each time
• important needs can be missed or inconsistently prioritized
• there is no defensible reason to accept one capability and defer another

A requirements baseline may help stabilize scope, but it does not by itself provide a fair method to compare alternatives. The key takeaway is that option-selection churn usually signals a missing or weak valuation and decision framework.

The team lacks a defined valuation framework and decision technique, so product choices are being driven by opinion instead of consistent option analysis.

Question 163

Topic: Traceability and Monitoring

During a steering review, stakeholders receive a status report showing that 9 of 25 high-priority requirements are marked implemented but have no passed validation evidence, and go-live is in two weeks. Stakeholders now question whether the solution is truly ready. What should the business analyst provide next to best support an informed decision?

• A. A traceability matrix linking requirements, acceptance criteria, test results, and open changes
• B. A summary of elicitation sessions completed and stakeholder attendance
• C. A version history of approved requirements documents
• D. The latest sprint burndown chart for the delivery team

Best answer: A

What this tests: Traceability and Monitoring

Explanation: When stakeholders are concerned about readiness, they need evidence that requirements have been fully traced through acceptance criteria and successful validation. A traceability matrix with test status and open changes directly shows whether high-priority requirements are ready for go-live.

The key concept is communicating requirements status with evidence that supports decision-making, not just reporting activity. Here, the concern is solution readiness: some high-priority requirements are implemented, but there is no passed validation evidence. The most useful follow-up is an end-to-end traceability view that connects each critical requirement to its acceptance criteria, test results, and any unresolved changes.

This lets stakeholders quickly determine:

• which high-priority requirements are truly validated
• where coverage or testing gaps remain
• whether open changes affect readiness or acceptance
• whether the reported risk is isolated or significant

Activity summaries, team progress measures, and document version history may be useful for management, but they do not prove that the delivered solution satisfies the required outcomes. In this situation, readiness must be validated with requirement-level traceability and test evidence.

This artifact best validates readiness because it shows whether critical requirements are fully covered, tested, and still affected by unresolved change.

Question 164

Topic: Analysis

A BA is recommending scope for release 1 of a customer self-service portal. The business case targets a 20% call-volume reduction within 3 months of launch. Release 1 has a fixed 12-week deadline, and operations can support only one new integration. Password reset, address change, searchable FAQ, and required audit logging can be delivered with existing platform capability in 8 weeks and low risk. Payment-method changes require a new payment integration, add 4 weeks, and carry high security-testing risk. Live chat adds 4 weeks and needs its own integration. Personalized offers add 3 weeks but have low impact on call reduction. Current call drivers are password resets 35%, address changes 25%, payment-method changes 15%, FAQs 15%, and promotional inquiries 10%. Which option set should the BA recommend for release 1?

• A. Password reset, address change, FAQ, and audit logging
• B. Password reset, address change, payment changes, and audit logging
• C. Payment changes, live chat, personalized offers, and audit logging
• D. Password reset, FAQ, live chat, and personalized offers

Best answer: A

What this tests: Analysis

Explanation: The best recommendation is the option that achieves the required business value with the least delivery and operational risk. Here, the existing platform capabilities already address the highest-volume call drivers and include mandatory audit logging, so adding risky integrations does not improve the decision enough to justify the tradeoff.

This tests requirements prioritization by balancing value, risk, and capability rather than simply choosing the largest feature set. The existing platform can deliver password reset, address change, FAQ, and audit logging in 8 weeks with low risk. Those capabilities address 35% + 25% + 15% = 75% of current call drivers, far above the 20% reduction target in the business case.

Adding payment changes or live chat would consume scarce integration capacity and increase implementation risk. Payment changes are especially risky because they add high security-testing exposure and use the full 12-week window. A sound BA recommendation is to accept the lowest-risk set that satisfies the business objective and defer lower-priority or higher-risk items to a later release.

The closest distractor is the package including payment changes, but it uses the full schedule for no meaningful advantage against the stated target.

This set exceeds the business-case target using existing capability, includes mandatory compliance, and avoids unnecessary integration risk.

Question 165

Topic: Analysis

A BA must define current-state requirements for a claims validation solution before a regulator audit in 4 weeks. Frontline adjusters work rotating shifts and cannot leave operations for long workshops. The insurer already has detailed SOPs, recent audit findings, and system transaction logs, but supervisors suspect staff use undocumented workarounds during peak periods. What is the BEST BA action?

• A. Interview a sample of adjusters about steps and exceptions.
• B. Run a supervisor workshop to define the current-state process.
• C. Analyze SOPs, audit reports, and logs, then observe claim handling.
• D. Survey all adjusters and rank the most frequent responses.

Best answer: C

What this tests: Analysis

Explanation: The best choice is to use the strongest available sources for accurate current-state information. Existing documents and logs give traceable evidence, while observation confirms whether undocumented workarounds are occurring in practice when stakeholder availability is limited.

A BA should select elicitation sources based on reliability, speed, and fit for the information needed. In this scenario, detailed SOPs, audit findings, and transaction logs already provide structured evidence of the intended and recorded process. Because supervisors suspect undocumented workarounds, observation is also important to confirm how work is actually performed.

Starting with interviews or workshops is less effective here because frontline staff have limited availability and recollections may be incomplete or biased. Surveys are even weaker for understanding step-by-step behavior, exceptions, and rationale. Reviewing existing artifacts and then observing real work gives the BA a faster, more accurate foundation for requirements and later targeted clarification. The closest distractor is the supervisor workshop, but it risks capturing policy views rather than actual practice.

Existing artifacts provide governed evidence quickly, and observation verifies whether actual work differs from documented policy.

Question 166

Topic: Analysis

A BA is reviewing four draft requirement packages before baselining acceptance criteria for a new customer portal. Which package still lacks enough detail to support meaningful measurement during validation?

• A. Password reset failures stay under 2% of weekly attempts.
• B. Duplicate invoices remain below 0.5% of monthly transactions.
• C. Staff can easily locate a customer record after training.
• D. Search completes within 2 seconds for 95% of peak-hour queries.

Best answer: C

What this tests: Analysis

Explanation: A requirement must be stated in a way that allows objective testing. The statement about staff being able to “easily” locate a record is too subjective because it does not define a measurable target such as time, accuracy, or success rate.

The key concept is measurability. A requirement supports meaningful evaluation only when it defines an observable result with enough detail to test it, typically including a metric, a target or threshold, and the context for measurement. In this scenario, the statement about staff being able to “easily” locate a customer record does not specify how success will be judged. Different stakeholders could interpret “easily” in different ways, making validation inconsistent.

The other statements are testable because they include quantifiable thresholds such as response time, error rate, or failure rate tied to a population or time period. A close distractor might seem incomplete if it does not mention a method, but it is still measurable because the expected result is objectively defined.

It uses subjective wording without a metric, threshold, or test condition, so the requirement cannot be measured consistently.

Question 167

Topic: Evaluation

Six months after a new CRM is deployed, the sponsor asks whether the investment delivered the promised value. The dashboard shows 94% user adoption, 97% training completion, and only 12 minor defects in hypercare. However, the business case expected a 10% increase in customer retention and faster renewal processing, and no one can show whether those outcomes improved. Which underlying BA gap most likely caused this situation?

• A. Failure to obtain formal approval of the finalized requirements package
• B. Failure to define and track outcome metrics against baseline and business case targets
• C. Failure to monitor defect counts during stabilization
• D. Failure to collect training completion evidence before go-live

Best answer: B

What this tests: Evaluation

Explanation: The key gap is the absence of valuation measures that show whether the deployed solution produced the intended business outcomes. Adoption, training, and low defects show readiness and quality, but they do not prove realized value against the business case.

In evaluation, realized value is shown by evidence that the solution improved the business outcomes it was funded to achieve. Here, the business case named retention and renewal speed, but the available evidence only reports operational or delivery-oriented indicators such as adoption, training completion, and defect counts. Those measures can support readiness and stability, yet they do not answer whether the organization gained the expected benefits.

The missing BA work is to define and track outcome-based metrics with a pre-deployment baseline and target values, then compare actual post-deployment results to those targets. Examples here would be customer retention rate and renewal cycle time before and after deployment. The closest distractors measure implementation health, not business value realization.

Realized value must be demonstrated with post-deployment business outcomes compared to the original baseline and expected benefits, not just delivery or adoption data.

Question 168

Topic: Planning

A manufacturer approved a project to reduce order-entry errors by 30% and shorten customer onboarding by two days. A newly assigned BA began eliciting requirements from each department’s wish list. After two review cycles, priorities keep changing, managers reject one another’s requests, and several drafted requirements improve convenience but do not support either business target. The BA proposes pausing elicitation to review the business case and project objectives with stakeholders. What is the most likely underlying BA gap?

• A. BA work lacked context from the business case and goals.
• B. Requirements change control was too weak.
• C. Acceptance testing was planned too early.
• D. Stakeholder reviews were rushed before consensus was built.

Best answer: A

What this tests: Planning

Explanation: The core problem is missing business context, not simply disagreement. Reviewing the business case and project objectives gives the BA a basis for elicitation, prioritization, and decision-making so requirements can be evaluated against expected benefits instead of departmental preferences.

Reviewing the business case and project goals is a planning activity that gives context for all later BA work. It clarifies the business problem, expected value, success measures, and scope boundaries. In this scenario, requirements are being proposed from local wish lists, and some do not support the approved outcomes of fewer errors and faster onboarding. That is why priorities keep shifting and approvals keep cycling: stakeholders do not have a shared basis for deciding what matters most.

Using the business case first helps the BA:

• focus elicitation on the business need
• prioritize requirements by expected value
• define acceptance criteria tied to outcomes
• reduce rework from low-value requests

Stronger controls or longer reviews may help administratively, but they do not fix the missing alignment to the approved business objectives.

Without grounding BA activities in the business case and objectives, the team cannot judge which requirements support the intended value and success targets.

Question 169

Topic: Analysis

A BA is reviewing draft requirements for a new shipping portal before the requirements package is finalized. The BA wants to clarify the requirement with the greatest downstream dependency impact first.

Exhibit: Requirements excerpt

Which requirement should the BA clarify first?

• A. Hazardous shipment audit fields
• B. Packing label handling codes
• C. Carrier eligibility rules
• D. Order classification rules

Best answer: D

What this tests: Analysis

Explanation: Dependency analysis starts with the upstream requirement that controls several others. In the exhibit, order classification is still undefined and directly affects carrier eligibility, label handling codes, and hazardous-shipment audit data. Clarifying it first prevents rework in multiple dependent requirements.

The key concept is to resolve the requirement that acts as a prerequisite for other requirements. Here, the classification of an order as standard or hazardous is an unresolved business rule, and three other requirements explicitly depend on it. Until that rule is clarified, the BA cannot confidently elaborate which carriers are allowed, what handling codes must appear on labels, or which additional audit fields are needed for hazardous shipments.

A practical dependency-analysis approach is:

• Identify the unresolved requirement.
• Check which other requirements reference or rely on it.
• Clarify the controlling requirement first.
• Then elaborate the dependent details.

Clarifying a downstream item first would risk rework because its content may change once the classification logic is defined.

This is the unresolved upstream business rule that drives several dependent requirements.

Question 170

Topic: Needs Assessment

A business analyst is supporting a pre-project assessment for a new customer onboarding process. Sales wants minimal data entry to speed conversions, compliance wants stronger controls, and operations wants fewer handoffs. The sponsor needs a credible baseline for prioritizing requirements within 2 weeks, and several tradeoffs must be discussed across these groups together. Which elicitation technique is best suited to uncover stakeholder values, priorities, and tradeoffs under these constraints?

• A. Facilitated workshop with key stakeholder representatives
• B. Individual interviews with each functional manager
• C. Enterprise-wide survey of affected employees
• D. Job shadowing of frontline onboarding staff

Best answer: A

What this tests: Needs Assessment

Explanation: When the goal is to reveal stakeholder values, priorities, and tradeoffs across groups, a facilitated workshop is usually the strongest choice. It enables direct comparison of competing needs and helps establish a shared baseline for prioritization within a short timeframe.

The core concept is matching the elicitation technique to the information needed. Here, the BA must uncover not just requirements, but the relative value each stakeholder group places on speed, control, and operational efficiency. Because the sponsor needs a prioritization baseline quickly and the tradeoffs must be discussed across groups together, a facilitated workshop is the best fit.

A workshop helps the BA:

• bring key stakeholders into one discussion
• surface conflicting priorities explicitly
• test tradeoffs in real time
• move toward shared prioritization criteria

Individual interviews provide depth but keep tradeoffs separated by stakeholder, while observation and surveys are weaker for negotiating relative value across conflicting interests.

A facilitated workshop is best because it exposes competing values in real time and helps stakeholders discuss and compare tradeoffs to form a prioritization baseline quickly.

Question 171

Topic: Analysis

After two prototype-based validation workshops, operations, compliance, and sales agree that most workflows meet the business need. The BA sends the sponsor 18 pages of chronological meeting notes, but the package does not show which requirements met acceptance criteria, which gaps remain, the impact of each gap, or whether approval or rework is recommended. The sponsor delays sign-off, and the delivery team starts unnecessary rework. What is the most likely underlying BA gap?

• A. Validation outcomes were not summarized into a decision-ready package.
• B. Each validation issue should have gone directly to formal change control.
• C. Prototype reviews should have been replaced by additional elicitation sessions.
• D. Key business stakeholder groups were missing from validation.

Best answer: A

What this tests: Analysis

Explanation: The sponsor cannot approve because the BA provided raw notes instead of a validation summary that clearly shows what passed, what failed, the business impact of gaps, and the recommended next action. Validation outcomes should be packaged to support a clear approval or rework decision.

The core concept is that validation is not complete when comments are merely captured; the BA must synthesize the outcomes into a form that supports a decision. Here, the right stakeholders participated and the prototype workshops produced useful feedback, but the output was a long chronological note set rather than a structured validation summary. A decision-ready summary should show which requirements were reviewed, whether each met acceptance criteria, what gaps or defects remain, the business impact of those gaps, and whether approval, rework, or further clarification is recommended. That helps the sponsor approve knowingly and prevents the team from reacting to raw comments with unnecessary rework. Formal change control may come later, but only after validation findings are analyzed and presented clearly.

The issue is not lack of validation activity, but failure to present results by requirement, gap, impact, and recommendation for approval or rework.

Question 172

Topic: Planning

A business analyst is defining evaluation metrics for a new supplier onboarding portal.

Exhibit: Requirements package excerpt

Requirement R-12:
Low-risk suppliers must be approved through the portal
in 1 business day or less.

Acceptance criteria:
- Required data fields are complete.
- No manual re-entry is needed.
- In pilot testing, 95% of low-risk applications are
  approved within 1 business day.

Based on the exhibit, which metric best reflects whether the solution meets the requirement?

• A. Average procurement team satisfaction score with the portal
• B. Percentage of low-risk applications approved within 1 business day
• C. Reduction in onboarding labor hours during the first month
• D. Number of suppliers registered in the portal each week

Best answer: B

What this tests: Planning

Explanation: The best metric is the one that directly measures the requirement as written. Here, the requirement and acceptance criteria both focus on how many low-risk supplier applications are approved within 1 business day, so that is the most valid measure of whether the solution meets the requirement.

A business metric should map directly to the requirement being evaluated, not just to a related benefit or general perception. In this exhibit, the requirement is about approval speed for a specific group: low-risk suppliers. The acceptance criteria make that measurable by setting a threshold of 95% approved within 1 business day.

That means the strongest metric uses the same elements:

• the same population: low-risk applications
• the same measure: approval completed
• the same time boundary: within 1 business day
• the same success threshold: 95%

Metrics such as registration volume, user satisfaction, or labor-hour reduction may still be useful, but they do not directly confirm that this requirement has been met. The key takeaway is to choose a metric that mirrors the requirement and its acceptance criteria as closely as possible.

It directly measures the same population, time target, and threshold stated in the requirement and acceptance criteria.

Question 173

Topic: Analysis

A sales director insists the new CRM must include AI lead scoring. In validation sessions, stakeholders debate dashboards and vendor brands, but the approved business case only states that qualified-lead conversion must improve and follow-up time must drop. Which artifact would best show whether stakeholders are validating the real requirement rather than a preferred solution?

• A. Signed feedback from the AI lead-scoring demo
• B. Baseline requirement with rationale and measurable outcome acceptance criteria
• C. Count of stakeholders favoring the AI feature
• D. Weighted matrix ranking lead-scoring vendors

Best answer: B

What this tests: Analysis

Explanation: The strongest evidence is an outcome-based requirement that includes business rationale and measurable acceptance criteria. That keeps validation focused on the need to improve conversion and response performance, not on whether stakeholders like AI lead scoring as a solution.

Requirements validation should confirm that a requirement is complete, accurate, and aligned to the business objective. In this scenario, the real need is improved qualified-lead conversion and faster follow-up. When stakeholders focus on dashboards, vendor brands, or enthusiasm for AI, they are validating a preferred solution, not the requirement itself.

A baseline requirement with rationale and measurable acceptance criteria makes the validation target explicit and solution-independent. It lets the BA ask whether the requirement is clear, testable, and tied to value, and whether AI scoring is truly necessary or just one possible way to meet it. A solution ranking or demo can be useful later, but only after the underlying requirement has been validated.

It validates the business need with measurable outcomes, so stakeholders assess whether any solution meets the requirement instead of defending AI scoring.

Question 174

Topic: Planning

A business analyst is reviewing a draft requirements management plan for a claims modernization project that will change policy, billing, and regulatory reporting processes. The draft already covers stakeholder approvals, weekly status reporting, a shared repository, and document version numbers.

Each requirement will have a unique ID, owner, priority, and status.
Statuses: Proposed, Approved, Implemented.
After approval, any requested change will be reviewed weekly by the sponsor and product manager.
Approved requirements documents will be stored in the repository with version history.

Before the plan is finalized, which gap is most material?

• A. Daily review meetings for all pending change requests
• B. Trace links from requirements to objectives, dependencies, solution components, and tests
• C. A stricter file-naming convention for requirements documents
• D. Additional statuses to separate deferred items from rejected items

Best answer: B

What this tests: Planning

Explanation: The draft plan addresses IDs, approvals, statuses, and version history, but it does not define how requirements will be traced across the lifecycle. For an integrated solution, that is the biggest gap because change decisions need impact analysis tied to objectives, dependencies, components, and tests.

The core concept is that a requirements management plan must define the traceability strategy used to manage baselined requirements and evaluate change. In this scenario, the plan already includes basic control elements such as unique IDs, lifecycle status, approval review, and document versioning. However, those items alone do not show what business objective, dependent requirement, interface, process change, or test case will be affected when a requirement is added or changed. The missing element is explicit trace relationships and how they will support impact analysis during change control. That is what preserves downstream coverage and keeps baseline decisions informed. More administrative discipline helps, but it does not replace end-to-end traceability.

Without defined trace links, the team cannot perform reliable impact analysis or control changes across the integrated solution.

Question 175

Topic: Planning

A retail bank’s approved requirements management plan assumes one predictive delivery team, one operations approver, and monthly requirements reviews. The solution scope is expanded to include fraud alerts, the work is reassigned to two agile teams plus a vendor, and compliance must now review requirements each sprint. Which evidence would best justify updating the requirements management plan?

• A. A burndown chart from the first agile team
• B. Prototype demo feedback showing users like the new screens
• C. A delta analysis showing gaps between current plan assumptions and the new scope, roles, approvals, and cadence
• D. A count of backlog items created for the fraud alert features

Best answer: C

What this tests: Planning

Explanation: The best evidence is a delta analysis that compares the approved requirements management plan with the new project conditions. Because scope, team structure, stakeholder approvals, and delivery cadence all changed, the BA needs evidence that the plan’s assumptions are no longer valid.

A requirements management plan should be updated when the assumptions behind it change in ways that affect how requirements will be elicited, analyzed, approved, communicated, or controlled. In this scenario, all three triggers are present: expanded scope, a different team structure, and a shift from predictive reviews to sprint-based review cycles with added compliance involvement. A delta analysis is the strongest artifact because it explicitly compares the current plan to the new conditions and identifies what must change, such as roles, approval paths, communication timing, and management methods.

Measures like backlog volume or burndown may be useful for delivery tracking, and demo feedback may help validate solution acceptance, but they do not show whether the planning framework itself is now misaligned. The key takeaway is to update the plan when documented planning assumptions no longer match the delivery reality.

A gap or delta analysis directly shows that the approved plan no longer fits the changed scope, team structure, and delivery approach.

Questions 176-200

Question 176

Topic: Needs Assessment

A business analyst is assessing a project to improve a retailer’s online return process. After initial workshops, the scope expands to include refund timing rules and warehouse exception handling, affecting finance, warehouse operations, and customer service. The sponsor asks how stakeholder identification should be updated. Which action should the business analyst NOT take?

• A. Review adjacent processes to find newly impacted parties
• B. Update stakeholder engagement based on influence and interest
• C. Reassess the stakeholder register against the expanded scope
• D. Add newly affected groups only after requirements are baselined

Best answer: D

What this tests: Needs Assessment

Explanation: Stakeholder identification is iterative, not a one-time activity. When scope expands or requirements reveal new impacts, the business analyst should revisit who is affected and adjust engagement; delaying additions until baselining is the anti-pattern.

The core concept is iterative stakeholder identification. In PMI-PBA practice, the business analyst continues refining the stakeholder list as goals, objectives, scope, and requirements reveal new business impacts or dependencies. In this scenario, refund timing rules and warehouse exception handling introduce new financial and operational effects, so the analyst should look again at who is affected, who has decision authority, and who must be consulted or informed.

• Recheck the expanded scope and new impacts.
• Identify newly affected business units, SMEs, and decision makers.
• Update the stakeholder register and engagement approach.
• Involve new stakeholders before requirements are finalized.

Waiting until requirements are baselined is too late because it can exclude needed input, hide conflicts, and force avoidable rework once overlooked stakeholders surface.

Waiting until baselining delays representation from newly impacted parties and increases the risk of missed requirements and rework.

Question 177

Topic: Needs Assessment

A retailer wants to reduce new loyalty-account activation from 2 days to 15 minutes. The sponsor wants the solution scope statement limited to the customer registration app. Operations says manual fraud review may also need to change, and finance wants reward-settlement updates included. Before deciding the solution scope boundary, what should the business analyst verify FIRST?

• A. Which vendor can deliver the registration app fastest
• B. Which additional stakeholder requests can be bundled into one release
• C. Which process steps and interfaces must change to meet the activation target
• D. Which department will provide the largest share of funding

Best answer: C

What this tests: Needs Assessment

Explanation: The first step is to clarify the business-driven boundary of the solution, not funding, vendors, or extra requests. To decide whether fraud review or reward settlement belongs in scope, the BA must confirm which process steps and interfaces actually need to change to achieve the 15-minute activation goal.

A solution scope statement should define the boundary of the change needed to address the business problem or opportunity. In this scenario, the key question is not who pays, which product to buy, or what else stakeholders want; it is which parts of the end-to-end activation process must change for the target outcome to be possible.

The BA should first verify:

• where the delay occurs in the current state
• which handoffs, rules, or interfaces contribute to it
• which capabilities must change in the future state to meet the target

That information shows whether manual fraud review, reward settlement, both, or neither belong inside the solution boundary. The closest distractor is bundling extra requests, but release packaging comes after the needed scope is understood.

Scope boundaries should be based first on the end-to-end business changes required to achieve the stated business outcome.

Question 178

Topic: Planning

A healthcare insurer is running a hybrid initiative. Compliance requirements are approved in version-controlled documents, delivery teams decompose them into user stories in an agile backlog tool, and QA manages test cases in a separate test tool. When a regulation changes, analysts spend days reconciling versions, some impacted stories are missed, and business approvers reopen items because they cannot see end-to-end impacts. What is the most likely underlying BA planning gap?

• A. Stakeholders need more frequent status reports on project progress.
• B. No bidirectional traceability repository or matrix was defined across regulations, requirements, stories, and tests.
• C. Operations users were not included in enough elicitation sessions.
• D. Requirements should not be baselined until all testing is complete.

Best answer: B

What this tests: Planning

Explanation: The symptoms point to a traceability design gap, not a communication or elicitation problem. In a hybrid, compliance-driven environment with multiple tools, the BA should define a bidirectional traceability artifact or linked repository that connects source regulations through requirements, backlog items, and test cases.

The core issue is that the project environment spans multiple requirement levels and multiple tools, but no traceability approach appears to connect them. That creates version reconciliation work, missed downstream impacts, and approval churn when stakeholders cannot see how a regulatory change affects detailed requirements, stories, and tests.

A fit-for-purpose traceability solution here should support:

• linkage from regulatory source to approved requirements
• decomposition to backlog items or stories
• connection to test cases and validation results
• impact analysis when changes occur

A bidirectional traceability matrix or integrated repository is the best planning response because it matches the hybrid context and the need for monitoring and validation. More meetings or reports may improve visibility, but they do not solve the underlying inability to trace change across artifacts.

This environment needs an end-to-end traceability artifact or linked tool approach so changes can be traced quickly across source, delivery, and validation items.

Question 179

Topic: Analysis

A company is replacing its claims intake process with a product delivered in 2-week iterations. The BA validates user stories mainly through end-of-release UAT sign-off. During each sprint review, only the product owner attends. After three increments are built, compliance and call center supervisors identify missing business rules, exception paths, and handoff steps, causing repeated rework and debate over whether requirements were already “approved.” What is the most likely underlying BA gap?

• A. The team lacked a detailed traceability matrix
• B. The solution was released before UAT was complete
• C. Validation was not tailored for iterative delivery
• D. Stakeholders were changing scope too often

Best answer: C

What this tests: Analysis

Explanation: The core issue is a mismatch between the delivery approach and the validation approach. In an iterative context, requirements should be validated early and often through demos, prototypes, and stakeholder feedback on each increment, not primarily through end-of-release sign-off.

This scenario points to a validation timing and technique problem. The work is delivered in short iterations, but the BA is using a mostly predictive validation pattern by relying on end-of-release UAT sign-off. That delays discovery of gaps until after multiple increments are built, which explains the rework, approval churn, and confusion about whether requirements were already accepted.

In iterative delivery, effective validation should:

• involve the right stakeholders each increment
• use sprint reviews, demos, or prototypes to confirm need and fit
• validate business rules, exception flows, and operational impacts early
• refine stories and acceptance criteria continuously

A traceability artifact can help monitor status, but it does not replace timely validation. The key takeaway is that validation must match the lifecycle so missing needs are exposed before significant build effort is spent.

The BA used late, formal validation instead of frequent increment reviews with the right stakeholders for an iterative lifecycle.

Question 180

Topic: Needs Assessment

A business analyst is preparing a needs assessment package for a claims-processing improvement effort. Four stakeholder groups provided value inputs, but they conflict. The draft note says:

Business need: Improve claims processing.
Stakeholder values:
- Claims managers: reduce average handling time
- Compliance: add more verification checkpoints
- Customer service: shorten claimant wait time
- Finance: avoid increasing operating cost
Prioritization note: All stakeholder requests are critical and will be ranked later during solution design.

Which is the most important flaw to fix before this package can serve as a prioritization baseline?

• A. It does not show document control information.
• B. It does not identify the elicitation sources for each value input.
• C. It does not compare stakeholder values or define trade-off priorities.
• D. It does not quantify current-state performance measures.

Best answer: C

What this tests: Needs Assessment

Explanation: The draft cannot serve as a prioritization baseline because it lists conflicting stakeholder values but provides no agreed way to compare them. In needs assessment, the BA must establish relative importance and trade-off logic before later requirements decisions can be made consistently.

The core issue is missing value comparison. A prioritization baseline is not just a list of stakeholder wants; it is an agreed reference for how competing value expectations will be weighed when trade-offs arise. Here, speed, compliance, customer responsiveness, and cost control naturally conflict, yet the draft says all requests are critical and postpones ranking until solution design. That means the team has no baseline for deciding what matters most when priorities collide.

A stronger package would include an agreed approach such as ranked business objectives, weighted decision criteria, or a stakeholder-approved trade-off hierarchy. Current-state metrics, source references, and document control improve quality, but they do not solve the central problem of unresolved stakeholder value conflicts.

A prioritization baseline requires agreed relative importance among competing stakeholder values, not a statement that everything is critical.

Question 181

Topic: Analysis

A business analyst is elaborating acceptance criteria for a customer portal feature.

Exhibit: Requirements excerpt

Requirement R-12:
Customers must be able to reset a forgotten password without
contacting the service desk.

Business rules:
- Only active customer accounts may be reset.
- Identity must be verified with a one-time code sent to the
  email address or mobile number on file.
- New passwords must contain at least 12 characters, including
  upper-case, lower-case, and a number.
- Every successful password change must be recorded in the
  security audit log.

Which acceptance criterion best derives a detailed, testable condition from this requirement set?

• A. Given the reset feature is released, when customers use it, then service desk calls drop by 30%.
• B. Given a reset request, when an email is on file, then a code is sent.
• C. Given an active account, when a valid code and compliant password are submitted, then the password is changed and audit logged.
• D. Given any account, when a user enters a new password, then access is restored immediately.

Best answer: C

What this tests: Analysis

Explanation: Detailed acceptance criteria should be specific, testable, and trace directly to the requirement and its business rules. The best choice includes the required precondition, verification method, password rule, and expected system outcome, making it suitable for validation.

The core concept is turning a high-level requirement into acceptance criteria that are observable and testable. A strong acceptance criterion should state the relevant precondition, the triggering action, and the expected result while tracing to the stated business rules.

Here, the best criterion covers the active-account condition, successful identity verification, password-policy compliance, and audit logging. That makes it complete enough for QA and stakeholders to evaluate whether the solution meets the requirement as specified. By contrast, a criterion that captures only one step, ignores a stated rule, or measures a business outcome instead of product behavior does not adequately elaborate the requirement.

The key takeaway is that acceptance criteria validate solution behavior, not just business benefits or partial process steps.

It translates the high-level requirement and stated business rules into a complete, measurable condition that can be validated by testing.

Question 182

Topic: Analysis

A bank is replacing its customer onboarding workflow. Sponsors want to confirm after release that cycle time drops from 5 days to 2 days and first-pass completion reaches 95%. Several interface and compliance requirements affect these outcomes, and the requirements package is about to be baselined. How should the business analyst document the metrics and acceptance criteria to best support later validation and evaluation?

• A. Baseline measurable criteria in requirements with trace links and version control
• B. Record the criteria in workshop notes and refine them during UAT
• C. Add the metrics to the test plan after design is finished
• D. Keep the KPIs in the business case and let QA define thresholds

Best answer: A

What this tests: Analysis

Explanation: Metrics and acceptance criteria should be documented as measurable, baselined requirements artifacts that can be traced forward to validation and backward to business objectives. That gives the team clear test targets, preserves dependency coverage, and ensures any later threshold changes go through version-controlled change control.

The key concept is to document metrics and acceptance criteria where they remain testable, traceable, and controlled across the full lifecycle. In this scenario, the targets for cycle time and first-pass completion should be written as measurable acceptance criteria in the requirements package or linked requirement records, then baselined with unique identifiers, source/rationale, and trace links to related interface, compliance, and business requirements.

This supports later work by allowing the team to:

• validate delivered features against explicit thresholds
• analyze impacts when a requirement or dependency changes
• maintain version history and baseline integrity
• evaluate whether the deployed solution achieved the business need

Putting criteria only in test documents, notes, or QA interpretation weakens traceability and can disconnect evaluation results from approved requirements. The closest distractors document the information somewhere, but not in a controlled, baselined form that supports downstream validation and evaluation.

This preserves auditable, testable acceptance criteria tied to objectives and dependencies while ensuring later changes are controlled.

Question 183

Topic: Traceability and Monitoring

A BA is reviewing a release-readiness dashboard for a claims intake project. The requirements management plan states that once a requirement is baselined, any change must include origin, rationale, impact analysis, and change approval, and approved requirements must trace to supporting artifacts before UAT.

UAT starts in one week, and the BA can escalate only one issue immediately. Monitoring evidence shows:

• 96% of approved functional requirements trace to test cases; the remaining 4% were formally deferred to Release 2.
• One process model has an older version number, but its linked requirements and tests still match the approved baseline.
• Eight baselined requirements were changed during sprint reviews and built by the team; only three changes include impact analysis, and none show change approval.
• Two enhancement requests are logged with rationale and are waiting for the next change review.

Which issue is the strongest evidence that requirements governance is not functioning effectively?

• A. Deferred Release 2 requirements are not linked to current test cases
• B. An outdated process model version remains in the repository
• C. New enhancement requests are still awaiting change review
• D. Implemented baseline changes without recorded impact analysis or approval

Best answer: D

What this tests: Traceability and Monitoring

Explanation: The clearest sign of ineffective requirements governance is that baselined requirements were changed and implemented without the required impact analysis and formal approval. That means the control mechanism for authorized change is being bypassed, which threatens traceability, downstream artifacts, and stakeholder confidence.

Requirements governance is functioning effectively when lifecycle rules are consistently enforced, especially after baselining. In this scenario, the highest-risk evidence is not a minor repository issue or a documented future release decision; it is that approved requirements were altered and built without completing the required change controls. That breaks the governance model because the team cannot reliably show who requested the change, why it was accepted, what impacts were assessed, or whether dependent artifacts were properly updated.

A formally deferred requirement is still governed if the decision is documented. A pending enhancement request is also governed if it is captured and awaiting review. An older model version is a document-control concern, but the stem says the linked requirements and tests still align to the approved baseline.

The key takeaway is that undocumented, unapproved implemented changes are the strongest indicator that governance is failing, not merely that documentation needs cleanup.

Bypassing required analysis and approval for baselined changes shows the governance controls are not being followed, creating the highest risk to traceability, scope, and acceptance.

Question 184

Topic: Analysis

A business analyst is reviewing draft requirements for a customer self-service portal before sending them to development. Which statement is NOT written in a measurable and actionable way?

• A. Lock the account after five failed sign-in attempts in 15 minutes.
• B. Provide a user-friendly and efficient login experience.
• C. Show order status within 2 seconds for 95% of requests.
• D. Allow agents to reset a password in three steps or fewer.

Best answer: B

What this tests: Analysis

Explanation: Measurable and actionable requirements describe a specific behavior that development and testing teams can verify. The statement about a user-friendly and efficient login experience is vague because it does not define exactly what the solution must do or how success will be measured.

The key concept is requirement quality for development readiness. A requirement is measurable and actionable when it states a clear behavior, actor or system response, and a condition or threshold that can be built and tested. In this scenario, the acceptable statements specify concrete outcomes such as a lockout after a defined number of failed attempts, a response-time target, or a maximum number of steps. By contrast, phrases like “user-friendly” and “efficient” are subjective; different stakeholders could interpret them differently, and testers would not know what evidence proves the requirement was met. To make that statement usable, the analyst should replace the vague adjectives with specific measures such as login completion time, error rate, or step count. The main takeaway is that suitable requirements avoid opinion-based wording and use observable, testable criteria.

It uses subjective adjectives without defining observable behavior or testable acceptance criteria.

Question 185

Topic: Needs Assessment

A business analyst is documenting current-state findings to support a business case for improving the company’s order-to-cash process. Stakeholders want the business case to focus on the existing problem, its impact, and why change is needed. Which finding should NOT be documented as a current-state input to the business case?

• A. The company should implement Vendor X’s platform with mobile dashboards.
• B. Sales representatives maintain shadow spreadsheets to track order status.
• C. Order entry takes 18 minutes because staff re-enter data in three systems.
• D. Invoice corrections affect 7% of monthly orders due to customer data mismatches.

Best answer: A

What this tests: Needs Assessment

Explanation: Current-state findings used in a business case should describe the existing environment, including pain points, impacts, and measurable baselines. A recommendation to adopt a specific vendor platform moves into solution selection and should not be documented as a current-state finding.

The key concept is separating current-state evidence from solution recommendation. Input to a business case should capture what is happening now: process delays, error rates, workarounds, operational impacts, and other measurable facts that define the business problem or opportunity. In this scenario, long order-entry time, invoice correction rates, and shadow spreadsheets all describe the present state and help justify change.

A statement that the company should implement a named vendor platform is different. It assumes a solution before the business case has fully established the problem, options, and value rationale. That makes it an anti-pattern for current-state documentation. The closest distractors are valid because they provide objective evidence of inefficiency or control gaps in the existing process.

This is a proposed solution decision, not a factual current-state finding about the existing business problem.

Question 186

Topic: Analysis

A business analyst is baselining the next product release. The backlog items have already been accepted and ranked by business value. The release date and budget are fixed, but an architect notes that two top-ranked items rely on a security service upgrade from another team, and the integration specialist is only available part-time. Before deciding which items remain in the release baseline and which are deferred, what should the BA verify FIRST?

• A. Whether stakeholders want to rescore the current business value rankings
• B. Whether QA can draft test cases for the deferred items
• C. Whether dependencies and critical resource capacity support the top-ranked items
• D. Whether the sponsor can increase budget to keep all scope

Best answer: C

What this tests: Analysis

Explanation: The backlog is already prioritized by value, so the missing information is feasibility. Before baselining accepted and deferred requirements, the BA should verify dependency readiness and constrained resource capacity to confirm what can realistically fit the release.

When forming a release baseline, prioritization by value is necessary but not sufficient. The BA must also test whether the highest-value requirements are feasible within the stated schedule, budget, and resource constraints. In this scenario, the unresolved security-service dependency and limited specialist availability directly affect whether the top-ranked items can be delivered in the release.

A sound first check is to confirm:

• prerequisite dependencies are ready or scheduled in time
• critical shared resources have enough capacity
• affected requirements can still fit the fixed release window

Only after that verification should the BA finalize which requirements stay accepted for the release and which are deferred. Re-ranking value may be useful later, but it does not resolve feasibility under current constraints.

A realistic release baseline must first confirm that high-value items are actually feasible within dependency and capacity constraints.

Question 187

Topic: Analysis

A business analyst is elaborating acceptance criteria for a new pricing recommendation tool. One approved requirement states: “Sales managers must be able to understand the reason for each recommended discount well enough to explain it to the customer during the call.” During pilot validation, which measure would be most useful for this requirement?

• A. User rating of explanation clarity during scenario-based pilot reviews
• B. Percentage of recommendations accepted without override
• C. Average time to display each recommendation explanation
• D. Number of customer calls handled per manager per day

Best answer: A

What this tests: Analysis

Explanation: The requirement is about whether users can understand and explain the recommendation, so the best measure must assess clarity in realistic use. A scenario-based user rating is the most direct fit because it evaluates the qualitative outcome the requirement describes.

When a requirement focuses on comprehension, confidence, or perceived usefulness, the strongest measure is one that evaluates those qualities directly with actual users in a realistic context. Here, the key question is not speed, adoption, or productivity; it is whether sales managers can understand the rationale well enough to explain it during a customer call.

A useful fit is a scenario-based qualitative measure, such as user ratings or structured feedback on explanation clarity after reviewing sample recommendations. This ties the metric to the requirement’s intent and supports acceptance criteria that can later be quantified with a threshold if needed. Measures like display time, override rate, or call volume may matter elsewhere, but they do not directly prove that the explanation is understandable. The closest distractor is recommendation acceptance, which may reflect trust or policy compliance rather than true understanding.

This directly measures whether intended users find the recommendation explanation understandable enough to justify decisions in the required business context.

Question 188

Topic: Analysis

A retail bank is selecting a new online dispute-resolution solution. The business case defines the value proposition as reducing dispute-processing calls by 30% and raising customer satisfaction from 3.6 to 4.2 within 6 months. Both shortlisted options meet security and regulatory requirements, and either can be funded.

Exhibit:

Which recommendation is best?

• A. Select the guided web form to minimize spend.
• B. Select the guided form + status tracking option.
• C. Select the guided web form and revisit satisfaction later.
• D. Defer both options until a cheaper alternative appears.

Best answer: B

What this tests: Analysis

Explanation: The key comparison is not cost alone but whether each option delivers the business value promised in the business case. Since both options are feasible and fundable, the higher-cost option is preferred because it is the only one projected to meet the required call-reduction and satisfaction targets.

When evaluating product options, a business analyst should compare expected benefits against the defined value proposition and success measures, not just initial price. In this scenario, both options are compliant, feasible, and affordable, so cost is not the deciding factor by itself. The lower-cost guided web form provides some improvement, but it does not reach the required 30% call reduction or the target satisfaction score of 4.2. The higher-cost option meets both business outcomes, so it better supports the business case and should be recommended.

Choosing the cheaper option would confuse lower cost with higher value. An option that costs less but fails the target outcomes does not satisfy the value proposition.

It is the only option expected to achieve the stated value proposition, while the cheaper option misses both target outcomes.

Question 189

Topic: Analysis

A business analyst is supporting a claims-processing enhancement. In a scoping workshop, stakeholders ask for “one model” to clarify how claims work, but their examples mix routing steps, claim status changes, approval conditions, and disputed field meanings. Before choosing a process model, state diagram, decision table, or data dictionary, what should the business analyst determine first?

• A. Ask which stakeholders will approve the final model.
• B. Ask which repository format the project uses for requirements artifacts.
• C. Ask which solution option has the strongest business case.
• D. Ask whether the main confusion is flow, states, rules, or data definitions.

Best answer: D

What this tests: Analysis

Explanation: The best first step is to identify what kind of ambiguity must be clarified. Process models, state diagrams, decision tables, and data dictionaries each solve different analysis problems, so the analyst should first confirm whether the issue is workflow, lifecycle behavior, business rules, or data meaning.

This question tests technique selection in analysis. When stakeholders ask for “one model” but describe different kinds of confusion, the business analyst should first classify the problem to be clarified. A process model is best for sequence, handoffs, and flow; a state diagram is best for status changes over time; a decision table is best for complex rule combinations and outcomes; and a data dictionary is best for inconsistent field definitions and allowable values.

Starting with approval, repository, or business case questions does not help choose the right analysis technique. The first useful clarification is the nature of the uncertainty the model must resolve. Once that is clear, the analyst can select the technique that makes the requirement understandable and testable.

The key takeaway is to match the model to the specific type of requirement ambiguity before worrying about governance or documentation details.

The choice among these techniques depends first on whether stakeholders need clarity on sequence, lifecycle transitions, decision logic, or data meaning.

Question 190

Topic: Planning

A hybrid project is about to baseline business and stakeholder requirements for a customer onboarding solution. During planning, the BA finds that stakeholders have been sending change ideas through email, chat, and sprint demos, causing missed reviews and conflicting versions. The sponsor asks for the best evidence that the team is ready to control future requirements changes using standard submission and communication channels. Which artifact provides that evidence?

• A. Elicitation workshop notes listing requested enhancements
• B. A user acceptance test summary with pass and fail counts
• C. A requirements traceability matrix linking requirements to design and tests
• D. An approved requirements management plan with change intake channels, workflow, and notification rules

Best answer: D

What this tests: Planning

Explanation: The best evidence of readiness is an approved requirements management plan that explicitly defines how requirements change requests must be submitted and communicated. It establishes the standard channels, review path, and notification rules needed for controlled change management.

This question tests whether the team has a defined method for requirements change control, not whether requirements are complete or the solution is performing well. When stakeholders are using inconsistent paths such as email, chat, and demos, the key planning artifact is the requirements management plan that specifies the approved intake channel, required request information, impact analysis process, decision authorities, communication approach, and version control expectations.

That artifact demonstrates operational readiness to manage change in a consistent way after requirements are baselined. A traceability matrix supports impact analysis after a change is raised, but it does not by itself define where requests should be submitted or how decisions are communicated. The main takeaway is to look for the artifact that standardizes submission and communication protocols, not one that only records work or quality results.

This artifact directly shows that standard protocols exist for how change requests are submitted, evaluated, communicated, and controlled.

Question 191

Topic: Analysis

A business analyst is validating a requirements package for a claims portal. The package includes detailed compliance rules, revised screen flows, and cross-team handoff procedures. Compliance SMEs are distributed globally and can only review documents asynchronously this week. Claims supervisors can attend one live session, but frontline users will not be available until after development begins. Which validation method is one the BA SHOULD AVOID for this situation?

• A. Walkthrough of handoff procedures with claims supervisors
• B. Documentation review of the compliance rules
• C. Low-fidelity prototype review of the screen flows
• D. User acceptance testing to validate the draft requirements now

Best answer: D

What this tests: Analysis

Explanation: The best validation method depends on both the requirement type and stakeholder availability. Documentation review, walkthroughs, and prototype reviews all fit the stated artifacts and available participants, while user acceptance testing is not suitable for validating draft requirements before a solution exists.

Requirements validation should be matched to the nature of the requirement set and the stakeholders who can realistically participate. In this case, asynchronous documentation review is well suited to detailed compliance rules, a walkthrough is appropriate for confirming cross-team handoffs with supervisors, and a low-fidelity prototype helps validate screen flow before development. User acceptance testing is typically used later to confirm that a built solution meets acceptance criteria in an operationally meaningful way.

• Use document review for detailed rules and precise wording.
• Use walkthroughs for end-to-end process understanding.
• Use prototypes or demos for flow, usability, and interaction feedback.
• Use UAT after a solution is available for business users to test.

So the anti-pattern is trying to use UAT now as the main validation method for an unbuilt requirements package.

Using user acceptance testing now is inappropriate because it requires a working solution and available end users, neither of which exists in the scenario.

Question 192

Topic: Analysis

A business analyst is preparing a requirements package for a steering committee. Delivery capacity has been reduced, so one requirement will likely be moved out of the current release. The draft package note says:

R-12: Push shipment alerts | Objective: reduce service calls | Estimate: 8 points
R-18: Export dashboard to spreadsheet | Objective: improve supervisor reporting | Estimate: 5 points
R-21: Multi-factor login | Objective: satisfy security policy CP-7 | Estimate: 3 points
R-25: Address auto-suggest | Objective: reduce order entry time | Estimate: 5 points
All four items include acceptance criteria and stakeholder approval.

What is the most important improvement to this draft before deciding which requirement should be deferred first?

• A. Add document version history and distribution details
• B. Replace point estimates with hour-based estimates
• C. Add business value ranking and dependency information
• D. Expand acceptance criteria into detailed test scripts

Best answer: C

What this tests: Analysis

Explanation: When constraints tighten, the key question is which accepted requirement can be deferred with the least harm to value delivery and baseline integrity. That decision depends on relative business value and dependencies, which are missing from the draft package.

The core concept is requirement allocation under constraint: accepted requirements are deferred or retained by balancing scope, schedule, budget, resources, and the value proposition. This draft shows objective links and effort, but it does not show the relative value of each requirement or whether one requirement enables or blocks another. Without that, the committee cannot confidently identify the safest requirement to defer first.

A sound package should let decision makers compare:

• business value or priority by requirement
• mandatory versus discretionary items
• dependency or sequencing constraints
• effort in relation to expected benefit

Version history, estimate units, and more detailed test scripts may improve documentation quality, but they do not answer the immediate deferral decision. The closest distractor is changing estimates to hours, because effort matters, but effort alone does not show what should be deferred first.

Deferral decisions should be based on relative value and dependency impact, not just effort, because the team must remove the least valuable feasible requirement first.

Question 193

Topic: Evaluation

A business analyst is preparing stakeholder sign-off for deployment of a new claims portal. Functional acceptance criteria have been met, but stakeholders disagree on readiness: operations cites incomplete training and limited support coverage, while sales wants release before a seasonal campaign. An agreed deployment-readiness checklist already defines the evaluation criteria, and the sponsor wants a transparent recommendation before signing. Which decision-making approach should the business analyst use?

• A. Escalate for an immediate sponsor decision
• B. Run Delphi rounds for anonymous expert consensus
• C. Decide by majority vote in a sign-off meeting
• D. Score readiness with a weighted decision matrix

Best answer: D

What this tests: Evaluation

Explanation: When readiness criteria already exist and stakeholders disagree on whether the solution is ready, the best approach is a structured comparison against those agreed criteria. A weighted decision matrix makes the basis for the recommendation visible, objective, and easier for stakeholders to accept.

The core concept is to use a decision-making technique that converts stakeholder disagreement into an evidence-based discussion. Here, the team already has an agreed deployment-readiness checklist, so the business analyst should facilitate scoring the solution against those criteria, such as training completion, support coverage, defect severity, and business timing. A weighted decision matrix works well because it makes priorities and trade-offs explicit, helps stakeholders see why a release is or is not ready, and supports a defensible sign-off recommendation.

This is especially appropriate when:

• readiness is disputed
• evaluation criteria already exist
• the sponsor wants transparent justification

The closest distractors either bypass agreement-building or fit a different situation, such as broad expert forecasting rather than immediate deployment readiness.

A weighted decision matrix uses the agreed readiness criteria to make trade-offs explicit and build evidence-based agreement before sign-off.

Question 194

Topic: Planning

A business analyst has started planning work for a customer portal project. The stakeholder map, elicitation schedule, and traceability approach were drafted based on a goal of increasing self-service adoption. Before elicitation begins, the sponsor updates the business case after an audit finding: the first release must now prioritize compliance with new data-retention rules, even if some usability enhancements are deferred. What should the business analyst do next?

• A. Obtain immediate approval of a revised scope before further analysis
• B. Reassess BA priorities against the new objectives and update the plan
• C. Continue the original plan and capture compliance needs during elicitation
• D. Ask the delivery team to reprioritize features while documentation catches up

Best answer: B

What this tests: Planning

Explanation: When project goals change after planning has started, the BA should first realign business analysis work to the updated business case and objectives. That means assessing impacts to priorities, stakeholders, planned activities, and contingencies before moving ahead.

The core concept is to re-establish context for business analysis activities when goals or objectives shift. In this scenario, the original planning assumptions were based on adoption and usability, but the updated business case now makes compliance the primary driver. The BA should first analyze what this change means for BA priorities and then revise the planning approach accordingly.

• Review the updated business case and objectives
• Identify impacted stakeholders, requirements focus, and dependencies
• Adjust BA activities, sequencing, and contingency plans
• Communicate the revised approach before continuing

Continuing with the old plan, seeking approval too early, or letting the delivery team reprioritize without BA impact analysis all skip the needed planning adjustment. The key takeaway is that changed objectives require a deliberate reset of BA priorities before execution continues.

A change in project objectives requires the BA to review impacts on business analysis priorities, stakeholders, and contingency plans before proceeding.

Question 195

Topic: Planning

A business analyst is defining the requirements change management plan for a regulated claims-processing project. After requirements are baselined, many change requests are expected from operations, compliance, and the product owner. The plan must specify how approved, rejected, and deferred changes will be documented and communicated. Which practice is INCORRECT to include?

• A. Record each decision, rationale, owner, and version impact in a change log.
• B. Update requirement status and traceability after approved changes are implemented.
• C. Archive rejected changes without communication unless the requester asks later.
• D. Notify impacted stakeholders when a deferred change will be reconsidered.

Best answer: C

What this tests: Planning

Explanation: A sound change control approach documents and communicates every disposition, not just approved changes. Rejected and deferred requests still need visible status, rationale, and stakeholder communication to avoid confusion, duplicate requests, and misaligned expectations.

The core concept is that change control must cover the full lifecycle of a request: submission, analysis, decision, documentation, and communication. In the scenario, the plan explicitly needs a standard protocol for approved, rejected, and deferred changes. That means each disposition should be captured with status and rationale, then communicated to affected stakeholders through defined channels.

Rejected requests should not disappear into an archive with no communication. If they are not communicated, requesters and downstream stakeholders may continue assuming the change is pending, resubmit it unnecessarily, or make planning decisions based on outdated expectations. Deferred requests need a future review point, and approved requests require updates to requirements status, versioning, and traceability.

The key takeaway is that visibility and documented disposition are required for all change outcomes, not only the approved ones.

Rejected changes still require documented disposition and proactive communication so stakeholders understand the decision and do not continue planning against them.

Question 196

Topic: Traceability and Monitoring

On a hybrid project, a business analyst sends the same weekly 18-page requirements status report to the steering committee, project manager, and delivery team. The report includes detailed story updates, traceability IDs, and defect notes. Governance meetings keep deferring decisions because key impacts are hard to find, while the delivery team often learns about approved requirement changes too late, causing rework. What is the most likely underlying BA gap?

• A. Requirements were not formally baselined before implementation started.
• B. Communication was not tailored by audience for cadence and level of detail.
• C. User stories lacked detailed acceptance criteria for testing.
• D. The solution scope statement did not define measurable business benefits.

Best answer: B

What this tests: Traceability and Monitoring

Explanation: The core problem is a communication mismatch, not a missing artifact. Governance stakeholders need concise, impact-focused status at decision points, while working teams need timely operational detail about requirement changes. Using one report for both audiences caused approval churn and late awareness.

This scenario points to a requirements communication gap: the BA used the same format, content, and frequency for audiences with very different needs. Governance bodies typically need summarized decision-ready information such as change impact, risk, and approval items. Working teams need more frequent, detailed updates so they can adjust analysis, build, and testing work quickly. When those needs are not tailored, executives delay decisions because the message is too detailed, and delivery teams create rework because critical changes are not communicated in a usable cadence.

A sound approach is to tailor communication by stakeholder group:

• governance: concise summaries, impacts, decisions needed
• working team: frequent detailed updates, dependencies, changed items
• project manager: consolidated status, risks, and escalation points

The key takeaway is that requirements status communication must be audience-specific in both detail and timing.

Governance and working-team stakeholders need different frequency and detail, so using one report for all audiences creates both delayed decisions and rework.

Question 197

Topic: Planning

A financial services company is starting a hybrid initiative with process changes, vendor configuration, and new compliance reports. Requirements are currently split across user stories, process models, and policy documents in different repositories. The sponsor asks the business analyst to recommend documentation management tools and techniques for requirements traceability and versioning.

What should the business analyst clarify first before making that recommendation?

• A. Stakeholder training needs and rollout schedule
• B. Existing templates and document naming conventions
• C. Required trace links, version history, and baseline controls
• D. Available budget and preferred vendor platform

Best answer: C

What this tests: Planning

Explanation: The first step is to understand what traceability and versioning the organization actually needs to manage. Without knowing required relationships, approval points, baselines, and history expectations, the business analyst cannot choose an appropriate document control approach.

When selecting documentation management tools and techniques, the deciding factor is the required control model, not the software brand or rollout details. In this scenario, requirements exist in multiple artifact types and repositories, so the business analyst must first determine what must be traced to what, how versions will be controlled, when baselines are established, and what history or auditability must be retained.

That information drives whether a simple shared repository, a structured traceability matrix, backlog integration, or a dedicated requirements management tool is appropriate. It also determines workflow, permissions, status fields, and reporting needs. Budget, training, and templates matter, but only after the traceability and versioning requirements are clear enough to evaluate suitable options.

The closest distractor is naming conventions, which help standardize control but do not define the actual traceability and versioning capability needed.

Tool and technique selection should start with the specific traceability and versioning needs the solution must support across the lifecycle.

Question 198

Topic: Evaluation

A BA is reviewing evidence for a new customer self-service password reset feature. QA reports that all functional test cases passed, but one release acceptance criterion in the approved requirements package states that 80% of pilot users must complete a reset unaided within 2 minutes to reduce support calls. Pilot results show only 42% met that threshold, and the release board needs the BA’s recommendation tomorrow. What is the BEST action?

• A. Document the gap and recommend no sign-off yet
• B. Approve release because functional requirements were satisfied
• C. Recommend user training after release to improve adoption
• D. Ask QA to rerun the same functional test scripts

Best answer: A

What this tests: Evaluation

Explanation: The key issue is that passing technical tests does not equal satisfying business acceptance criteria. Because the approved criterion tied to the business objective was not met, the BA should identify the gap and avoid recommending acceptance until it is addressed or formally dispositioned.

In evaluation, the BA validates test evidence against the full acceptance criteria, not just technical pass rates. Here, the feature works functionally, but the approved criterion measures the business intent: users must complete the task unaided within 2 minutes to reduce support calls. Since pilot evidence shows only 42% success against an 80% threshold, the solution does not yet satisfy the stated requirement.

The BA’s best action is to:

• compare actual results with the approved criterion
• document the variance and likely business impact
• communicate that acceptance should not be recommended yet
• support remediation or a formal decision through governance

The closest distractor is post-release training, but training does not erase the fact that current evidence fails the defined acceptance condition.

The solution passed technical tests but failed an approved business-focused acceptance criterion, so the BA should report the delta and withhold recommendation for acceptance.

Question 199

Topic: Analysis

A business analyst is documenting requirements for a new claims portal. In an elicitation workshop, the compliance manager states that submitted claim records must be retained for seven years. The analyst captured the requirement text, but not who requested it or why it is needed. Before moving into prioritization and solution assessment, what should the analyst do next?

• A. Ask the technical team to estimate storage options
• B. Add the requirement to the traceability matrix as is
• C. Record the requirement’s origin and rationale
• D. Submit the requirement for sponsor sign-off

Best answer: C

What this tests: Analysis

Explanation: The best next step is to capture the requirement’s supporting details, especially its origin and rationale. Those details help the analyst evaluate priority, resolve questions, and assess impacts later in the lifecycle.

In PMI-PBA analysis work, a requirement should be captured with enough supporting detail to enable future analysis, not just as a standalone statement. Here, the analyst already has the requirement text, but is missing two key attributes: who originated the requirement and the business reason behind it. Recording the compliance manager as the source and the record-retention need as the rationale helps with prioritization, validation, conflict resolution, and later change impact analysis.

Moving to approval, estimation, or downstream traceability before capturing that context is premature because those activities depend on understanding why the requirement exists and who can clarify it. The key takeaway is that a requirement is more useful when its source and purpose are documented along with the statement itself.

Capturing who raised the requirement and why it exists provides the supporting detail needed for later analysis, prioritization, and change assessment.

Question 200

Topic: Needs Assessment

A bank begins a project with the goal, “implement a chatbot to reduce contact-center costs.” After kickoff, compliance says many inquiries still require human verification, operations says call volume is driven mainly by billing errors, and customer service says success should be measured by first-contact resolution, not fewer calls. Each stakeholder review changes scope and priorities, causing rework. What is the most likely underlying BA gap?

• A. Failure to schedule enough approval meetings with key stakeholders
• B. Failure to analyze the underlying business problem, desired outcomes, and solution scope before setting project goals
• C. Failure to baseline detailed requirements before stakeholder reviews
• D. Failure to prepare a user training and transition plan

Best answer: B

What this tests: Needs Assessment

Explanation: The scenario shows solution-first thinking: the chatbot was defined as the goal before the actual business problem was clarified. Conflicting stakeholder input about billing errors, compliance limits, and success measures indicates the BA should have validated the real need and scope before aligning project goals.

The core concept is clarifying business needs before defining project goals. Here, the project started with a specific solution idea instead of confirming the actual problem to solve. Stakeholder feedback later revealed that demand may be caused by billing errors, some inquiries cannot be automated, and success should be tied to service outcomes rather than simple cost reduction. That pattern points to an unmet needs assessment task: identifying the real business problem, desired value, constraints, and high-level solution scope before turning them into project objectives.

• Confirm the business problem or opportunity.
• Define measurable desired outcomes.
• Clarify key constraints and scope boundaries.
• Align goals to the validated need, not a preferred solution.

A missing requirements baseline or extra approvals would not explain why the original goal itself was misaligned.

The team treated a proposed solution as the goal instead of first clarifying the real business need, outcomes, and high-level scope.

How to interpret your result

• 85% or higher: you are likely handling BA scenario judgment well if the set was unseen and timing stayed stable.
• 75-84%: review whether misses come from weak elicitation, unclear baselines, poor traceability, or evaluation gaps.
• Below 75%: return to focused domain pages before doing another 200-question attempt.

For PMI-PBA, do not look only at total score. A good diagnostic should show whether you can connect stakeholder needs, requirements quality, traceability, and solution evaluation without losing control of the baseline.

What PM Mastery adds after this diagnostic

This page gives one complete public PMI-PBA diagnostic. PM Mastery adds the larger business-analysis bank, focused domain drills, mixed timed mocks, progress tracking, and explanations for requirements, traceability, stakeholder approval, and evaluation decisions.

Retake protocol

Do not retake immediately. Review the miss pattern, drill the weakest domain, and then use a varied PM Mastery mock for a cleaner readiness signal than repeating this static page.

Continue with full practice

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.

Focused topic pages

• PMI-PBA: Needs Assessment
• PMI-PBA: Planning
• PMI-PBA: Analysis
• PMI-PBA: Traceability and Monitoring
• PMI-PBA: Evaluation

Free review resource

Read the PMI-PBA guide on PMExams.com for concept review, then return here for PM Mastery practice.