Eleven Edits That Make a BRD Worth Reading

What a BRD is for, and one fragment of one shown twice: the way it usually arrives, and after eleven edits, with the objection each edit still takes.

"The current returns process is inefficient and causes customer dissatisfaction."

I have read that sentence, or one built to the same pattern, in more requirements documents than I want to count. It is not false. It is just not evidence of anything. Anybody can write it after ten minutes on the company website, which is the problem when the document is attached to a job application.

A business requirements document, a BRD, is the document that says what a business needs to change, why, and how anyone will know the change worked. Every line in it is meant to be checkable by somebody who was not there when it was written.

One limit before any of this is worth reading. I have never sat on the hiring side of the table, so I cannot tell you what happens to your document once it is submitted. What I can describe is the thing I actually do: pick up a document written by a stranger and decide, inside two minutes, whether I trust the person who wrote it. That happens on international projects, and again with the work people send me on the Polish training platform I run. Whether the first screen of a recruitment process works the same way is a guess, and it is the only claim here I cannot back.

In short

• The first version of the fragment below cannot be argued with, and that is the whole problem: not one sentence in it had to be checked with anybody.
• Count the problem instead of describing it, then say what the count is not, because four of ten complaint threads I selected myself is a count and never a rate.
• Give every business rule a source, and leave the owner slot open when no public source names one rather than filling it in with a plausible job title.
• Two of the eleven edits do most of the work in the first thirty seconds of reading: a counted problem statement, and a scope section with a reason beside every exclusion.

Who reads a BRD, and what are they looking for?

Your delivery team reads a BRD to build something. They need it complete. They will read every page, badly, over several weeks, and they will come back to you about the gaps because they have to.

A stranger deciding whether to interview you reads three paragraphs and stops. They are not auditing the document. They are looking for traces of thinking: whether you asked anyone anything, whether you noticed two rules contradicting each other, whether you wrote down what you did not know. Nobody is checking your BRD for completeness, and completeness is the cheap half anyway.

Complete and thought-through are not the same thing, and a document can be all of the first and none of the second. Most of what people send me has exactly that shape: every heading from the template present, and not one sentence that had to be earned.

What follows is a fragment of the worked case I publish here: returns handling at a mid-size retailer. There was no engagement and no client. Everything in it is built from published policy, help centre articles and public complaint threads, and every line says which. Read the numbers as a method, not as a finding about retail.

The fragment, the way it usually arrives

3. Business need

The current returns process is inefficient and causes customer
dissatisfaction. Customers must call support to request a refund,
which generates a high volume of calls and increases operational
costs. The business requires a modern, user-friendly solution to
streamline the returns process and improve the customer experience.

4. Scope

In scope:  refunds, returns, notifications, reporting.
Out of scope: TBD.

5. Requirements

BR-1  The system shall allow customers to request a refund online.
BR-2  The system should process refunds quickly.
BR-3  The system must be user-friendly and intuitive.

Nothing in there is wrong. Nothing in there can be argued with either, and that is the tell: no sentence in it had to be checked with anybody.

The same fragment after eleven edits

3. Business need

3.1  Four of the ten damaged-delivery complaint threads I read
     end with no named person owning the case after the first
     contact. Source: ten public complaint threads I selected
     and read between 12 and 21 March, with their dates. This
     is a count of the ten threads I chose, not a rate across
     all cases, and the true frequency cannot be known from
     outside until somebody measures the queue.

3.2  We are not trying to reduce the number of refunds. We are
     trying to reduce the number of cases with no owner and no
     clock. If refunds fall, that is a side effect I want to see
     explained, not celebrated.

3.3  This work is finished when the share of damaged-delivery
     cases sitting with nobody's name on them, once the queue is
     measured at all, stays under one in ten for two consecutive
     months, with the refund rate flat within one percentage
     point.

4. Scope

In scope:      damaged-delivery refunds for web store orders, from
               evidence upload to refund decision.
Out of scope:  change-of-mind returns (separate published policy,
               separate rules), marketplace orders (different
               terms, outside the returns policy), the accounting
               posting itself (unchanged by this work).
Not decided:   whether partial refunds ship in this release.
               Owner: Head of Customer Care, role identified,
               person not named in this case. Needed by
               30 April 2026. If nobody answers: out of
               release 1.

5. Business rules

BR-07  No refund case may stay open longer than five working days.
       Source: the help centre, which says the company aims to
       resolve returns within five working days. "Aims to" is not
       a rule, so the status stays open until somebody says which
       it is, and no public source names who owns the sentence.

