Overview
Evaluation covers four tasks at the end of the requirements lifecycle and beyond: validating the solution's test results, reports and other evidence against the requirements acceptance criteria; analyzing and communicating gaps and deltas with quality assurance tools and methods so stakeholders can resolve discrepancies between solution scope, requirements and the developed solution; obtaining stakeholder sign-off on the developed solution so deployment can proceed; and evaluating the deployed solution with valuation techniques to see how well it meets the business case and value proposition.
Candidates must understand that evaluation depends on the acceptance criteria written in Domains 2 and 3 and on the traceability built in Domain 4. They also need to see that the analyst's job does not end at go-live: the final task compares real results with the value promised in the Domain 1 business case, often months after deployment.
How it's tested
Evaluation questions are scenarios set during user acceptance testing, at the go or no-go decision, or months after deployment. You decide whether evidence satisfies acceptance criteria, how to classify and handle a discrepancy, who must sign off, or how to judge whether the solution delivered value. The right answer compares evidence with agreed criteria or the business case rather than opinion.
-
Evidence against criteria
Test results are presented with the acceptance criteria, and you decide whether the requirement is satisfied or which result fails the measurable threshold.
-
Classify the discrepancy
A difference between the solution and expectations appears, and you decide whether it is a defect, a gap against requirements, or a new requirement that needs change control.
-
Value after deployment
The solution is live, and the question asks how to judge success, usually by measuring business metrics against the business case and value proposition.
A payroll solution passed every user acceptance test, but three months later processing cost per payslip has not fallen, which was the main objective in the business case. Options include closing the project, adding features, measuring against the business case metrics and analyzing why, or re-running acceptance tests. Passing tests proved the requirements were met, not that value was realized; the analyst evaluates actual metrics against the business case and investigates the shortfall.
Tasks 4
Official tasks from the PMI outline, in outline order.
5.1 Validate the solution's test results, reports, and other test evidence against the requirements acceptance criteriaJudge whether evidence shows the solution satisfies the requirements.
- What it means
- The analyst reviews test results, reports and other evidence, such as user acceptance test outcomes, and compares them with each requirement's acceptance criteria to determine whether the solution satisfies the requirements.
- What to understand
- The analyst does not usually run every test but evaluates whether the evidence meets the agreed, measurable criteria. Traceability from requirement to test case to result is what makes this comparison complete.
- How it shows up
- A result is reported as acceptable, but its measured value misses the criterion, and you decide whether the requirement is met.
- Common confusion
- Accepting a test as passed because the tester marked it passed, without checking the result against the criterion's threshold.
5.2 Analyze and communicate the solution's identified gaps and deltasExplain discrepancies so stakeholders can resolve them.
- What it means
- Using quality assurance tools and methods, the analyst analyzes differences between solution scope, requirements and the developed solution and communicates them so stakeholders can decide how to resolve them.
- What to understand
- A gap is where the solution falls short of a requirement or scope; a delta is a difference between what was specified and what was built. Root cause analysis and severity assessment help stakeholders choose to fix now, accept with a workaround, or defer.
- How it shows up
- UAT reveals a difference between the built feature and stakeholder expectations, and you choose how to classify and handle it.
- Common confusion
- Treating a stakeholder's new idea discovered during testing as a defect instead of a change request.
5.3 Obtain stakeholder sign-off on the developed solutionSecure formal acceptance so deployment can proceed.
- What it means
- Using decision-making techniques, the analyst facilitates stakeholders' formal acceptance of the developed solution so that deployment can proceed.
- What to understand
- Sign-off is based on evidence that acceptance criteria are met and on agreed handling of open gaps, such as accepted workarounds or deferred fixes. It is distinct from the requirements baseline sign-off in task 3.5.
- How it shows up
- Stakeholders disagree about deploying with known minor gaps, and you choose how sign-off should be reached.
- Common confusion
- Mixing solution sign-off with requirements sign-off, or assuming the analyst signs off on the business's behalf.
5.4 Evaluate the deployed solutionMeasure real-world value against the business case.
- What it means
- After deployment, the analyst uses valuation techniques to determine how well the solution meets the business case and value proposition.
- What to understand
- Evaluation compares actual business metrics, such as cost, revenue, cycle time or satisfaction, with the baseline and targets set earlier, often over months. Findings can lead to enhancements, a new needs assessment, or lessons learned for future initiatives.
- How it shows up
- A live solution meets all requirements but misses its business objective, and you choose the analyst's next step.
- Common confusion
- Equating successful testing or on-time delivery with realized business value.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Solution evaluation
Assessing whether a solution, before or after deployment, delivers the outcomes and value it was meant to deliver.
- Remember
- Evaluation is measured against the acceptance criteria before release and against the business case after release.
- Tested as
- Most questions in this domain ask which yardstick applies at which point.
- Trap
- Using acceptance test results as proof that business value was achieved.
-
User acceptance testing (UAT)
Testing by business users or their representatives to confirm the solution meets their requirements in realistic conditions.
- Remember
- UAT evidence is compared with acceptance criteria; it is a validation activity performed by the business, with the analyst supporting.
- Tested as
- Appears in task 5.1 scenarios that present test outcomes.
- Trap
- Assuming the analyst performs UAT on behalf of users.
-
Gap vs. delta
A gap is a shortfall between the solution and what was needed; a delta is a difference between what was specified and what was delivered.
- Remember
- Both are communicated with their impact so stakeholders, not the analyst alone, decide how to resolve them.
- Tested as
- Questions ask what the analyst should do when testing reveals a discrepancy.
- Trap
- Fixing discrepancies informally without informing stakeholders.
-
Defect vs. new requirement
A defect is where the solution fails a requirement as specified; a new requirement is something stakeholders now want that was never specified.
- Remember
- Defects go to the defect process; new requirements go through change control and impact analysis.
- Tested as
- A UAT finding is described and you classify it.
- Trap
- Logging an enhancement request as a defect so it bypasses change control.
-
Workaround
A temporary procedure that lets users achieve an outcome despite a known gap in the solution.
- Remember
- Stakeholders may accept a workaround to allow deployment, with the gap tracked for a later fix.
- Tested as
- Appears in go or no-go decisions with minor open gaps.
- Trap
- Treating a workaround as a permanent resolution and closing the gap.
-
Quality assurance vs. quality control
Quality assurance improves and checks the processes that produce the solution; quality control inspects the outputs to find defects.
- Remember
- Task 5.2 names quality assurance tools and methods, which include root cause analysis of why gaps arose.
- Tested as
- Definition questions and scenarios about preventing repeated gaps.
- Trap
- Thinking quality assurance is just running more tests.
-
Root cause analysis of gaps
Investigating why a discrepancy occurred, such as an ambiguous requirement, missing test, or misunderstood interface.
- Remember
- Finding the cause helps decide the fix and feeds lessons learned.
- Tested as
- A recurring type of gap appears across releases, and you choose the analysis that prevents recurrence.
- Trap
- Fixing each symptom without asking why the gaps keep appearing.
-
Solution sign-off
Formal stakeholder acceptance of the developed solution that authorizes deployment.
- Remember
- It comes after evidence review and agreed handling of open gaps, and it differs from the requirements baseline sign-off in Analysis.
- Tested as
- Questions ask what precedes deployment or who must approve.
- Trap
- Deploying on technical readiness alone without business acceptance.
-
Benefits and value realization
Measuring whether the expected benefits in the business case occur after deployment, using the metrics defined earlier.
- Remember
- Benefits often appear months after go-live, so evaluation continues beyond project closure.
- Tested as
- Post-deployment scenarios ask how to judge whether the solution succeeded.
- Trap
- Declaring success on the go-live date.
-
Lessons learned and retrospectives
Structured reflection on what worked and what did not, captured for future initiatives or the next iteration.
- Remember
- Evaluation findings, including root causes of gaps, are inputs to lessons learned.
- Tested as
- Appears as a follow-on action once value shortfalls or recurring gaps are analyzed.
- Trap
- Choosing lessons learned as the first action when the immediate need is to analyze or resolve a gap.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Defect vs. gap vs. new requirement
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Defect | The solution does not behave as the approved requirement specifies | Requirement is clear; the build is wrong | Sending it through change control as if scope changed |
| Gap | The solution falls short of the need or scope, possibly because a requirement was missing or unclear | Needs analysis of cause and stakeholder decision on resolution | Assuming it is always the developers' fault |
| New requirement | A capability stakeholders now want that was never specified | Goes through change control and impact analysis | Logging it as a defect to get it fixed for free |
Requirements baseline sign-off vs. solution sign-off
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Requirements baseline sign-off (3.5) | Approval of what will be built | Happens before development and creates the baseline | Thinking it authorizes deployment |
| Solution sign-off (5.3) | Acceptance of what was built | Happens after evidence review and authorizes deployment | Treating it as a formality once tests pass |
Pre-deployment vs. post-deployment evaluation
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Pre-deployment (5.1 and 5.2) | Comparing test evidence with acceptance criteria and resolving gaps | Yardstick is the acceptance criteria | Claiming business value from test results |
| Post-deployment (5.4) | Measuring actual outcomes against the business case | Yardstick is the business case and value proposition | Re-running acceptance tests to judge value |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Tests passed, so value is proven
- What candidates pick
- Close the evaluation once user acceptance testing passes.
- Why it looks right
- The solution met every requirement, which feels like success.
- Why it's wrong
- Meeting requirements is necessary but not sufficient; task 5.4 measures real outcomes against the business case and value proposition after deployment.
Clue to watch for The stem mentions months after go-live or a business metric such as cost or revenue.
-
New request treated as a defect
- What candidates pick
- Log a stakeholder's new idea from UAT as a defect for the developers to fix.
- Why it looks right
- It gets the stakeholder what they want quickly.
- Why it's wrong
- If the behavior was never specified, it is a new requirement and must go through change control with impact analysis.
Clue to watch for The solution works as the approved requirement states, but the stakeholder now wants something different.
-
Tester's word is enough
- What candidates pick
- Accept a requirement as satisfied because the test was marked passed.
- Why it looks right
- Testers are responsible for test outcomes.
- Why it's wrong
- The analyst validates the evidence against the acceptance criteria; a recorded result that misses the criterion's threshold does not satisfy the requirement.
Clue to watch for The stem gives both the measured result and the criterion, and they do not match.
-
Analyst resolves gaps alone
- What candidates pick
- Quietly adjust the requirement or ask developers to patch the gap.
- Why it looks right
- It avoids delay and stakeholder friction.
- Why it's wrong
- Task 5.2 requires analyzing and communicating gaps so stakeholders can resolve discrepancies; hidden fixes break traceability and trust.
Clue to watch for A discrepancy is found, and one option involves no stakeholder communication.
-
Every gap blocks deployment
- What candidates pick
- Refuse sign-off until every open gap is fixed.
- Why it looks right
- It sounds like the high-quality choice.
- Why it's wrong
- Stakeholders can accept minor gaps with documented workarounds and a plan to fix them; the decision rests on severity, risk and value, not perfection.
Clue to watch for The remaining gaps are minor, have workarounds, and the business needs the release.
-
Lessons learned first
- What candidates pick
- Hold a lessons learned session as soon as a value shortfall is noticed.
- Why it looks right
- Learning from problems sounds responsible.
- Why it's wrong
- First measure the shortfall against the business case and analyze its cause; lessons learned follow once the facts are known.
Clue to watch for The question asks what to do FIRST after a post-deployment metric misses its target.
Answer framework
For an Evaluation question, decide which yardstick applies and who decides, then work through these steps.
- Establish the timing: before deployment the yardstick is the acceptance criteria, and after deployment it is the business case and value proposition.
- Compare the actual evidence or metric with the agreed criterion or target, not with any tester's or stakeholder's opinion of it.
- Classify every discrepancy as a defect, a gap, or a new requirement, and route it to the defect process or to change control accordingly.
- Communicate gaps with their impact and root cause so stakeholders can choose to fix, accept with a workaround, or defer.
- Obtain business sign-off before deployment, then keep measuring outcomes after go-live and feed findings into lessons learned or a new needs assessment.
Practice question
Want more like this? The PMI-PBA practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study Evaluation last, because it draws on everything before it. Before you start, review the business case from Domain 1, the acceptance criteria from tasks 2.6 and 3.8, and the change process from Domain 4; most Evaluation questions are really about applying those artifacts at the end.
The highest-priority skill is comparing evidence with criteria. Practice with measurable criteria and results that sit just above or below the threshold, so you learn to ignore the stated verdict and check the numbers yourself. Next, drill the defect, gap and new requirement distinction with short examples until you can classify each in seconds.
The area candidates most often underestimate is post-deployment evaluation in task 5.4. Make sure you can explain why passing tests does not prove value, which metrics come from the business case, and why measurement may continue after the project closes. Also separate solution sign-off from baseline sign-off.
Afterward, take a mixed practice set covering all five domains, since Evaluation questions often reference earlier artifacts. Review misses by asking which yardstick, acceptance criteria or business case, the scenario called for.
FAQ
How much of the PMI-PBA exam is Evaluation?
Evaluation is the smallest domain at 10% of the exam. That is roughly 20 of 200 items as a planning estimate; PMI does not publish per-domain counts.
Does the business analyst run user acceptance testing?
Usually the business users or their representatives perform UAT. The analyst supports it and validates the resulting evidence against the acceptance criteria.
What is the difference between a gap and a defect?
A defect is where the solution does not do what an approved requirement says. A gap is a shortfall against the need or scope, which may come from a missing or unclear requirement and needs stakeholder decision on how to resolve it.
Can a solution be deployed with known gaps?
Yes, if stakeholders accept them, often with a documented workaround and a plan to fix them later. The decision rests on severity, risk and value.
How is solution sign-off different from requirements sign-off?
Requirements sign-off in Analysis approves what will be built and creates the baseline. Solution sign-off in Evaluation accepts what was built and authorizes deployment.
Why evaluate the solution after deployment?
Tests show requirements were met, but only real-world measures show whether the solution delivered the value promised in the business case. That comparison is task 5.4.
How does Evaluation relate to Needs Assessment?
Needs Assessment sets the business case, objectives and value proposition. Evaluation measures the deployed solution against them, closing the loop.
Other Business Analysis certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
You have covered test evidence against acceptance criteria, gaps and deltas, solution sign-off and post-deployment value. Test whether you can pick the right yardstick at each point in an evaluation scenario.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the PMI-PBA AI tutor Get any concept explained your way