Requirements register template with acceptance criteria a tester can run

An index, one requirement worked in full (REQ-014), a blank block to copy and six ways acceptance criteria go wrong. Every number tagged with its source.

This is the one people get wrong, and it is the one a reviewer opens first. A stakeholder map can be thin and still pass. A register that nobody can test is the whole document failing quietly, because the failure only shows up weeks later, in a sprint review, when two people disagree about whether something is done.

The job of this file is narrow. Every requirement in it has to survive three questions from a stranger: what does the system do, how would I know it happened, and who said this was a rule.

How to use this file

• Anything in [square brackets] is instruction. Delete it as you fill the field in. Tags in [backticks] are the opposite: they stay in the document.
• Nothing enters this register without a tag saying where it came from. The seven-tag provenance legend is at the top of template 1 and it governs the four templates that hold claims about the business (the stakeholder map, the process, this one and the rule register): [POLICY], [HELP], [THREADS n=10], [WALKTHROUGH], [LAW], [MINE], [OPEN]. A requirement is where numbers get laundered: a threshold you chose on a Tuesday reads exactly like a threshold the business set, unless one of them says [MINE]. The worked example below tags every number it contains, and two of them turn out to be mine.
• The worked example is REQ-014, from the returns case published on analify.com. That case is self-directed and built from public sources. Nobody inside that retailer was asked anything, which is why its sources are policy pages, help centre articles and public complaint threads, and why no field in it cites an interview. It is an example, not client work, and it says so on its own face.
• Copy the blank block at the end once per requirement. Do not invent a new layout for the difficult ones. The difficult ones are exactly where a reader needs the familiar shape.
• Dates are written out in full (9 April 2026), the same way as everywhere else in the pack. One format held everywhere, so that nobody has to work out whether 04-09 is April or September. Inside a tag, where the date is a label rather than prose, the short form is fine: [INTERVIEW 2026-04-14].

Section A. The index

One line per requirement. A reader who never opens the detail should still be able to see what is undecided.

[Keep this table on one screen. If it does not fit, you have either scope creep or a register that is really two registers.]

Priority means something or it means nothing. Must have means the release does not ship without it. If every row says Must, delete the column, because you have not prioritised anything, you have relabelled everything. When you cannot get a decision on priority, that is an open question with an owner, not a guess in a cell. Every row in the example above says Must, which is a smell, and the case it comes from says so on its own face and answers the delivery manager who will ask: it names the one it would cut first and the two it would not.

IDs are permanent. REQ-014 stays REQ-014 for the life of the document. A requirement that dies gets status Withdrawn and keeps its row, with one line saying who withdrew it and when. Renumbering is how you break every comment, test and review note that pointed at the old number.

Section B. One requirement in full, worked

This is the quality bar. Read the criteria and ask yourself whether you could run them tomorrow without phoning me.

REQ-014 - Refund on damaged delivery

Acceptance criteria

1. Photo upload accepts up to 3 files, 10 MB each [MINE]. A fourth file is rejected before upload with a message that names the limit, and the accepted formats are listed on the form itself rather than in a help article.
2. A refund decision is recorded within 48 hours [MINE] of the timestamp on the submitted form, not the moment an agent opens it. If no decision is recorded by then, the case is assigned under REQ-015 and the customer is told who holds it and by when.
3. Partial refunds are permitted only when the order value is above 40 EUR [POLICY] (BR-11). At or below 40 EUR the refund is full or refused, never partial.

Mechanism note (suggestion, not a constraint). The upload can sit on the existing order page rather than on a new screen. I am flagging it as a suggestion so that nobody reads it as a requirement and nobody has to fight me to put it somewhere better.

Open questions

What I did not change, and why. The reviewer asked why the 40 EUR threshold exists and who set it. The number stayed: it is published policy and I cannot improve on it from outside the company. What changed was the silence around it, so criterion 3 carries its tag and its rule id, and BR-11 now carries a rationale marked as an inference with the owner slot left open. The three file, 10 MB limit in criterion 1 is the opposite case, a constraint I chose rather than one I found, kept visible in the criterion so that somebody can argue with me instead of inheriting it. Review log, entry 5.

What makes that row work

• Criterion 2 names the event that starts the clock. The first version said "within 48 hours" and two people read it two different ways, which cost a review. That fix is the whole reason this template exists.
• Every number carries a tag, and behind the tag a rule id or an open question. 40 EUR is [POLICY], held by BR-11. The 3 files at 10 MB and the 48 hours are [MINE]: I chose them, no source gives them, and the register says so on the line where a reader can argue with me instead of six months later in a sprint review.
• The exception path has a person on it. "The case escalates" is not an outcome. Criterion 2 hands the case to REQ-015, and REQ-015 says in as many words that a shared mailbox, a group or a queue does not satisfy it.
• The open questions have consequences. An open question with no fallback is a wish with a due date.