BR-11  Partial refunds are allowed only above 40 EUR order value.
       Source: the same policy and two help centre articles, all
       three wording it identically. Rationale not published.
       My inference, marked as one: below 40 EUR the handling
       cost of a split refund plausibly exceeds what it recovers.
       I have no cost data. The inference and what would settle
       it sit in the rule register, for the rule owner to confirm
       or kill.

BR-12  A case that misses the decision window is assigned to a named
       person, not to a queue. Traces to BR-07: a deadline with no
       owner is a deadline nobody keeps and nobody breaks.

Note on the clock: the 48 h window in REQ-014 runs from the
timestamp on the submitted form, not from the moment somebody
opens the case.

Same document, same case. One version tells you nothing about its author. The other is hard to fake without having done the work.

The eleven edits

Five of them carry a note in the margin: the objection that edit has actually taken in review, next to the edit it hit. A clean list of improvements is the half that proves least.

1. Counted the problem instead of describing it. "Inefficient" is an opinion nobody can check. "Four of the ten threads I read" is a claim someone can repeat in twenty minutes and disprove, which is what makes it worth reading.

Objection I take on this one: "It reads like a data report now, and a director will not find the ask." Correct. In the full document one sentence sits above 3.1 saying which decision I want and by when. I left it out here to keep the contrast visible, which is a small dishonesty worth naming.

2. Named the source, the selection method and the denominator, and said what the number is NOT. A number with nobody attached to it is a rumour with a decimal point. A count dressed up as a rate is worse, because it survives the first challenge and collapses at the second.

Objection: "Ten threads you picked yourself are not a sample of anything, so why print the figure at all?" The stronger version of that is to cut the figure and say only that cases end up with nobody's name on them. I kept it, because a labelled count with a stated method can be rechecked by a stranger in twenty minutes and a shrug cannot. The disagreement is in the review log rather than resolved quietly in my favour.

3. Wrote down the anti-goal. Saying what I am not trying to improve stops the team optimising the one metric that would make the business worse.

4. Put the success condition next to the problem. A document that never says when the work is finished produces a project that ends when somebody gets tired.

5. Cut the solution language out of the business need. "Modern, user-friendly solution" names an answer before the scope is agreed, and every hour after that goes into defending it rather than testing it.

6. Replaced "Out of scope: TBD" with named exclusions and a reason for each. When I see TBD in a scope section I stop reading for content and start reading for who the author has spoken to. Usually the answer is nobody.

And here is the objection to the whole approach: somebody writing a portfolio piece has spoken to nobody either, and has no Head of Customer Care to name. True, and in this case it is deliberate: the entire study is built from public sources so that it can be published. Then say exactly that inside the document. "Public sources, listed, selection method stated" reads as competence. A borrowed logo and an invented stakeholder name read as something else, and I have seen both.

7. Split "not in scope" from "not decided yet", and gave the undecided item an owner and a deadline. They look similar on the page and behave nothing alike in a project, because one of them is coming back.

8. Replaced "quickly" with a threshold and the event that starts the count. Most of the argument about a deadline is never about the number. It is about which moment it runs from, and the vague version hides that there is a choice at all.

9. Deleted BR-3. "User-friendly and intuitive" is a requirement nobody can fail, so it protects nobody and takes up a line.

10. Gave every rule a source, and left the owner slot open where no public source names one. A rule with a name on it can be renegotiated. An anonymous rule can only be worked around.

    Objection: "An empty owner field is not an owner, so this edit does less than you claim." Fair. What it does do is keep the field visible, so the first person with access to the company fills it in from a person instead of from a guess. Writing "Finance" there because it sounds right would have been an invented fact wearing a name badge.

11. Wrote down the reasoning behind the 40 EUR threshold, marked it as my inference, and said where the working lives. The number is the least interesting part. The argument behind it is what stops it being changed in a corridor six months later.

    Objection, and I have earned this one more than once: "The line pointed at an appendix nobody had written." Guilty, which is why it now points at the rule register, where the reasoning actually sits. A citation to a document that does not exist is worse than no citation, because it buys trust the document has not earned.

There is a twelfth change I did not count, because it is a habit rather than an edit: the rules are numbered to match the register, so a reviewer's comment lands on one line instead of a paragraph.

Where should you start if you have one hour?

Take a document you already have and do edits 1 and 6 on it: a counted problem statement, and a scope section with a reason beside every exclusion. Give it an hour. In my experience those two change the first thirty seconds of the reading more than the other nine together.

The rest of the standard I hold myself to is on this site: the scorecard is twenty-five checks across six artifacts, versioned, free and with no email address asked for. The case this fragment comes from is in the Proof Pack, finished, with the review notes left in. If you want the requirement these numbers end up in, that is in the six artifacts piece.

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