Most teams don't argue about requirements. They argue about who broke the build, why the feature "doesn't do what we asked," and whether that was ever written down. Nearly all of it traces back to three words used loosely as if they meant the same thing: requirement, specification, and acceptance criteria. They don't. Keeping them distinct is one of the cheapest quality wins a leader has, no tooling, no budget, just clearer thinking about what each artefact is for.

The quick version

  • Requirement = the need. What a user or the business must be able to do, and why. It owns the problem.
  • Specification = the chosen solution in enough detail to build. It owns the how.
  • Acceptance criteria = the pass/fail conditions that say a specific item is done and correct. They own proof.
  • Write criteria before you build, make them testable, and you turn "is it finished?" from an opinion into a checklist.

The idea in depth: three artefacts, three jobs

Start with the requirement. A requirement states a need independent of any solution, "a café owner must be able to post a job and receive applications", not the screens or the database. The classic reference is Karl Wiegers, whose Software Requirements is a standard text for business analysts. Wiegers lists the characteristics of a good requirement statement: complete, correct, feasible, necessary, prioritised, unambiguous, and verifiable (Wiegers, "Writing Quality Requirements"). Two of those do most of the work. If a requirement is ambiguous, two people read it two ways and only find out at demo. If it isn't verifiable, you can't ever prove you met it, which is the quiet root of endless "is this done?" debates.

So run every requirement through one question before it leaves the page: how would we test that this is true? If you can't answer, the requirement is still vague, and no amount of careful building will rescue it. That single habit pulls the verifiability check forward to the cheapest possible moment, before anyone writes code.

In modern product teams the requirement usually arrives as a user story, written in the "As a [role], I want [capability], so that [benefit]" template. That format is older and more deliberate than it looks: it originated around 2001 at a UK firm, Connextra, credited to agile coach Rachel Davies and colleagues, and was popularised by Mike Cohn's User Stories Applied (2004) (Cohn, Mountain Goat Software). The "so that" clause is the part people drop and the part that matters most, it carries the why, the thing that lets a team push back on a bad solution. A story without its benefit is a feature request wearing a costume.

How do you tell a good story from a wish? Bill Wake's INVEST checklist, from a 2003 article, is the durable answer: Independent, Negotiable, Valuable, Estimable, Small, Testable (Agile Alliance, "INVEST"). Note where it lands again: testable. A story you can't test is a story whose "done" is a matter of opinion. Treat that T as a gate, not a nicety, if nobody in the room can describe the test, the story isn't ready to start.

flowchart TD
    R(["Requirement / user story<br/>the NEED, what & why"]) --> S(["Specification<br/>the chosen HOW, enough to build"])
    R --> AC(["Acceptance criteria<br/>the PROOF, pass/fail per item"])
    S --> B(["Build"])
    AC --> T(["Test / demo<br/>accepted or not"])
    B --> T
One need, one solution, one set of proofs. The requirement owns the problem; the spec owns the how; the criteria own done. Leaders Loop

Acceptance criteria: turning "done" into pass or fail

This is where the three artefacts most often collapse into one, and where keeping them apart pays off most. Acceptance criteria are the specific, checkable conditions a single story must satisfy to be accepted. They are not the spec (the spec can describe a great deal the criteria never check) and they are not the requirement (the requirement is the need; the criteria are its proof).

The most useful format came out of behaviour-driven development. Dan North, in his 2006 article Introducing BDD (first published in Better Software magazine), set out the Given / When / Then structure for writing a scenario: Given some starting context, When an event happens, Then ensure some outcome (North, "Introducing BDD"). North co-developed the template with Chris Matts, and its point is precise: it forces a criterion to name a concrete situation and a concrete observable result, which is exactly what makes it testable. "The form should be intuitive" reads very differently from "Given a new user with no saved address, When they reach checkout, Then the form pre-selects their billing country from their IP." Only one of those can fail a test.

"Given some initial context (the givens), When an event occurs, Then ensure some outcomes.", Dan North, Introducing BDD (2006)

So write acceptance criteria as scenarios, before the build, and with the people who'll implement and test them. Gojko Adzic's Specification by Example (2011), drawn from around fifty teams, makes the case that concrete examples agreed across roles become both the shared understanding of what to build and the basis for the tests, "living documentation" that stays true because it's executed (Adzic, Specification by Example). The deeper benefit isn't the document; it's the conversation it forces. Writing "Then what, exactly?" surfaces the edge cases, the empty state, the duplicate, the timeout, while they're still cheap to resolve on a whiteboard rather than expensive to find in production.