Section C. Blank requirement, ready to copy

REQ-0xx - [Short title. The outcome, not the mechanism.]

Acceptance criteria

1. [Observable behaviour. A tester can run it without asking you what you meant. Scorecard check 02.]
2. [The exception branch. What happens when the thing does not arrive, does not fit, or times out, and who receives the case then.]
3. [The boundary. If a threshold appears anywhere above, say what happens exactly at the threshold, not only above and below it.]

[Three criteria is a healthy target. At seven you are describing a feature, not a requirement, and it should be split. Do not pad to three either: two criteria that answer the three questions beat five that circle them.]

Mechanism note (suggestion, not a constraint). [Optional. Use it when you have an implementation idea you do not want to lose and do not want to impose. Delete the line if you have none.]

Open questions

Section D. Six ways acceptance criteria go wrong

Every one of these has been in a draft of mine. The weak version is the one that gets written at speed, late, when the register is nearly finished and you want it to be finished.

1. The adjective does the work

Weak: The refund status page is clear and easy to understand.

Fixed: The refund status page shows the case state (Received, In review, Decided, Paid), the date of the last state change, and, while the state is In review, the date the decision is due. A customer who returns to the page after a state change sees the new state without clearing the cache.

What changed: nobody can fail "clear", so it protects nobody. Four states and two dates can be checked by a person who has never met you.

2. The clock with no start event

Weak: Refunds are paid within 5 working days.

Fixed: The 5 working day count starts on the day the refund decision is recorded, not on the day the case was opened. Working days exclude Saturdays, Sundays and public holidays in the merchant's country.

What changed: a duration with no "from" is two requirements pretending to be one. The team will pick the start event for you, and they will pick the one that is easiest to build.

3. Only the branch where everything behaves

Weak: When the customer uploads photos, the case is created and sent for review.

Fixed: If the upload fails or is abandoned, the case is still created, in state Evidence missing, and appears in the customer's case list with a prompt to add photos. A case that stays in Evidence missing for 5 working days is closed with a message that explains how to reopen it.

What changed: the branch where the system does not behave got a state, a screen and an ending. Scorecard check 03 asks this of the as-is model. The same instinct belongs in the criteria.

4. A number with no source

Weak: Partial refunds are allowed for orders over 40 EUR.

Fixed: Partial refunds are permitted only when the order value is above 40 EUR [POLICY] (BR-11, published returns policy section 4; rationale unconfirmed, flagged for the rule owner). At or below 40 EUR the refund is full or refused, never partial.

What changed: the number got a tag, a rule id, a source and a boundary. "Over 40" and "40 or more" are different requirements, and somebody is going to build one of them without asking which you meant.

5. The criterion that restates the requirement

Weak: The customer can request a refund online.

Fixed: A customer whose order is inside the published return window sees a Start a refund action on that order. Outside the window, the action is replaced by the reason and the date the window closed.

What changed: the weak version cannot fail, because it repeats the user story in shorter words. The fixed version has a case that passes and a case that does not, and it points at the rule that holds the window instead of copying the number into a second place where it can drift.

6. A design decision wearing the costume

Weak: There is a Start refund button in the top right of the order page, in the brand green.

Fixed: The customer can start a refund from the order without contacting support. Mechanism (suggestion, not a constraint): the action can sit on the existing order page rather than on a new screen.

What changed: the what stayed, the how moved into a line that is explicitly a suggestion. Lock the placement into a criterion and you have decided the design in a document the designer will not read, and made it a breach for anyone to improve it.

The one that nearly made the list

The compound criterion: "the user gets a notification when their order status changes". That sentence hides three decisions, and none of them is written down: which transitions count, what a repeated transition does, and what the opt-out switch actually switches off. When a criterion contains "and", "or", or a plural noun doing a lot of work, split it and see how many you get.

Before you send it

Half a minute per criterion, and it is the cheapest half minute in the project.

Five of the twenty-five checks in the Proof Pack scorecard land on this document:

01 Every requirement traces to a named business rule 02 Acceptance criteria are testable without asking the author 05 Open questions are listed with an owner and a date 13 Every criterion containing a duration names the event that starts the clock 14 Every requirement carries an id, a version and the date it last changed

Template 3 of the Proof Pack, from analify.com. Use it in your own applications and at work, including commercially. Do not resell it as your own product.

In the worked case

Section 4 of the worked case shows this artifact filled to the standard the template asks for: returns and refunds at a mid-size online retailer, built from public sources only, with every number tagged. Read it there, then come back to the blank.

The scorecard checks for this artifact

The numbered list of what the solution must do, written so it can be tested and traced.

All twenty-five checks, with the scoring scale: the scorecard.

Notes that work on this artifact

Next template

All six templates · The worked case · The scorecard