BRD vs PRD vs SRS: which one should a PO write?

Three requirements documents answer three different questions: why we do it, what we build for whom, and how the system must behave. This guide shows when you need each.

Written by Phan Lam Duy Khoi

A BRD explains why the business needs the change and what business goals it serves, a PRD explains what the product does, for whom, and how success is measured, and an SRS describes in detail how the system must behave. A PO often owns the PRD and the backlog, contributes to the BRD and reviews the SRS, though names and owners vary by company.

What is the difference between a BRD, PRD and SRS?

A BRD explains why the business should do something, a PRD explains what the product will do, for whom, and how success is measured, and an SRS describes in detail how the system must behave. A PO often owns the PRD and the backlog, contributes to the BRD and reviews the SRS, but the names and owners vary between companies.

Here is an illustrative situation. You have just started as a PO at a software agency that builds projects for clients. On day one your lead says: “The client sent the BRD. You write the PRD, and the BA will do the SRS later.” You nod, then search “what is a BRD”. You find three templates with almost identical tables of contents, and no idea which part is your job.

A week later the BA shares a first SRS draft. You open all three files: the client's BRD, the PRD you are drafting and the SRS draft. All three have a “scope” section, all three mention “users”, and the target number in the BRD differs from the one in the PRD you are drafting. The real question is no longer “which template is right”. It is: what decision does each document support, who reads it, and how far should you go?

Why are these documents so easy to confuse?

The confusion is not because you skimmed. At least four things blur the line between a BRD, a PRD and an SRS.

Names are inconsistent. Some companies call every requirements document a “spec”, some use FRD instead of SRS, some call the PRD a “feature document”. The same name can hold different content in two companies.
The international standard uses different names from everyday practice. ISO/IEC/IEEE 29148, the requirements engineering standard, uses names such as BRS (business requirements specification) and SRS (software requirements specification). Many teams say BRD instead, and the PRD comes from product management practice rather than from this standard.
The three documents cover the same work at three depths. Each has scope, users and goals, so their outlines look alike. The difference is the question each must answer and who uses it to decide.
The roles overlap too. POs, PMs and BAs all work with requirements, so who writes what depends on how the company splits the work. If those role boundaries are unclear to you, read the PO, PM and BA comparison first.

On top of that, many agile teams never write all three. Atlassian describes the agile PRD as a page focused on shared understanding, customer needs and flexibility, avoiding overly detailed specs. The detail is broken down into the backlog as user stories. So when a job ad or a colleague says “write the SRS”, ask what they actually mean by that name.

Product Owner vs Product Manager vs Business Analyst

What are a BRD, PRD, SRS and FRD?

The easiest way to remember them is to tie each to a question. The BRD asks “why”, the PRD asks “what, and for whom”, the SRS asks “how must the system behave”. The FRD is part of the last question, focused only on functions.

Four kinds of requirements document compared (owners shown are common splits, not rules)
Document	Question it answers	Main readers	Often written by	Detail and when used
BRD: business requirements document	Why the business needs this, what the business goals are, how wide the overall scope is	Leadership, project sponsors, the client paying for the work	Business teams, BAs, sometimes PMs	Low. Used to approve a project, a budget or a contract
PRD: product requirements document	What problem the product solves for whom, what is in this release, how success is measured	Designers, engineers, affected stakeholders	PO or PM	Medium. Used before splitting work into user stories, updated during delivery
SRS: software requirements specification	What the system must do, how it handles data and errors, which performance and security standards it meets	Engineers, testers, integration partners	BAs, engineers or system analysts, reviewed by the PO	High. Used for contracts, audits, multi-system integration
FRD: functional requirements document	Only the functions: what the system must do	Engineers, testers	BAs	High, but often without non-functional requirements

A few more things worth knowing about each.

The BRD takes the business view. It states the business problem, measurable goals, stakeholders, and constraints such as budget, deadlines or regulation. A good BRD does not mention screens. In 29148 the matching document is the BRS, which describes the organisation's business or mission requirements.
The PRD takes the user and product view. It says who has the problem, what the product will change for them, the scope this time and what is deliberately left out. Atlassian suggests the PRD acts as the landing page for everything related to a set of problems, from goals and assumptions to user stories and design.
The SRS takes the system view. It holds functional requirements (what the system must do) and non-functional requirements (how fast, how secure, what load). The classic reference for an SRS is IEEE 830-1998. It was superseded by ISO/IEC/IEEE 29148 in 2011, which was revised in 2018.
The FRD is often treated as the functional part of an SRS. It is a term from project practice rather than a separate document in 29148, so companies may read it slightly differently.

