Acceptance criteria
Define observable conditions for a deliverable to be accepted.
The idea
Acceptance criteria state what a result must satisfy for the appropriate owner to accept it. They should be specific, testable, and linked to the intended outcome. Include functional, security, operational, and accessibility needs where relevant. Agree criteria early and refine them transparently as requirements change. They are different from merely reporting that implementation work finished.
In practice
A knowledge library’s criteria include working concept links, usable mobile navigation, valid metadata, readable content, and a repeatable publishing process.
A common misunderstanding
“Looks good” can be useful feedback, but it is not a sufficient criterion for important security behavior.
Check your understanding
Who should accept a deliverable?
Think it through: The designated owner or authority who can evaluate the agreed criteria and take responsibility for the result.
Replace adjectives with observable conditions
Acceptance criteria describe what a particular deliverable must satisfy for the relevant stakeholder to accept it. Words such as secure, fast, and user-friendly express intentions but leave room for disagreement. Translate them into conditions that can be evaluated in the actual environment. Some conditions require a test; others require an approved record, a demonstration, or an operational handoff.
For an administrator access workflow, useful criteria could include rejecting an unapproved request, recording the approver, limiting the granted role, and allowing the service owner to review current access. The exact conditions depend on the intended use and risk. Avoid prescribing a specific implementation unless that technology is genuinely required. The criterion should usually describe the result.
A fictional late disagreement
A team demonstrates a new backup configuration and expects acceptance because scheduled jobs succeed. The application owner expected proof that the service can be restored to usable operation. Both parties used the word working while meaning different things. Agreeing on restore validation before implementation would have exposed this difference when it was cheaper to resolve.
Acceptance is also distinct from general quality requirements. A shared Definition of Done can apply across many deliverables, while acceptance criteria describe the particular behavior of this one. A feature might satisfy its functional example yet still fail the team's required review or documentation threshold. Both perspectives can be necessary.
Write a testable condition
Take the phrase alerts should be useful and rewrite it for a fictional administrator sign-in alert. Specify the event, the information available to the responder, and the expected routing. Include one negative case, such as an approved test event that should be handled according to a documented rule. Ask another learner to explain how they would decide whether each condition passed.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
UK Government: Project Delivery Functional Standard