The first BRD I wrote ran to forty pages. I was proud of it. It had a glossary, a stakeholder matrix, an assumptions register, and an appendix that cross-referenced the appendix. Three weeks later a developer asked me a question the document answered on page 22, and I understood that page 22 does not exist. Nobody reads to page 22.
A requirements document has exactly one job: get a decision out of somebody's head and into a form a developer can build from without guessing. Every page that does not serve that job is a page that makes the useful pages harder to find.
Write the decision, not the discussion
Most bloated documents are bloated because they record the meeting instead of the outcome. The client said this, then finance raised that, then we agreed to revisit. That belongs in your notes. What belongs in the BRD is the settled decision and the constraint that produced it.
Compare these two lines:
After discussion with the operations team, it was determined that the system should ideally handle bulk uploads in a reasonable timeframe.
The system accepts a CSV of up to 5,000 rows and returns a per-row success or failure result within 60 seconds. Rows that fail do not block rows that succeed.
The second one can be built and tested. The first one cannot be tested, which means it cannot be built — it can only be interpreted, and interpretation is how a project ends up with two different versions of the truth.
Every requirement needs an acceptance line
I now refuse to write a requirement I cannot immediately write a test for. If I cannot say what a tester would click and what they would see, then I have not finished thinking, and shipping that sentence to a developer just moves my unfinished thinking onto their desk.
The test is a cheap one. Read the requirement out loud and ask: what would it look like if this were broken? If the answer is vague, the requirement is vague.
Structure for scanning, not for reading
Nobody reads a BRD front to back except the person who wrote it. Everyone else arrives with a specific question and leaves as soon as they have an answer. So the document should be built for arrival, not for narrative.
- One requirement per numbered item, with a stable ID that survives reordering.
- The rule first, the rationale second. If someone stops reading after one line, they should still have the rule.
- Tables for anything with a limit: field lengths, roles and permissions, status transitions.
- Process diagrams for anything with a branch. Prose is bad at "if this, unless that, except when."
Know when to stop documenting and start drawing
There is a point where a paragraph is doing the job of a diagram badly. If the flow has more than two decision points, a reader is now maintaining a state machine in their head while they read your sentence. Draw it in BPMN, put the diagram in the document, and use the prose only for what the diagram cannot carry — the data rules, the thresholds, the exceptions.
The forty-page BRD was not a documentation problem. It was me trying to prove I had done the work. The work shows up somewhere better: nobody has to ask me what page 22 said, because there is no page 22.