Resources · 61
Project acceptance: turn needs into criteria and evidence
Prepare scenarios, expected outcomes, evidence and exception decisions to assess a delivery through tasks actually tested.
· 3 min
What this guide helps achieve
- Start with a task
- Write a testable expectation
- Connect evidence to the scenario
- Resolve exceptions
Quick check
- Who should accept delivery?
- Is an exception a pass?
- Can tests be reused after a correction?
Step-by-step method
- 01
Start with a task
State who needs to accomplish what, in which context and under which constraints. The proposed method draws on GOV.UK service-assessment preparation without treating private acceptance as public certification.
Deliverable: needs and priority journeys.
- 02
Write a testable expectation
Replace words such as fast or intuitive with an observable result and measurement context. Include errors, permissions, language and accessibility. A criterion states what the user obtains, beyond the presence of a feature.
Deliverable: criteria and fictional test data.
- 03
Connect evidence to the scenario
Record version, environment, preconditions, action and outcome for each trial. A screenshot alone does not prove a journey succeeds. Prepare evidence a reviewer can inspect or replay without access to secrets.
Deliverable: reproducible evidence record.
- 04
Resolve exceptions
Define blocking failures, permitted exceptions and owners before acceptance. An accepted exception needs a scope, reason and deadline; it does not turn a failed test into a passing test.
Deliverable: exception register and decisions.
- 05
Close with operations
Test documentation, recovery and support handover too. For AI services, identify limits and ownership. Retain tested scope, open gaps and conditions requiring another acceptance review.
Deliverable: delivery decision and exception follow-up.
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Need | Person, task and context |
| Criterion | Expected result and preconditions |
| Trial | Version, fictional data and observation |
| Decision | Exception, owner and deadline |
Worked example
Illustrative situation
Fictional example: a form submits a case but loses its attachment on mobile.
Decision and expected evidence
Acceptance distinguishes a technical submission from a complete case; the need passes only when the recipient can retrieve the attachment.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Demonstration | Understand a selected journey | Do not treat it as full coverage |
| Business acceptance | Verify tasks and expected outcomes | Include errors and distinct user profiles |
| Technical review | Inspect contract and behaviour | Connect outcomes to user needs |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Covered criteria | Criteria actually exercised | Separate untested, passed and failed |
| Open exceptions | Accepted or blocking gaps | Name an owner and deadline |
| Replayable evidence | Reconstructible scenarios | Record version and preconditions |
Common pitfalls
- Do not treat it as full coverage
- Include errors and distinct user profiles
- Connect outcomes to user needs
Frequently asked questions
Who should accept delivery?
The designated owner of the need, with input from required specialists. Name this responsibility before testing.
Is an exception a pass?
No. It remains a known gap; acceptance is a documented decision within a scope.
Can tests be reused after a correction?
Yes, with stable data and preconditions, naming the new version and potentially affected journeys.
Official references
References consulted on 2 October 2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