At an agile product company you may only meet one thing: a short PRD plus a backlog. At an outsourcing firm, a bank or a public-sector project you are more likely to meet a BRD, an SRS and the sign-off records that come with them.

Which document should a Product Owner write?

The Scrum Guide 2020 does not mention BRDs, PRDs or SRSs. It says the Product Owner is accountable for effective Product Backlog management, may delegate some of that work, and remains accountable. So instead of asking “which document must a PO write”, a more useful question is: which document makes your backlog clear, correct and well ordered?

One approach is to go through four steps before opening any template.

Four steps to choose the right document Start from the reader and the decision, not from a template.

Ask who reads it: Who will use this to decide what
Find what exists: BRD, contract, old PRD, current backlog
Pick the level: Why, what for whom, or how the system behaves
Write your part, link the rest: Each fact lives in one place

When a goal, scope or rule changes, edit it in exactly one document and check the links that point to it.

Step 2 is easy to skip. Much of what you plan to write in the PRD already sits in the BRD or the contract. Copying it creates two versions that will eventually disagree. Linking to the original leaves one place to update.

For step 3, the filter below helps you decide which documents one request needs. Each “yes” moves you forward. A “no” tells you which document is missing.

Which documents does this request need? Work from the top. Stop at the first “no”, add that document, then come back.

A new request needs to be written down

Are the business reason, budget and approver clear? You need a BRD or a one-page business case first. In many teams, business teams or a BA lead it, and the PO contributes the user problem.
Has the team agreed the problem, users, scope and success measure? Write a PRD, ideally a one-page one. In many teams, this is the part the PO owns.
Do the Developers have enough to estimate and test from user stories and acceptance criteria? Add a detailed spec (SRS or FRD) for the complex part only, written with the BA and the Developers.
Is the current backlog enough for every party that needs a formal spec (if any), such as a contract, an audit or an integration partner? A party needs a formal spec the backlog does not cover: write an SRS in the format they require, for example following the ISO/IEC/IEEE 29148 structure.

Use a short PRD and the backlog. No extra document is needed for this request.

The filter shows something important: an SRS is not a compulsory step after a PRD. For many small and medium features, user stories with testable acceptance criteria are detailed enough. An SRS is worth writing when a real reader needs it: the Developers when a part is too complex to fit in user stories, the client's testers, an auditor or an integration team at another company. The one-page PRD guide also has a “Do you need a full spec?” filter: for payments, legal rules, personal data or changes that are hard to reverse, write a full spec and keep the one page as the entry point.

If the PRD is your part, start with the one-page PRD guide, then split the work into user stories and write acceptance criteria for each story.

Example: one request at three levels

This illustrative example uses a fictional online tea shop called Tra La. Operations complain that many deliveries fail because customers are not home. The original request is one line: “Let customers choose a delivery time slot.” Every number in the table is an assumed figure for illustration.

The same “delivery time slot” request at three document levels (illustrative, assumed numbers)
Document	Main question	Sample wording	Does not belong here
BRD	Why does Tra La need this?	First-attempt delivery failures are at 8% (assumed figure), and each redelivery adds shipping cost. Goal: below 5% within three months in the first two cities. Constraint: the delivery partner must be able to receive the time slot.	The list of slots, the slot picker screen
PRD	What, for whom, measured how?	Office workers in the city want to receive orders when they are home. This release: choose one of three slots at checkout. Out of scope: changing the slot after the order leaves the warehouse. Measure: first-attempt delivery success for orders with a chosen slot.	Data field names, API design
SRS	How must the system behave?	The system shows three slots: 9 to 12, 13 to 17, 18 to 21. A slot locks when it reaches the configured maximum number of orders or when less than 2 hours remain before it starts. The slot list loads within 1 second (assumed figure). If the delivery partner's API fails, hide slot choice and allow standard delivery.	Business rationale, expansion strategy

Notice a few things. Each document has its own number, and that number serves its reader. The BRD uses the failure rate so leadership can decide whether to invest. The PRD uses first-attempt success so the team knows whether the feature helped after launch. The SRS uses load time and lock conditions so engineers can build it and testers can check it.

The PRD's out-of-scope line and the SRS's error handling do not repeat each other either. The PRD states scope in the user's words. The SRS states the same scope as system behaviour. If Tra La were a small agile team, the SRS part could live inside the acceptance criteria of two or three user stories with no separate file.

