BRD, FRD and SRS: which document is needed when

The client signs the document and believes they have fixed what the product will be. The team reads the same document and sees goals in it: what we actually want to change. A month later both say “but it was in the requirements” and “it was never there” — about the same file.

BRD, FRD and SRS are three different documents for three different readers and three different moments in a project. The BRD explains to the client and the sponsor why the change is worth starting. It comes first, before any solution is chosen. The FRD tells the team what the system must do, and it is written once the solution has been chosen. The SRS answers those who build and verify: how exactly this must work so it can be implemented and a test can be written. That is the whole answer; the rest is detail.

The details matter because three-quarters of the confusion in an interview is not about these three lines. Everyone knows them. People stumble on something else.

The confusion starts with the word “business requirements”

The most common answer I hear: “A BRD is business requirements.” It sounds logical, the letters match. And it is a substitution from which everything else grows.

Business requirements are a type of requirement. A BRD is a document. In the BABOK guide, requirements are divided by type. There are business requirements (the goals and outcomes for which the change is undertaken), stakeholder requirements, solution requirements — functional and non-functional — and transition requirements, which are needed only during the transition and die off after it. None of these words names a file. It is a classification of content: what exactly you wrote down, not where.

Then it becomes clear where the trap is. A single document can easily hold several types at once. In a normal BRD, stakeholder requirements live next to the goals. In an SRS, non-functional ones sit beside the functional ones. And conversely, a single type of requirement is spread across three documents. So the question “which document holds business requirements” has no single answer. The question “which document answers the client’s question of why we are doing this” does.

If in an interview you move the conversation from files to requirement types and back, the difference between candidates becomes audible immediately. One retells three abbreviations. The other explains who reads what.

What the standard says — and what it does not say

Here begins the unexpected part that the conversation usually does not reach.

The international standard for requirements work — ISO/IEC/IEEE 29148

— does describe requirements documents. In section 8 there are four of them: the business requirements specification BRS, the stakeholder requirements specification StRS, the system requirements specification SyRS and the software requirements specification SRS. An example structure is given for each.

Do you notice what is not in this list? BRD and FRD. They are not there at all.

Of the three abbreviations around which the argument revolves, the standard knows one — SRS: its outline sits in section 8.5. The definition, though, belongs to a neighboring document — the system requirements specification SyRS: a structured collection of requirements — functions, performance characteristics, design constraints and other attributes — for the system, its operational environments and external interfaces. BRD and FRD are industry practice: names that companies and consultancies agreed on, not terms from the guide.

Hence the practical takeaway worth carrying with you. Asking “what is the correct way to format a BRD according to the standard” is pointless — no correct answer exists. In every company a BRD means something slightly different. On a new project, ask what the word means here. Do not assume.

By the way, about the “correct SRS template”. It is often taken from IEEE 830 — a 1998 document still taught in courses. On the IEEE website this standard has the status Superseded: it was replaced by ISO/IEC/IEEE 29148 back in the 2011 edition. The template did not become bad, but citing it as a current standard is a noticeable mistake.

Three documents across five questions

A comparison table of “what is the difference” appears in every other article, and it is of little use: it answers the examiner’s question, not yours. So let us go through each document across five questions that come up in real work. The fifth is the main one, and it is usually not asked.

BRD

Who writes it: the business analyst together with the client or the sponsor of the change. Who reads it: those who provide the money and make the “do it or not” decision. What decision it closes: whether this is worth undertaking at all, and how we will know it worked. When it appears: before all the others, before the solution is chosen. If the document already names a system, you are not writing a BRD. What is missing without it: the criterion by which, six months later, one can say the project succeeded. Without a BRD, success is determined by the client’s mood at the demo, and there is nothing you can argue against.

FRD

Who writes it: the analyst, already knowing which solution has been chosen. Who reads it: the development and testing team, sometimes the client who wants to check they were understood. What decision it closes: what the system must do for the goals from the BRD to be achieved. When it appears: after the decision on the solution, before effort estimation. What is missing without it: the boundaries of the scope of work. An estimate without an FRD is an estimate of what each meeting participant imagined for themselves, and the discrepancy will surface at acceptance.

SRS

Who writes it: the analyst together with the architect or a developer. Who reads it: those who build and verify: development, testing, integrators. What decision it closes: how this must work so it can be implemented and verified. When it appears: before implementation, and it lives longer than the previous two — it is updated as long as the system is alive. What is missing without it: the ability to write a test case without going to the author. Every ambiguity turns into a question in a chat, and the answer to it is not saved anywhere.

The fifth point is the one that distinguishes a person who has maintained documents from a person who has read about them. “What breaks if this document is missing” cannot be learned; it is only visible from practice.

Two ways to ruin all of this that I see most often

The documents drifted apart. This does not happen out of laziness. The documents have different readers and different speeds. The upper part changes at a meeting with the client. The detailed part changes inside a sprint. No one is obliged to synchronize them until a moment of reconciliation arrives. And then the real price surfaces. It is not rewriting but alignment: you have to find out again which version is true, and only someone who remembers both discussions can do that. This work is not visible in the plan, does not fall into anyone’s estimate, and eats up days. Discipline does not cure this. Links between documents do — and there is a separate piece on how not to lose a requirement along the way: requirements traceability matrix.

The document was written because it had to be. It has no reader. The process demanded it, so the document appeared — and decisions are still made in chat. A month later it describes a system that no longer exists.

A document without a reader is not useless — it is harmful. A useless one just sits there. This one looks like an answer: it is cited, deadlines are calculated from it, newcomers are onboarded with it.

Hence the rule worth keeping in mind in any argument about documentation composition: every document must have a named reader and a decision it closes. If neither is found, the document is not needed. That is a normal answer, not a cop-out, and in an interview it sounds far stronger than listing all the artifacts in a row.

Which one is needed in your situation

You should choose not by project stage but by the question no one can answer right now.

Unclear why you are doing this at all? You need a BRD, even a one-page one. The why is clear, but everyone imagines the scope differently — you need an FRD. The scope is clear, but the tester and the developer keep coming to you with the same questions — you need an SRS. All three questions are closed and there is not a single document? Then perhaps none is needed. A team of four people who talk every day is not obliged to write three specifications.

That is what sounds strong in an interview. Not “you are supposed to keep three documents”, but “here is the question nobody could answer, so we wrote this”.

How this sounds in an interview

In our question bank from real interviews, the topic of these three documents appears six times, and four of those questions are tagged as junior. That is worth reading literally: the documents are asked about at the entry point into the profession. Not “when you grow to Senior”, but at the very first interview where you are asked about artifacts.

A weak answer is to spell out what the abbreviations stand for. It is formally correct and ends in nothing: the interviewer nods and moves on down the list.

A strong answer is shorter than it seems. Three documents — three readers — three moments. Then one sentence about what this was called in your company, and what exactly. And, if they ask deeper, an honest one: of these three, only the SRS exists in the standard; the rest is practice.

The last point separates a practitioner from someone retelling an article, more than any detail about section structure.