“Requirement vs Specification vs Acceptance Criteria”

What is the difference between a requirement, a specification, and acceptance criteria?

requirement vs specification vs acceptance criteria is a key topic in modern project management and teamwork. The one-line distinction worth memorising: requirements are about value, specifications are about decisions, acceptance criteria are about evidence.

How do the three fit together in a real project?

They form a chain that narrows at every step.

A business requirement says the support team cannot reset passwords manually at the current volume. A functional requirement says users must be able to reset their own password without contacting support. A specification says how: token format, expiry, rate limits, email template, audit log entry, and the failure messages for each branch. Acceptance criteria say how you will prove each branch behaves: expired link, reused link, wrong email, third request within the hour, successful reset, and password reuse rejection.

Then tests map to acceptance criteria, one or more per criterion, and a traceability matrix maps tests back to requirements. If a requirement has no acceptance criteria, it is a wish. If an acceptance criterion has no requirement, it is scope creep with good manners.

Two failure patterns follow directly from breaking the chain.

Skipping the specification produces inconsistent implementations: two developers build the reset flow differently, and the support team receives two different audit formats. Skipping acceptance criteria produces arguments at the end, where “done” means whatever the person with the most authority says on that day.

What does each one look like when it is written well?

Concrete examples make the difference obvious, so here is one feature written three ways.

Requirement (business): “Customers must be able to download their invoices for the last 24 months without contacting support.”

Specification (one page, not a novel): the endpoint accepts a date range capped at 24 months; returns a ZIP containing one PDF per invoice; filename pattern `invoice-{number}-{YYYY-MM}.pdf`; maximum 200 invoices per request with pagination beyond that; 30-second timeout; audit log records user, range, and count; permission check requires the billing role; failure returns a specific error code for each case.

Acceptance criteria (four, testable):

1. Given a customer with 14 invoices in the last 24 months, when they request the full range, then a ZIP containing 14 PDFs is downloaded and the audit log records the request.
2. Given a requested range starting 25 months ago, when the customer submits it, then the range is rejected with an error naming the 24-month limit.
3. Given a customer with no invoices, when they request a download, then an empty-state message appears and no file is produced.
4. Given a user without the billing role, when they open the invoices page, then the download action is hidden and a direct request returns a permission error.

Notice what the specification does that the requirement cannot: it decides 200 invoices per request, 30 seconds, filename format. Notice what the acceptance criteria do that the specification cannot: they name observable outcomes, so a tester never has to interpret.

What makes a Given/When/Then criterion actually usable?

A usable criterion names one condition, one action, and one observable result, and it can be evaluated by someone who did not write it. Most bad criteria fail on the third part: they describe internal behaviour, not observable behaviour.

The pattern: if two competent testers could disagree about whether the criterion passed, rewrite it.

Worked example 1: what does one ambiguous word cost?

A requirement says the invoice download “must be fast.” Three interpretations exist inside the same team: under 1 second, under 5 seconds, and “fast enough that nobody complains.” The specification quietly picks 2 seconds on a test dataset of 50 invoices.

In user acceptance testing, the client tests with 2,000 invoices on a shared database and measures 8.4 seconds. The gap triggers a redesign: query optimisation (4 developer days), a background job with email delivery (3 days), and re-testing (2 QA days).

Cost: 7 developer days at $650 = $4,550; 2 QA days at $450 = $900; a one-week delay on a dependent reporting feature, which is the expensive part. Direct rework alone is $5,450, and the stakeholder relationship cost is not measurable in this table.

Now price the prevention. Writing one acceptance criterion — “Given a dataset of 2,000 invoices, when the user requests the maximum range, then the file is ready within 5 seconds or the job is queued and an email is sent within 2 minutes” — takes about 12 minutes and one conversation about the dataset. Twelve minutes against $5,450 is a 450:1 return, and that ratio is why acceptance criteria belong in the requirement conversation rather than the testing phase.

Worked example 2: how many tests do boundaries really need?

Take a discount rule: 0% under $10, 5% from $10 to $49.99, 10% from $50 to $199.99, and 15% at $200 or more. A naive test set covers one value per tier: $5, $25, $100, $250 — four cases, all of which pass while two boundary bugs sit in production.

Boundary coverage adds the edges: $9.99, $10.00, $49.99, $50.00, $199.99, $200.00, plus one value inside each tier. That is 11 cases, and it catches the classic defects: inclusive versus exclusive comparisons and rounding at the tier change.

