PRD, SRS, BRD and ERD: Which Document You Actually Need
Most failed software projects were mis-specified, not mis-built
When a build goes wrong, the post-mortem rarely finds bad code. It finds a feature everyone described differently: the client meant one thing, the developer built another, and nobody wrote down which was correct. The documents below exist to make that disagreement surface early, in a paragraph, rather than late, in a sprint.
The confusion is understandable. PRD, SRS, BRD and ERD overlap in content and differ in purpose, and plenty of teams produce a single muddled document that serves none of the four audiences well.
Key takeaways
- BRD = why. Business problem, objectives and success measures. Written for sponsors.
- PRD = what. Product behaviour, user outcomes, scope boundaries. Written for the team building it.
- SRS = how precisely. Testable functional and non-functional requirements. Written for engineers and QA.
- ERD = the data. Entities, attributes and relationships. Written for whoever designs the database.
- A requirement that cannot be tested is not a requirement — it is a hope. "Fast" fails; "95th percentile under 400ms" passes.
Which document, which reader
| Document | Answers | Primary reader | Fails when |
|---|---|---|---|
| BRD — Business Requirements | Why are we spending money on this? | Sponsor, finance | It lists features instead of outcomes |
| PRD — Product Requirements | What must the product do? | Product, design, engineering | It specifies implementation |
| SRS — Software Requirements Spec | Exactly what, verifiably? | Engineers, QA | Requirements are untestable |
| ERD — Entity Relationship Diagram | What data, related how? | Database designer | It is drawn after the code |
The BRD — business requirements
The BRD justifies the project. It should be readable by someone who will never open the software, and it should contain no feature list at all.
- Problem statement in business terms, with a number attached to the pain.
- Objectives and success measures — what will be different, and how it will be measured.
- Scope boundaries, especially what is explicitly out.
- Stakeholders and who signs off.
- Constraints: budget, deadline, regulation, existing systems.
- Assumptions and risks, written before anyone is invested in the answer.
Write the success measure before the solution. "Reduce quote turnaround from three days to four hours" survives a change of approach; "build a quoting portal" does not, and quietly becomes the goal.
The PRD — product requirements
The PRD translates business intent into product behaviour. It is the document the delivery team works from day to day, and the one most worth investing in.
- User roles and what each is trying to accomplish.
- User journeys for the primary flows, including the unhappy paths.
- Functional scope as capabilities, not screens.
- Acceptance criteria per capability — the conditions under which it is done.
- Out of scope, explicitly, so scope creep has to be a decision rather than a drift.
- Open questions with owners and dates. This section is a feature, not an admission.
A PRD should describe behaviour, not implementation. "The system notifies the approver" belongs in a PRD; "send via SendGrid webhook" does not.
The SRS — software requirements specification
The SRS is where ambiguity goes to die. It is the document a QA engineer writes test cases from without asking questions, and the one a fixed-price contract should reference.
The reference standard here is ISO/IEC/IEEE 29148, which covers requirements engineering and sets out what makes an individual requirement well formed: necessary, unambiguous, singular, feasible, verifiable and traceable.
- Functional requirements, each individually numbered and testable.
- Non-functional requirements: performance, availability, security, accessibility, data retention, localisation. These are what get forgotten and then cost the most.
- Interfaces: external systems, APIs, file formats, authentication.
- Data requirements: validation rules, retention, personal data handling.
- Traceability back to the PRD and forward to test cases.
The ERD — entity relationship diagram
The ERD is the data model: the entities your system stores, their attributes, and the relationships between them. Its value is that data-model mistakes are the most expensive class of mistake in software — a wrong screen is a day, a wrong relationship is a migration.
- Every entity with its key attributes and identifier.
- Cardinality on every relationship: one-to-one, one-to-many, many-to-many.
- Optionality: is this relationship mandatory?
- The lifecycle question: what happens to related records on deletion?
Draw the ERD before you draw the screens. Interfaces derived from a sound data model tend to simplify themselves; data models reverse-engineered from screens accumulate columns that mean "it depends".
Writing requirements that can actually be tested
| Weak | Testable |
|---|---|
| The system should be fast | Search returns in under 400ms at the 95th percentile with 10,000 records |
| The system should be secure | All passwords stored using a memory-hard hash; sessions expire after 30 minutes idle |
| Users can manage their profile | A signed-in user can change name, email and password; email change requires confirmation from the new address |
| The app should be user friendly | A new user completes first booking in under three minutes in moderated testing, without assistance |
| Reports should be available | Monthly revenue report exports to CSV and PDF, generated in under 10 seconds for 12 months of data |
Three habits fix most requirement writing: use shall for obligations, give every requirement a number that never changes, and state a measurable condition for every adjective.
What a small project actually needs
Not all four. For most small and mid-sized builds:
| Project | Write | Skip |
|---|---|---|
| Internal tool, one team | Short PRD + ERD | BRD, formal SRS |
| Client build, fixed price | BRD + PRD + SRS | — the SRS is your contract |
| Startup MVP | PRD + ERD | BRD (the pitch deck is the BRD) |
| Regulated or safety-critical | All four, with traceability | Nothing |
| Replacing a legacy system | BRD + SRS + ERD of the old system first | — document what exists before replacing it |
Documentation is worth exactly what it prevents. A ten-page PRD that stops one rebuilt feature has paid for itself several times over; a hundred-page specification nobody reads has not.
Frequently asked questions
What is the difference between a PRD and an SRS?
A PRD describes what the product must do from the user's point of view and is read by the whole delivery team. An SRS states the same scope as individually numbered, verifiable requirements, including non-functional ones, and is read by engineers and QA. In practice the PRD answers "what are we building and why does the user care", while the SRS answers "exactly what must be true for this to be accepted". Fixed-price work needs the SRS, because it is what disagreements get resolved against.
Do agile teams still need requirement documents?
They need fewer and shorter ones, not none. User stories work well for iteration but are poor at carrying non-functional requirements, data models and cross-cutting constraints, which is where expensive surprises live. A lightweight PRD plus an ERD, kept current, gives an agile team the shared context that a backlog alone does not — the backlog says what is next, not what the system is.
Who should write these documents?
Whoever is accountable for the answer being right, which varies by document: the sponsor or a business analyst for the BRD, product for the PRD, an engineer or analyst for the SRS and ERD. The failure mode to avoid is a document written entirely by someone who will not live with the consequences. Whoever writes it, one named person must own each document and keep it current, or it becomes archaeology within a month.
How long should a PRD be?
As long as it takes to remove ambiguity, which for most small projects is five to fifteen pages. Length is a poor proxy for quality — a short document with numbered acceptance criteria and an explicit out-of-scope list beats forty pages of prose. If a section is not going to change anyone's behaviour, cut it.
What happens if we skip the ERD?
You get one anyway, implicitly, as whatever the code happened to create. That is fine until the first significant change, at which point you discover a relationship modelled the wrong way round and need a data migration under time pressure. Data mistakes are the most expensive category in software because they compound: every feature built on top of a wrong model has to be revisited.
Sources
- ISO/IEC/IEEE, 29148 — Systems and software engineering: requirements engineering — the reference standard for requirement quality and specification structure.
- Entity–relationship model — background on entities, attributes, cardinality and notation.
Keep reading
All articles →
The Project Management Documents That Actually Earn Their Keep
A project charter, a RAID log and a one-page status report will carry a small project further than a full PMO template library. What each document is for, what goes in it, and whic
Aug 12, 2026 · 11 min read
Remote Work Technology Stack
The Remote Work Technology Stack: A Business-First Blueprint for Growth, Resilience, and Speed Remote and hybrid work are no longer “policies”—they’re operating...
Feb 18, 2026 · 13 min read
SOPs and Operations Manuals: Writing Procedures People Follow
Most SOPs are written once, filed, and ignored. Here is the format that survives contact with a busy team, how ISO 9001 thinks about documented information, and how to build a manu
Aug 12, 2026 · 11 min read