Requirements register

State what the process and any system must do, one testable statement per row, with the reason it is there and the test that proves it.

After the to-be process and the rules. Baseline it before anything is built or bought. Feeds: stories, the BRD, tests, the traceability matrix and the review exercise.

• Write one requirement per row, in the form "The actor shall do something observable", with the slots in italics, because square brackets hold instructions and tags.
• Link the rule, role, process step or decision table it serves.
• Give a priority, and write the reason for it in the next column.
• Write the acceptance criterion in one line, with data a tester can use.
• Mark what is deliberately left out of this release, and why.

1. Can each requirement be tested? Answered in Acceptance column, with a specimen request or a date in most rows; Tested by column, filled from document 18.
2. Why is this a Must? Answered in Priority reason column. The default follows the tag; REQ-01, REQ-02, REQ-11 and REQ-33 are raised to Must, each with its reason.
3. Which rule or need does it serve? Answered in Traces to column.
4. Is a solution hidden in the wording? Answered in Requirement column: "the system" stands for whatever release 1 buys or builds, and no product or screen is named (DEC-14).
5. What is not in release 1, and why? Answered in REQ-35. It is ruled out by DEC-02: release 1 charges nothing (BR-56).

• Every requirement a Must. You can spot it when nobody can say what to drop if time runs out.
• "User-friendly", "fast", "easy": nobody can say how a tester would fail one.
• Two requirements joined by "and": the row needs two test results.
• Copies of rules rather than requirements that enforce them: the row has no actor and nothing anyone could observe.
• No owner: nobody can accept the requirement, so nobody can sign it off.

• The priority follows the tag by default. Must enforces a LAW rule. Should enforces a GUIDE rule or a local rule tagged MINE. Could adds a convenience that no rule asks for, and Won't (release 1) is ruled out by DEC-02. Where two tags meet, the stronger one decides. Every exception is argued in its row. REQ-33, for example, is raised because it is the only requirement that produces the seven statistics the brief uses as success measures. Rejected: priorities by judgement alone, which a reviewer cannot check against anything.
• "The system" is the actor in most rows and names no product (DEC-14). Rejected: writing to one product, which would turn the register into a configuration guide.
• The Tag column carries every tag of the rules a requirement enforces. It adds MINE where the row sets a local control of its own, and OPEN where the requirement itself names an open question and its fallback. The priority follows the strongest tag, and the Priority reason names the rule and its source. Rejected: tagging every requirement MINE because the wording is the analyst's, which would hide which rows the law demands.
• REQ-35 stays in the register as Won't (release 1). The fees and charges in BR-25, BR-38 and BR-67 are law; DEC-02 only decides not to use them now. Rejected: leaving the requirement out, which would hide that the process cannot take a fee if the decision changes.