An FRD would keep the slots, the lock conditions and the API failure handling, but drop the 1-second target. That target is a non-functional requirement, so it has to be recorded somewhere else, for example in a shared list of system-wide requirements.

Set success metrics before building a feature

Template: which section goes in which document?

This template is not a document to fill in. It is a map to check that each piece of information sits in the right place. Copy it to the first page of your project and mark what exists, in which document, and who owns it. The detailed PRD template is in the one-page PRD guide, so only section names are listed here.

Project requirements document map

Rule: each piece of information lives in one document. Other documents link to it.

BRD (why) | Owner: [name] | Link: [link]
[ ] Business problem and context
[ ] Measurable business goals, with data source
[ ] Overall scope and what is out of scope
[ ] Stakeholders and approvers
[ ] Constraints: budget, deadline, regulation

PRD (what, for whom) | Owner: [PO or PM name] | Link: [link]
[ ] User problem and user groups
[ ] Product goal and how it is measured
[ ] Scope this time and what is not included
[ ] Key flows
[ ] Open questions, risks, dependencies

SRS or FRD (how the system behaves) | Owner: [name] | Link: [link] | Needed: [yes/no, why]
[ ] Functional requirements: what the system must do
[ ] Business rules and data
[ ] Interfaces with other systems
[ ] Non-functional requirements: performance, security, availability
[ ] Error handling and edge cases
[ ] How each requirement will be verified

Backlog | Owner: [PO name] | Link: [link]
[ ] User stories for this scope
[ ] Acceptance criteria for each story

Information currently in two places: [list it, choose one home, turn the other into a link]

The last line is the one to use most. Every time the same number or rule appears in two documents, choose one home and turn the other into a link. This small habit prevents many “but the other document says something else” arguments.

For the verification line, the 29148 templates in ReqView have a verification method attribute for each requirement, with test, demonstration, inspection and analysis as options. You do not need all four. Each requirement just needs an answer to “how will we know it is met?”

Common mistakes with requirements documents

Writing all three documents for every feature. More documents feel safer, but each extra one is another place to keep current. Use the filter above and write only what a real reader needs.
Copying the same information into several places. Goals in the BRD, the PRD and a slide deck drifting apart is easy to do. Keep one home and link from everywhere else.
Letting the PRD turn into an SRS. The PO writes field names, API structures or storage details. Engineers are better at these, and writing them in advance takes away the team's room to contribute.
Trusting the document's name over its content. One company calls it an SRS, another calls it a spec. When handed a template, ask who reads it and what they use it to decide.
Forgetting non-functional requirements. Speed, security, permissions and load capacity do not show on screen, so they are easy to miss until the system slows down at peak time.
Writing untestable requirements. “The system is fast” or “the interface is friendly” tells nobody when it is done. Each requirement needs a number, a condition or a visible result.

If reviewing an SRS with engineers feels intimidating, read the guide on working with developers when you cannot code. You do not need to know how the system is built, but you do need to ask whether it matches the agreed problem and scope.

Summary

A BRD answers why the business should do it. A PRD answers what to build, for whom, and how success is measured. An SRS answers how the system must behave. An FRD is the functional part of an SRS.
Names and owners vary by company. ISO/IEC/IEEE 29148, which replaced IEEE 830, uses the names BRS and SRS.
A PO often owns the PRD and the backlog, contributes to the BRD and reviews the SRS. The Scrum Guide makes the PO accountable for the Product Backlog and prescribes no document types.
Choose documents by reader and decision. Many agile teams need only a short PRD plus user stories and acceptance criteria.
Each piece of information lives in one document, and other documents link to it.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

Get new articles by email

Frequently asked questions

What is a BRD?

A BRD (business requirements document) states the business problem, the goals to reach, the overall scope and constraints such as budget or deadlines. It answers why the work is worth doing and does not yet describe screens or system behaviour.

What is the difference between a PRD and an SRS?

A PRD describes what problem the product solves, for whom, the scope and how success is measured. An SRS describes in detail what the system must do and to what standard, including functional and non-functional requirements, so engineers can build it and testers can check it.

Does a Product Owner have to write the SRS?

In many teams, the PO does not write it alone. A BA or the Developers may lead the SRS, while the PO reviews it against the problem, scope and priorities. In small agile teams this detail can live in user stories and acceptance criteria instead of a separate SRS.

Sources to check

What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.