The short answer: decide what evidence earns acceptance
Good software acceptance criteria describe the starting context, actor or system event, observable result, meaningful failure cases, applicable quality boundary, verification method, and authorized decision owner. Write them while the scope can still change—not after a polished demo has become the default answer.
A feature list says what may be built. Acceptance criteria say what must be true for someone to accept it. “Add approvals” is a feature. “A requester cannot approve their own request; an eligible approver sees the decision context; approval records the actor, time, reason, and resulting status” is closer to an observable agreement.
Observable
A reviewer can see the result without guessing
Representative
The data, roles, and failures resemble real use
Decidable
An authorized owner can accept, reject, or defer
Separate story, product, and release acceptance
Teams often overload one checklist. Keep three connected layers so a passing user story is not mistaken for a launch-ready product.
| Layer | Question | Typical evidence |
|---|---|---|
| Requirement | Does this behavior meet the agreed user or system need? | Scenario result, rule example, data change |
| Product quality | Does the change satisfy shared quality boundaries? | Review, regression, accessibility, security, performance |
| Release and handover | Can this version be operated, supported, and accepted? | Migration, monitoring, recovery, runbook, decision record |
The GOV.UK Service Manual describes acceptance criteria as outcomes used to confirm that a service met the user need and recommends linking supporting evidence. That outcome focus is useful even when the team does not use user-story syntax. See its guidance on writing user stories and acceptance criteria.
For a new product, start with the software discovery checklist so acceptance grows from a verified problem and boundary. If a supplier is still being selected, connect the evidence plan to the software development RFP checklist instead of asking vendors to promise a vague definition of done.
Design each criterion with eight parts
Not every criterion needs eight long sentences. The point is to expose missing decisions before they become rework. Use a row, ticket, or scenario that lets a product owner and reviewer reach the same conclusion.
- Purpose: name the user goal or business rule, not merely the screen.
- Context: define starting state, role, data, environment, and relevant permissions.
- Event: state the user action, scheduled event, or external message.
- Outcome: describe what the user or connected system can observe.
- Alternatives: cover consequential invalid, empty, duplicate, timeout, and denied paths.
- Boundary: attach measurable accessibility, security, performance, or data rules where they matter.
- Evidence: agree the method, environment, test data, and retained result.
- Owner: name who verifies and who may accept a deviation.
Use examples without prescribing the implementation
Given–When–Then is useful when it makes a rule concrete, but it is not mandatory. Cucumber's Gherkin reference frames examples as an initial context, event, and expected outcome, and advises keeping outcomes observable rather than describing hidden implementation details. Plain tables and bullet rules can work just as well when the team can verify them.
Illustrative criterion
Given a submitted expense owned by the requester, when that requester attempts approval, then approval is denied, the status is unchanged, and the denied action is recorded for review.
The example still needs representative roles, audit evidence, message expectations, and the owner who decides whether the result passes.
Build an evidence chain, not a screenshot folder
Trace the user need and business rule to scenarios, results, unresolved issues, and the final decision. Evidence can include test output, an inspected record, an accessibility review, performance measurements, migration reconciliation, or a recorded recovery exercise. A screenshot can support a visual observation; it rarely proves the complete state change alone.
NASA's software engineering guidance recommends defining acceptance with the customer up front, planning who performs each activity, comparing obtained and expected results, and documenting deviations and decisions. The scale and rigor in a commercial web project will differ, but the planning principle is transferable. See NASA's acceptance criteria guidance.
Do not convert specialist assurance into a single checkbox. For example, W3C's overview of evaluating web accessibility explains that evaluation uses different methods across design, development, and use; tool results still need human judgment. Scope the relevant journeys, standard, browsers, assistive technologies, reviewers, and evidence rather than writing “accessible: yes.”
Plan entry, exit, and issue disposition before UAT
UAT should confirm representative business use, not become the first time users see the workflow. Before it starts, agree the build identifier, included and excluded scope, environment, test identities, representative data, scenario owners, support route, and blocking conditions.
Give every unresolved issue one explicit disposition:
- Fix before acceptance because the criterion or risk boundary is not met.
- Conditionally accept with an authorized owner, mitigation, due date, and retest.
- Defer because it is outside the agreed release, with the backlog and consequence recorded.
- Reject the change when the value or remedy does not justify proceeding.
Passing acceptance proves the agreed behavior under the tested conditions. It does not prove adoption, revenue, legal compliance, or freedom from defects. Keep those claims outside the sign-off unless separate evidence and qualified review exist.
Use one acceptance ledger from scope to handover
Create the ledger during discovery, update it at milestones, and carry the accepted evidence and open decisions into release and handover. This avoids a second, disconnected UAT document that appears after the delivery team has made most decisions.
Minimum acceptance record
- Release, deliverable, version, and explicit exclusions.
- Criterion, source requirement, risk, and responsible owner.
- Scenario, environment, representative data, and expected result.
- Actual result, evidence link, tester, and date.
- Issue severity, disposition, mitigation, and retest status.
- Final accept, conditional accept, or reject decision.
If ownership and documentation are already uncertain, pair this ledger with the software project handover checklist. For a custom product, Leeonex can help turn the brief into a smaller, testable first version through product ideation and MVP scoping.
Software acceptance criteria FAQ
What should software acceptance criteria include?
Each criterion should identify the user or system purpose, starting context, action or event, observable result, important invalid or failure cases, applicable quality boundary, verification method, evidence location, and authorized decision owner. Product-wide security, accessibility, performance, recovery, and handover gates should be recorded separately and applied where relevant.
Who should write and approve acceptance criteria?
The product or business owner should own the intended outcome, with design, engineering, quality, operations, security, accessibility, data, and integration specialists contributing where risk requires them. The person authorized to accept, reject, or conditionally accept the work must be named before testing begins.
What is the difference between acceptance criteria and a definition of done?
Acceptance criteria describe the observable behavior and boundaries of a particular requirement or deliverable. A definition of done applies repeatable team-wide quality expectations such as review, automated tests, documentation, and deployment readiness. A release can require both, plus broader operational and business acceptance gates.
When should acceptance criteria be written?
Write the first criteria while scoping the work, before the estimate or implementation path is treated as fixed. Refine them as the team learns, but record scope changes explicitly. Waiting until UAT turns acceptance into a search for evidence after the important design and commercial decisions have already been made.
Does passing UAT mean the software is ready to launch?
Not automatically. UAT can confirm that representative users complete agreed business scenarios, but release readiness may also depend on security, accessibility, performance, data migration, monitoring, recovery, support, documentation, ownership, and unresolved-issue decisions. The required gates should reflect the product's actual risk and operating model.