10.2 Acceptance Criteria and Requirements Validation

Task 6: Validate Requirements Through Product Delivery

Domain 4, Task 6 is about proving the solution actually meets the need. Two terms anchor every question here.

Validation vs. Verification

Memory aid: Validation = Value to the customer; Verification = Verify against specs. A solution can pass verification (built exactly to spec) yet fail validation (the spec was wrong). The exam loves this gap.

Trap: in PMI terms, Validate Scope is the customer accepting deliverables (validation), while Control Quality checks deliverables against quality requirements first (verification). Control Quality is normally done before Validate Scope.

Acceptance Criteria

Acceptance criteria are the specific, pre-agreed conditions a product, service, or result must satisfy to be accepted. Good acceptance criteria are specific, measurable, achievable, relevant, and above all testable (an objective pass/fail).

Given-When-Then (Gherkin) format

Used for behavior-driven development in agile:

• Given [precondition / context]
• When [action / trigger]
• Then [expected, observable outcome]

Worked example for a login story:

• Given a registered user is on the login page,
• When they enter valid credentials and select Login,
• Then they are redirected to their dashboard within 2 seconds.

Checklist and rule-based formats

• Checklist: "User can log in with email and password"; "After 3 failed attempts an error appears"; "Session expires after 30 minutes idle."
• Rule-based: "If the order total exceeds 50 dollars, free shipping applies"; "If payment fails, order status becomes pending."

Acceptance Criteria vs. Definition of Done

This distinction is frequently tested. They are not the same.

A story can meet its acceptance criteria yet still be "not Done" if it has not been tested or documented per the DoD.

User Acceptance Testing (UAT)

UAT is the final test stage where end users (or their representatives) confirm the solution works for real tasks in a realistic environment. The typical flow:

1. Define the UAT plan (scope, participants, success criteria).
2. Build test scenarios from acceptance criteria and real use cases.
3. Prepare a realistic test environment.
4. End users execute the scenarios.
5. Log pass/fail and defects.
6. Decide: accept, accept with conditions, or reject.

Testing types compared

Validate Continuously, Not Just at the End

Waiting until UAT to discover the wrong product was built is expensive. Validate throughout.

• Predictive: requirements review and sign-off (planning), design review (design), prototype walkthroughs (build), system test and UAT (test), acceptance sign-off (deploy).
• Agile: story review at refinement, clarification at planning, continuous demos in-sprint, stakeholder inspection at Sprint Review, UAT and formal acceptance at release.

Readiness Assessment Using the RTM / Backlog

Before delivery the team judges readiness from the Requirements Traceability Matrix or product backlog. The RTM is powerful because it links every requirement to its source, design, and test, so it doubles as a completion checklist:

• Every requirement has at least one associated test case.
• Every required test case has been executed.
• All required tests have passed and all critical defects are resolved.
• Traceability runs unbroken from business need to a verified deliverable.

Exam scenario: if 95% of stories pass but one critical acceptance criterion fails UAT, the deliverable is not ready — you do not ship and "fix later." Readiness is gated on the agreed criteria, not on an average pass rate.

Who Signs Off, and How Acceptance Is Recorded

Validation ends in a formal acceptance decision, and the exam expects you to know who makes it. In a predictive project the customer or sponsor formally accepts deliverables, typically through a signed acceptance document at a phase gate or at project closeout; this is the PMI process Validate Scope. In agile, acceptance is incremental: the Product Owner accepts each story against its acceptance criteria, and stakeholders confirm the increment at the Sprint Review.

The three possible outcomes of any acceptance review are the same in both worlds — accept, accept with conditions (minor defects logged for later but the deliverable is usable), or reject (return for rework).

A recurring trap pairs the wrong actor with the activity. UAT and final acceptance belong to users and the customer, never to the developers who built the solution, because self-acceptance defeats the purpose of validation. Likewise, a Quality Assurance team can verify (test against spec) but cannot validate on the customer's behalf — only the stakeholder who owns the need can confirm the need is met.

Quick Reference: Validation Terms

Master the validation-versus-verification split, the acceptance-criteria-versus-Definition-of-Done split, and the rule that critical failures block readiness, and you will answer the large majority of Task 6 questions correctly.