Acceptance criteria describe the conditions a deliverable must meet for the relevant reviewer to consider it acceptable. Write them early enough to guide the work and test them against the user or business need.
Keep the criteria distinct from approval authority. A developer or author may demonstrate that conditions are met while the authorised person still needs to make the acceptance decision.
Begin with the intended use
Identify who will use the output, what task it supports and the requirement it is meant to satisfy. Avoid a criterion such as “easy to use” without explaining how it will be checked. For someone exploring software or systems work, our IT jobs and skills guide gives broader role context for requirements and testing; this exercise should still use the actual project’s review and approval responsibilities.
The GOV.UK Service Manual’s user-story guidance describes acceptance criteria as outcomes connected to user needs. Use that general approach alongside the actual project’s requirements and governance.
Check non-functional and access requirements with the appropriate people. A task appearing to work for one user does not establish every relevant requirement has been met.
A fictional form example
An invented internal room-request prototype is intended to collect enough information for a coordinator to review a request. Possible criteria, subject to the project’s approval, are:
- When required information is missing, the user receives a clear message identifying what needs attention.
- When a valid request is submitted, the system creates the defined received record and reference.
- The received status does not present the room as confirmed before the authorised decision.
- The coordinator can identify the requested date, time and relevant information through the approved access arrangement.
These are fictional requirements for an exercise. They do not describe functionality operated by Brisbane Olympic Jobs or another actual service.
Use a criteria record
Capture:
- Need: the user or business task supported.
- Requirement: source and agreed scope.
- Criterion: observable condition to check.
- Example: valid, invalid or boundary case that clarifies it.
- Evidence: test result, review or other appropriate demonstration.
- Reviewer: person responsible for assessing it.
- Decision: acceptance authority and any unresolved condition.
- Change: version and approval process for revisions.
Keep the criteria independent enough to investigate a failure. A single sentence combining many unrelated outcomes can be difficult to assess or report accurately.
Review ambiguity and edge cases
Ask a user representative, delivery team member and appropriate reviewer to explain the same criterion. If they expect different results, resolve the ambiguity before relying on it.
Include meaningful exceptions, such as a missing date or a request needing clarification, without attempting to list every possible scenario in one criterion. Refer specialist security, accessibility or performance requirements to the relevant competent process.
Avoid making the test merely mirror the current implementation. The output should be assessed against the need and approved requirement, not accepted because it behaves as it was coded.
Keep acceptance traceable
Link criteria to the evidence and actual decision. If the scope changes, review affected criteria through the approved process rather than silently redefining success after a failed result.
A useful set of criteria makes completion checkable and gives the reviewer a clear basis for a decision, while preserving the distinction between a demonstrated result and authorised acceptance.
