A requirement such as “the system should be fast” cannot be accepted. Acceptance criteria translate it into something verifiable: “Search results appear within two seconds with 1,000 concurrent users.” An opinion becomes a test.
Good acceptance criteria
They are unambiguous, verifiable, independent of the technical solution and written from the user’s perspective. They describe the outcome, not the route. And they cover error cases: what happens with invalid input, missing permission or an interface outage?
Formats
For behaviour, Given-When-Then works well: given a signed-in user without approval rights, when they try to approve an invoice, then they get an error message and the invoice stays open. For properties such as performance or availability, measurable statements with thresholds suffice. For user stories the criteria sit with the story.
Who writes them
The business side formulates them with business analysis support, the development team checks feasibility and testers derive test cases. In requirements engineering following IREB, acceptance criteria are part of validating and agreeing requirements.
Why they prevent disputes
Most conflicts at acceptance arise because client and supplier understood different things by the same requirement. Acceptance criteria agreed before implementation settle that dispute before it arises. How they feed into acceptance is shown in the software acceptance checklist.