One distinction worth holding, because it causes real arguments: acceptance criteria are not the same as a Definition of Done. Criteria are specific to one item, what this story must do. A Definition of Done is a blanket quality bar that applies to every increment: tested, documented, accessible, deployed. Notably, the Scrum Guide defines Done but says nothing about acceptance criteria, the criteria are a complementary practice teams adopted, largely from Extreme Programming (Scrum.org, "Definition of Done vs Acceptance Criteria"). A story can meet every acceptance criterion and still not be Done because it skipped the team's universal bar, and vice versa. Keep both; don't merge them.

An honest limitation: more words is not more clarity

It's worth being candid about the failure mode of taking all this too seriously. The discipline above can curdle into bureaucracy: a hundred-page specification nobody reads, or a story buried under thirty acceptance criteria that took longer to write than the feature took to build. Wiegers himself frames quality as fitness for purpose, not exhaustiveness, and agile's whole reaction to heavyweight requirements was that detailed up-front specs decay because the world changes faster than the document. Criteria written too early, at too fine a grain, lock in guesses you haven't tested yet.

There's a second trap. Acceptance criteria verify that the system does what you specified. They cannot tell you whether you specified the right thing. A feature can pass every Given/When/Then and still be unwanted, because the underlying need was wrong. That's not a job for criteria; it's a job for discovery and validation and a clear read on customer needs. So treat criteria as proof of correctness, never proof of value, and keep them light enough to change when the evidence does.

A worked example

Take a fictional team, call it RotaPay, building payroll software for very small businesses. (The figures and scenarios below are illustrative, used to show the mechanics, not real data.) A stakeholder drops a line in the backlog: "Let users approve timesheets faster." The team builds a bulk-approve button, demos it, and the stakeholder says it's wrong. Nobody is lying; the line was a requirement, a spec and the criteria all mashed into seven words.

Pull them apart. The requirement, as a story: "As a café owner, I want to approve a week of timesheets in one action, so that payroll runs on Friday without me checking each entry." Now the why is visible, Friday payroll, not "faster" in the abstract. The specification decides the how: a select-all checkbox on the weekly timesheet view, with a confirm step, and approvals written to the payroll ledger. The acceptance criteria say when it's correct, as scenarios:

flowchart TD
    G1(["Given a week with<br/>3 pending timesheets"]) --> W1(["When the owner<br/>clicks Approve all"])
    W1 --> T1(["Then all 3 are approved<br/>and locked for edit"])
    G2(["Given one timesheet<br/>has missing hours"]) --> W2(["When the owner<br/>clicks Approve all"])
    W2 --> T2(["Then it is skipped<br/>and flagged, others approve"])
Two scenarios that can pass or fail. The second, the edge case, is the one the original seven-word request never mentioned. Illustrative. Leaders Loop

Writing that second scenario is the whole point. The moment someone asks "what happens to a timesheet with missing hours?", the team has caught a decision that would otherwise have surfaced as a production bug and a payroll error. The criteria didn't just describe the work; writing them found the gap. And because the requirement kept its "so that," the team can check the spec against the real goal: does a bulk approve that skips broken entries still get payroll out on Friday? Yes, so long as the skip is visible. That visibility is now a written criterion, not a hope.

Frequently asked questions

What's the difference between a requirement and a specification?

A requirement states the need, what a user or the business must be able to do, and why, independent of any solution. A specification states the chosen solution in enough detail to build it. One requirement can be met by several possible specs; keeping them separate stops you from locking into a design before you've agreed on the problem.

Are acceptance criteria the same as the Definition of Done?

No. Acceptance criteria are specific to one story, the conditions that item must meet. The Definition of Done is a universal quality bar applied to every increment (tested, documented, deployable). The Scrum Guide defines Done but not acceptance criteria; the criteria are a complementary practice, mostly inherited from Extreme Programming. You want both.

Who should write acceptance criteria?

Not one person alone. The strongest results come from a short conversation across roles, product, engineering, and whoever will test it, before the build starts. That's the core of specification by example: agreeing concrete examples together surfaces edge cases early and means the criteria double as the test plan.

How detailed should acceptance criteria be?

Detailed enough that pass or fail is unambiguous, and no more. If a criterion can't fail a test, it's a comment, not a criterion. But if you're writing thirty of them for one story, the story is probably too big, split it. The aim is clarity, not volume; over-specifying early just locks in guesses you haven't validated.

Do acceptance criteria prove we built the right thing?

No, only that you built the thing you specified, correctly. A feature can pass every criterion and still be unwanted because the underlying need was wrong. Proving value is the job of discovery and validation and usability testing, not of acceptance criteria.

Related in the Toolkit

Where to go next