Run the arithmetic on escaped defects. Suppose two boundary defects reach production because the naive set passed. Each costs 6.5 hours to diagnose, fix, and release — 13 hours at a blended $70, or $910 — plus the customer-facing corrections. The boundary set adds 7 test cases at roughly 20 minutes each, 2.3 hours of QA time, or about $160.

The asymmetry is the point. You are paying $160 to avoid $910 and an unknown reputational cost, with no new tooling and no new process.

Worked example 3: the economics of writing acceptance criteria at all

A 60-requirement release with no acceptance criteria. Review finds that 34% — about 20 items — cannot be verified as written, so they get clarified during development, one conversation at a time.

Cost of the current state: 20 clarification cycles at 45 minutes each, involving a developer, a tester, and a product owner: 15 hours of three people, roughly $2,400 of blended time, spread unpredictably across a sprint. Ten of those items still get built against the wrong assumption, and each wrong assumption costs 6.5 hours in production: 65 hours, about $4,550.

Cost of the fix: write acceptance criteria for all 60 requirements at 12 minutes each: 12 hours, $840 at blended rates, done during refinement rather than as a separate phase. Defects found in review instead of production cost about 0.75 hours each rather than 6.5, so the same ten issues cost 7.5 hours — $525 — and most never reach production at all.

Total: $1,365 invested to avoid roughly $6,950 of avoidable work. Even if only a third of the estimate holds, the ratio survives. That is why “we do not have time for acceptance criteria” is usually a statement about the current sprint, paid for by the next two.

Which one should you write first, and who owns it?

Write the requirement first, but write the acceptance criteria immediately after it — before the specification — because criteria force you to test whether the requirement is actually clear. If you cannot write a pass/fail condition for a requirement, the requirement is not ready, and no amount of specification detail will rescue it.

The specification comes third, and it should be the shortest document that removes ambiguity for the builder. It exists to close decisions: formats, limits, error handling, permissions, performance thresholds. A specification that restates the requirement in longer sentences adds nothing.

Ownership follows the audience. Product owns the requirement, engineering owns the specification, QA drafts acceptance criteria with product sign-off. In regulated or contracted work, all three are reviewed and versioned, because they become the evidentiary record of what was agreed.

What are the most common mistakes?

How do the three map to tools and templates?

The artifacts are cheap to hold in a project tool if the fields exist: a requirement record with an owner and a business justification, a linked specification page, and acceptance criteria as a checklist on the same item. When those three live on separate wikis, the chain breaks the first time someone renames a project.

This is the one place Doitify belongs in this article, and it is our product, so read it as disclosure. Requirements, tasks, sub-tasks, checklists, owners, due dates, and project documents sit in the same workspace as boards, Gantt charts, workload views, and reports. Acceptance criteria work well as a checklist on the task, because a checklist is binary by construction: either the expired-link case was verified or it was not.

The tool does not write better criteria. It only removes the excuse that the criteria were stored somewhere nobody opens.

Do agile teams still need specifications?

Yes, but shorter and later. A user story is a requirement with a placeholder for a conversation; acceptance criteria make the conversation testable. The specification still exists, usually as design notes, API contracts, or a decision log, because someone has to choose the token expiry.

What changes in agile is timing, not existence. Specifications are written just before build, at the smallest useful scope, and they are allowed to be provisional. What must not be provisional is the acceptance criterion for the increment you are shipping this week.

If your team ships weekly and cannot answer “how will we know this is done” in thirty seconds, you do not have an agile process. You have a fast process with no definition of done.

Conclusion

Requirement, specification, and acceptance criteria are three answers to three questions: what do we need, how will we build it, and how will we prove it works. Collapsing them into one document feels efficient and costs more, because the missing precision gets rediscovered by the most expensive person at the least convenient time.

The practical rule is small enough to adopt this week. Every requirement gets at least one measurable acceptance criterion before it is estimated, every specification closes at least one decision the requirement left open, and every criterion names a condition, an action, and an observable result.

Do that and the argument at the end of the project disappears, because nobody has to interpret what “fast” meant.

If this post on requirement vs specification vs acceptance criteria was helpful, you might also enjoy How to Create a Resource Plan: A Step-by-Step Guide for Project Managers and Project Scheduling: The Complete Guide.