How to write software project acceptance criteria
‘The module will work’ is not a measurable delivery condition. Turn business workflows into observable acceptance criteria.
· TankDev Mühendislik
An acceptance criterion states the observable conditions under which a feature is complete. ‘A dealer can place an order’ does not yet say whether pricing is correct, unauthorized actions are blocked, or integration failures remain visible.
Begin with the business outcome
Name the user's role, the action, and the expected business result. Add preconditions, input, and observable output. The implementation language is usually not part of a business acceptance criterion.
A successful order scenario
- Given: An active dealer has an assigned price list and sufficient credit.
- When: The dealer confirms an order with valid products and quantities.
- Then: The server validates authorization and pricing, creates one order number, and presents the result.
Add failures and boundaries
Real usage includes unauthorized users, invalid prices, concurrent requests, missing documents, and unavailable external services. Define the expected result for each important condition. Measure both an understandable message and prevention of the wrong transaction.
Writing a performance criterion
Replace ‘the system must be fast’ with context: concurrent users, data volume, target response time for critical transactions, and the measurement environment. Base targets on actual use rather than a single run on a developer's laptop.
Delivery goes beyond the interface
- Were roles and administrator access handed over?
- Were data export and restore tested?
- Are integration fields and failure states documented?
- Are third-party services and licence responsibilities explicit?
- Are exclusions and later-release requests separated?
Who accepts the result?
A business representative verifies the workflow outcome; the technical team verifies security and integration behaviour. Critical scenarios can use anonymized or synthetic test data. Record the outcome and any agreed deviations.
Our guide to choosing a software company helps compare proposals on equal scope. Share a critical project scenario so the first release can have a measurable boundary.