Acceptance criterion
A condition that must hold for a requirement to count as met. It turns "done" from a feeling into a check.
What it is
An acceptance criterion states, in terms anyone can check, one situation the requirement must handle and the result expected. A requirement usually has several: the normal case, the limits, the errors.
A common form is Given … When … Then …: given a starting situation, when something happens, then this is the result.
Why it matters
Criteria are where people agree what "done" means before work starts, not after it is shipped. They expose the edge cases while they are still cheap: what happens one minute past the limit, with a taken slot, with no connection.
They are also what tests are written against, which is how a requirement becomes provable.
What goes wrong without it
- "Done" means different things to the developer, the tester and the product owner.
- Edge cases are decided in the code, by whoever writes it, without anyone noticing.
- Arguments after release about whether something is a defect or a new request.
- Tests check what the code does, not what the requirement needed.
What it gives an AI agent
Criteria are the most useful thing you can give a coding agent. They tell it exactly which cases to handle, and they give it something to prove: an agent that must turn each criterion into a passing test cannot quietly skip the hard case.
They also protect you from an agent's optimism. "All done" means little; "AC1 and AC2 Met, verified by these tests" can be checked.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Moving appointments works correctly. | AC2 — Given an appointment that starts in 1 hour, when the patient tries to move it, then the change is refused and the patient is asked to call the clinic. |
The requirement "move up to 2 hours before" gets one criterion for the allowed case, one for the refused case, and one for a slot that is already taken.
How it relates to the rest
- Belongs to exactly one requirement (or constraint) and gets a code from it, e.g. FR-5C0A71/AC2.
- Tests verify criteria; stories and defects cover them.
- When the requirement changes, its criteria are reviewed with it.
In Corpole
- Requirement types (BR, SR, FR, NFR, TR, PR) need at least one criterion before they can be Approved or Authority.
- Each criterion is Not verified, Met or Not met. A linked active test decides it automatically; a person can decide it too.
- An agent's own report marks a criterion Met but unverified until a person or a test confirms it.
- Changing a criterion's wording resets it to Not verified, because the old proof no longer applies.