Business requirements document

Give a sponsor one short document to approve. It explains why the work is needed and points to the registers for the detail, rather than copying them.

At the baseline, and again at each approved change. Inputs: every register. Feeds: sign-off, and the build or purchase that follows it.

• Write the first page for the sponsor: the problem, the decision asked for and what changes.
• Summarise the scope, the rules, the requirements and the quality needs in a few lines each, with links to the registers.
• Quote a rule only in the exact words, ID and tag it has in the rules register.
• List the decisions that shaped the document.
• List what is still open at sign-off, with the fallback for each.
• Keep a change history, and say which change request made each version.

1. Can a sponsor read the first page and know what they are approving? Answered in Summary for the sponsor: the problem, the five changes, what is left out, what is open and what changed in version 1.1.
2. Where is the detail kept? Answered in The links in each section: 04 for roles, 09 for rules, 11 for requirements, 13 for quality needs, 14 for decisions and questions, 15 for risks.
3. What changed since the last version? Answered in Document control and the last part of the summary: CR-01, approved under DEC-15.
4. What is still open at sign-off? Answered in Open questions at sign-off: OQ-01 to OQ-09, each with an owner, a due date and a fallback.
5. Who approved what, and when? Answered in Approval: STK-06 signed off version 1.0 at the baseline and approved CR-01, which made version 1.1.

• Copying every register into the document. You can spot it when the document is longer than the registers it summarises, and the two disagree after the first change.
• No version history: nobody can say which version a sponsor signed.
• Signing off with open questions hidden: an answer arrives after sign-off and changes something the sponsor thought was settled.
• No reasons for the choices: a decision in the document cannot be traced to a decision log entry.
• A first page written for the team, not the sponsor: the first page has rule numbers but no decision to make.

• The document is short and points to the registers. It gives counts and a few rules here, and every rule and requirement stays in 09 and 11 (BR-01 to BR-67, REQ-01 to REQ-37). Rejected: copying the registers in, which would make two versions of each to keep in step.
• The rules quoted here keep the exact words, ID, tag and source they have in the rules register, so a reader can check one against the other. The sponsor's page carries IDs only; the tags and clauses start on the next page. Rejected: rewording rules for the sponsor, which is how a summary starts to drift from the register.
• Version 1.1 changes only what CR-01 names, and everything else stands as signed off at the baseline (DEC-15). Rejected: a new sign-off of the whole document, which would reopen settled points for a change of name.
• The open questions are listed at sign-off with their fallbacks, OQ-01 to OQ-09, so the sponsor approves knowing what is not yet known. Rejected: waiting until every question is answered, which would hold the work on people outside the analysis.