How to Write Acceptance Criteria for Fixed-Scope Software
“A working dashboard” leaves too much to interpretation. Written acceptance criteria describe the input, the expected behaviour and the evidence a reviewer will use to accept a deliverable.
Agree them alongside the scope, exclusions and delivery terms before work starts. They give the project a shared test of completion; they do not guarantee business results or remove every delivery risk.
Give every criterion five parts
Scenario: who is using the system, with which permissions and input?
Expected behaviour: what can that person observe or do?
Pass condition: what must be true, including any agreed threshold?
Evidence: which test, demonstration, output or log records the result?
Reviewer: who accepts it, and when will they check it?
Replace “the integration is reliable” with a specific scenario. The examples below illustrate how to write one; they are proposed checks, not results from a client project.
Example 1: a request approval app
Given a pilot user with requester access, submitting a valid request creates a record with its owner and status. An authorised reviewer can approve it and see the recorded decision. A requester cannot approve it, including through the API.
The evidence is the agreed user journey plus the permission checks in the test environment. Add separate checks for missing required fields and a failed save. State the user roles and screens included so the criterion does not quietly become a whole product specification.
Example 2: an API integration
Given an approved test order, the destination receives the agreed fields once. Repeating the same event does not create another order. If the destination is unavailable, the failure is recorded and the agreed recovery procedure can complete the transfer without duplication.
This scenario matters for event-based systems: Stripe documents that webhook events can arrive more than once. See Stripe's webhook guidance.
Define the tested outage, recovery steps and evidence. Do not turn one successful recovery test into a claim that all future outages are covered.
Example 3: an AI document workflow
Agree the document types, fields, reference answers and scoring method. Reserve representative evaluation examples that are not used to tune the system. For each run, retain the outputs, errors, missing fields and reviewer corrections needed to assess the result.
If you propose an accuracy threshold, specify its denominator, how partial results count and which errors are unacceptable. Agree repeated runs where variability could change the decision. A model's self-reported confidence is not a correctness test.
Check the review path as well: incomplete or unsupported inputs must reach the agreed human review step, and the system must not take an action that requires approval before it receives that approval.
Separate PoC completion from production readiness
A PoC can deliver a runnable experiment and an evaluation showing that the approach is unsuitable. Decide in advance whether the engagement promises an experiment, a measured threshold or both, and what follows if a threshold is missed.
For an operational pilot, scope the required permissions, deployment, monitoring, recovery and support explicitly. Include repository access, setup instructions and handover checks where applicable. A convincing demo does not establish those conditions by itself.
Review progress and changes against the same list
Use the criteria in progress demos. Record passed checks, failed checks and unresolved dependencies. If a new system, language or workflow is needed, write down the effect on deliverables, price and timing and agree the revision before that work begins.
The first draft should be a joint working document: the engineer makes each check technically verifiable, and the workflow owner confirms that it tests the intended business task.
Bring a one-page project brief to that discussion. If the workflow itself is still undecided, start with choosing the first build.
Explore the fixed-scope packages for a starting point with deliverables and acceptance criteria agreed for your engagement.