Acceptance criteria define the conditions a software deliverable must meet before the business can accept it. They turn a requirement from a general intention into something both sides can verify. Without clear criteria, testing and sign-off become arguments about expectation rather than evidence.
Good acceptance criteria describe the business outcome, the relevant role, the starting condition and the expected result. They are specific enough to test without prescribing unnecessary implementation detail.
Start from the requirement and its business purpose
Before writing criteria, confirm what the requirement is intended to achieve. “Add an approval screen” is a design request. “Prevent expenses above the delegated limit from being paid without authorised approval” is a business outcome. The second statement leads to stronger criteria because it explains the control the system must provide.
Each criterion should trace back to a requirement, process step, business rule or risk. If it cannot, it may be an unapproved enhancement or a design preference.
Use a clear structure
A practical criterion can be written in plain language using four parts:
- Starting condition: the state of the record, user or system before the action.
- Role: who performs or attempts the action.
- Action or event: what happens.
- Expected result: the visible outcome, record change or control.
For example:
Given an expense claim above the requester’s delegated limit, when the requester submits it, then the system routes it to an authorised approver and prevents payment until approval is recorded.
The Given/When/Then format is useful but not mandatory. Clear meaning matters more than the label.
Write criteria around behaviour, not interface details
Specify what the user must be able to achieve and what the system must enforce. Avoid deciding button colours, field positions or technical methods unless they are genuinely part of the requirement.
| Weak criterion | Stronger criterion |
|---|---|
| The page has an Approve button. | An authorised approver can approve an eligible request, and the decision, user and timestamp are recorded. |
| The form validates properly. | Submission is blocked when the account reference is missing, and the user is told which field must be corrected without losing other entered data. |
| The report loads quickly. | The agreed monthly report completes within the accepted operating window using the representative data set. |
| The system is secure. | A user without the finance-approver role cannot view or approve restricted payment records. |
Cover permissions and scope
Many acceptance disputes arise because the main action works but the wrong people can perform it. State the role, the records within its scope and what unauthorised users experience.
Include positive and negative criteria:
- a regional manager can approve requests assigned to their region;
- the same manager cannot approve requests from another region;
- a requester cannot approve their own request;
- an administrator can reassign an approval and the reassignment is recorded.
Include business rules and boundary conditions
Criteria should test the values at which behaviour changes. If requests up to a threshold follow one route and higher values follow another, test below, at and above that threshold. Include empty values, maximum lengths, duplicate records and dates at important boundaries.
Do not hide the rule inside one example. Record the rule clearly and use examples as evidence.
Include exceptions and failure behaviour
The normal path is only part of acceptance. Define what happens when:
- required information is missing;
- an integration is unavailable;
- a user loses access during a process;
- a record is changed by another person;
- a notification cannot be delivered;
- a process is cancelled, rejected or reversed.
A criterion should state whether work is saved, blocked, queued, retried or sent for manual review.
Make non-functional criteria verifiable
Performance, accessibility, recovery, audit and support conditions also need acceptance evidence. Avoid unsupported numbers. Define the scenario, environment, data and method of verification.
| Area | Acceptance approach |
|---|---|
| Performance | Run the agreed critical workflow using representative data and load, then record the result. |
| Recovery | Restore the agreed service or data set in a supervised exercise and verify completeness. |
| Accessibility | Complete agreed automated and manual checks, including keyboard use and representative user journeys. |
| Audit | Perform specified changes and confirm the log records the actor, action, time and relevant context. |
| Supportability | Demonstrate that authorised staff can access the agreed monitoring, documentation and administrative functions. |
Keep each criterion focused
A long criterion containing several unrelated outcomes is difficult to test and partially accept. Split it when one part could pass and another fail. Keep related criteria grouped under the requirement so the business can see the complete picture.
A criterion should not become a miniature specification. Supporting rules, data definitions and diagrams can sit elsewhere and be referenced.
Assign an owner and evidence
State who decides whether the criterion has passed and what evidence they will review. Evidence may be a recorded test result, screenshot, export, log entry, restored data set or signed scenario.
The supplier should not be the sole acceptance owner for its own work. The business must retain the decision while using specialist advice where the subject requires it.
Review criteria before development starts
Acceptance criteria expose unclear requirements. If stakeholders cannot agree how a feature will be accepted, development should not begin on the assumption that the disagreement will disappear later.
Review for:
- ambiguous terms such as “appropriate”, “user-friendly” or “as required”;
- missing roles or data scope;
- untested exceptions;
- criteria that depend on an unavailable integration or decision;
- implementation details presented as business needs;
- criteria with no named acceptance owner.
Manage changes transparently
When a requirement changes, update its criteria and record the effect on scope, estimate and tests. Do not quietly expand criteria during UAT to include a newly discovered preference. Classify the finding as a defect, requirement gap or enhancement and make an explicit decision.
A short quality checklist
- Does the criterion trace to an agreed requirement or rule?
- Is the starting condition clear?
- Is the user role and data scope clear?
- Is the expected result observable?
- Are permissions, boundaries and exceptions covered?
- Can the result be tested with available data and systems?
- Is the acceptance owner named?
- Would two reasonable reviewers reach the same pass or fail decision?
Practical next step
Take one important requirement and write criteria for the normal path, an unauthorised user, a boundary value and a failure condition. If those four cases cannot be stated clearly, the requirement needs further work before it is ready for development.