BRD or SRS: What Changes When Rules Meet a System

BRD vs SRS as one test: swap the system out and see which sentences survive. Run on all 19 rule and criterion lines of one worked case.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece uses the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources, namely a published returns policy [POLICY], help centre articles [HELP], ten public complaint threads I selected myself [THREADS n=10], consumer law [LAW] and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement, no interviews. The case has four business rules and five requirements with fifteen acceptance criteria between them. Below, all nineteen lines go through one test, and the sorting is mine [MINE]: you can repeat it in twenty minutes and disagree line by line.

A business requirements document (BRD) states what the business needs and the rules it runs on, in sentences that stay true whichever system enforces them. A software requirements specification (SRS) states what one particular system must do to meet those needs, in sentences that stop being true the day that system is replaced.

That gives a test you can run on any single sentence: swap the system for a phone line and a spreadsheet, and see whether the sentence still holds word for word.

In short

• The cleanest line between a BRD and an SRS is the swap test. A sentence that survives replacing the system belongs to the business. A sentence that dies with it belongs to the specification.
• In the returns case, seven of fifteen acceptance criteria survive the swap. Only three are pure system sentences. Four split in two, and one is a business decision that only bites once a system exists.
• The swap test found three business decisions that live only inside acceptance criteria, with no entry in the rules register: a 24 hour due date, "never reversed automatically" and "cannot refuse".
• The SRS side adds questions the business side never had to answer: which field, which boundary, which clock, which state. In the case, the first of them came from a developer, not from the analyst.

What is the difference between a BRD and an SRS?

The textbook answer is about audience and level of detail. Wikipedia's article on software requirements specification defines an SRS as "a description of a software system to be developed" that "lays out functional and non-functional requirements". The same article notes that IEEE 830 formalised it and that the ISO/IEC/IEEE 29148 standard "superseded IEEE 830 in 2011". The article on business requirements puts the relation in one line: "Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements."

Correct, and hard to apply to a single sentence like "a refund decision is recorded within 48 hours of the timestamp on the submitted form".

The Business Rules Manifesto gets closer. Article 2.2: "Rules are not process and not procedure. They should not be contained in either of these." Article 4.6: "Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement." Read those two together and you have the swap test. The "how of enforcement" is the system. Take it away, and what is left standing is the business.

The swap test on all nineteen lines

The case has a requirements register and a rules register, and no separate SRS. So the question is where each sentence would go if you had to split it. The swap: the self-service form, the automated pre-check and the goods-in screen are replaced by the phone line, an email inbox and a shared spreadsheet. Same company, same promises.

The four rules all survive. BR-04 (14 day reporting window), BR-07 (five working days), BR-11 (40 EUR threshold) and BR-12 (named person, not a queue) hold with an agent on the phone and a spreadsheet column with a name in it. None of the four mentions a screen, which is the point of a rules register.

The fifteen criteria do not.

The count: seven survive, three die, four split, one is a rule about automation. A register that reads as system requirements is mostly business sentences. That is fine for a case written from outside, with no access to any system, but a delivery team picking it up still has an SRS to write.

What the swap test found that a reread did not

The case has already run the swap on one line. Section 4.1, answering "five must-haves in one release is a smell", cuts exactly one thing if forced: "a scheduled deletion job becomes a diarised manual deletion for release 1, with the same 90 day rule and the same log. The obligation stays, the build shrinks." That is the swap test applied to REQ-016: the obligation survives, the system goes. When a delivery manager asks what can be cut, look at the split lines first.

Three business decisions have no home in the rules register. REQ-015 criterion 2 sets a due date of "the earlier of five working days from submission (BR-07) or 24 hours from assignment". The 24 hours trace to nothing: BR-12 names who holds a missed case, not how long they have. REQ-017 criterion 3 says money already paid "is never reversed automatically", and REQ-018 says the pre-check "cannot refuse". Both decide what a machine may do to a customer's money, and neither has a BR id. REQ-018 traces to BR-04 and BR-11, and neither says anything about refusal.

Scorecard check 01 asks that "Every requirement traces to a named business rule", and every requirement here does. The swap test catches the layer below: a rule born inside a criterion, which whoever edits the criterion will change with no owner, no rationale and no review trigger. Those are exactly the fields BR-11 got after review RL-05.

Two lines are copies, and copies drift. REQ-014 criterion 3 restates BR-11. REQ-015 criterion 1 restates BR-12 and adds the rota. If Finance moves the threshold to 50 EUR, the rule changes and the criterion still says 40. One sentence, two places, one owner. The fix is a reference rather than a restatement, and the case already writes one in REQ-018 criterion 1, which approves a refund "that satisfies BR-04 and BR-11" without repeating either number.

What does the system side add that the business side never said?

A rule applied by a person tolerates gaps, because the person fills them. A rule applied by a system needs every gap closed in advance. The case's own review log has the clearest example.

On 2 April 2026 a developer on the delivery side read REQ-014 "for what a build team would have to test" and asked: "Under 48 hours from what moment?" The first draft never named the start event. Anchoring it to the form timestamp then exposed a second question, clock hours or working hours, which became OQ-04. In the case's words, "One vague sentence was concealing two decisions." That is scorecard check 13, and it is the SRS asking the BRD a question.

Every rule meets the same four questions once it has to be computed. None is new information about the business. They are the rule, made specific enough to run:

Three of these the decision table piece on this site raised already: the carrier's delivery date against the day the box was opened, whether "above 40 EUR" includes 40, and whether order value includes delivery (decision tables). The swap test says where they belong: not defects in the rule, but SRS questions the rule owner answers in a sentence. An SRS that leaves them out inherits them, and whoever writes the code answers them by default.

Where does a sentence go when it splits?

Each half goes to its own document, and the halves point at each other. REQ-016 criterion 1, split:

• BRD: "Uploaded photographs are deleted 90 days after the case closes [MINE, OPEN, OQ-01]. Each deletion is logged with case id and timestamp, and the log outlives the photographs."
• SRS: "A scheduled job deletes photographs of cases closed more than N days ago, where N is read from the retention rule, and writes one log entry per deletion."

The SRS line never contains the number 90. When legal answers OQ-01, one sentence changes and the system follows. The traceability matrix piece walks one change request through a register row by row: every value written twice is one more row to touch.

The rule-to-system sheet, filled in

One sheet per business rule, written by the analyst before handover and read by whoever writes the SRS. Every value comes from the case. "Not stated" means the case does not say.

The rule-to-system sheet, blank

Where is this test weak?

It assumes a system you could swap out. For a rule that exists only because of the system, such as REQ-017's "never reversed automatically", the test has nothing to remove and tells you nothing, which is why the sorting above needed a fourth label. It says nothing about non-functional requirements, which have their own piece. And on a small team two documents can cost more than they save. Then keep one, and mark each line BR, system, or both: the marking does the work, not the file count.

What the test does reliably is catch a business decision before it hides in a system sentence, where the next developer changes it without knowing it was a decision. If your register passes checks 01 and 13 and checks 15 to 18 in the scorecard, run the swap on it next. Eleven edits to a BRD shows the business half written well.

All field notes · The portfolio guide · More in The Document That Gets Read