Start With What Developers Actually Need to Read
When I sit down to write a BRD for a software project, the question I ask myself before I type a single word is: could a developer read this document and know exactly what to build, what is out of scope, and what constraints they are working within? If the answer is no, the document is not ready. That question drives every structural decision in the template I use.
A software BRD is not a wish list. It is not a slide deck translated into prose. It is a document that captures what the business needs the system to do, expressed clearly enough that a technical team can design, estimate, and build against it. The template structure I am sharing here is the one I have refined across government, utilities, and enterprise projects over 25 years. It works because it is organised around the decisions developers have to make, not around what feels logical to a business stakeholder presenting in a meeting room.
If you want to understand how a software BRD relates to the functional requirements document that typically follows it, the article on BRD vs FRD is worth reading before you start writing.
The Core Sections of a Software BRD Template
Below is the section structure I use for software development projects. Each section exists for a reason. I have noted what goes in each one and why developers depend on it.
- Document control and version history: Every BRD needs a table showing who owns it, who approved it, and what changed between versions. On software projects this matters more than people think because requirements drift silently between drafts.
- Project background and business context: A brief summary of why this software is being built, what problem it solves, and what has been tried before. Keep it to one page. Developers read this to understand intent when requirements feel ambiguous.
- Scope statement: A precise description of what the system will and will not do. I always include both an in-scope list and an explicit out-of-scope list. Assumptions sit here too.
- Stakeholders and user groups: Who uses the system and in what capacity. Not just names and titles but roles, access levels, and any constraints on what each group can see or do.
- Business requirements: The core section. Each requirement gets a unique ID, a plain-language statement of what the business needs, a rationale, a priority, and any acceptance criteria that can be verified. This is the section developers build from.
- Non-functional requirements: Performance, security, availability, scalability, accessibility, and compliance requirements. These are the requirements that kill a build in UAT when they are missing from the BRD. I cover this in detail in the next section.
- Integration and interface requirements: What systems does this software connect to, how does data flow, and what interface standards apply? On government projects I have seen this section cause more rework than any other omission.
- Data requirements: What data the system stores, what data it consumes, data migration requirements if replacing a legacy system, and any data quality or retention rules.
- Constraints and dependencies: Technology constraints, budget ceilings, regulatory requirements, third-party dependencies, and timeline constraints that affect design decisions.
- Glossary: Every domain-specific term that appears in the document, defined once and referenced consistently. Without this, developers build to their own interpretation of business language.
Business Requirements vs Non-Functional Requirements: Know the Difference
One of the most common mistakes I see in software BRDs written by early-career practitioners is collapsing all requirements into a single list without distinguishing between what the system must do and the conditions under which it must do it. The table below shows the distinction in practical terms.
| Requirement Type | What It Describes | Example in a Software BRD |
|---|---|---|
| Business Requirement | What the system must do to meet a business need | The system must allow a user to search case records by reference number, date range, and assigned officer |
| Functional Requirement | How the system behaviour delivers the business requirement | Search results must return within three seconds and display a maximum of 50 records per page with pagination |
| Non-Functional Requirement | The performance, security, or quality conditions under which the system operates | The system must support 155 concurrent users without degradation in response time |
| Constraint | A boundary condition that limits design or solution options | The solution must be deployable within the existing on-premise ICT environment without additional server infrastructure |
If you want a deeper look at how these layers interact, the article on business requirements vs functional requirements vs non-functional requirements breaks this down with worked examples across different project types.
Writing Requirements That Developers Can Build From: The Format That Works
I use a consistent format for every business requirement in a software BRD. Each requirement entry in the template should include the following fields.
- Requirement ID: A unique identifier such as REQ01, REQ02, and so on. This allows traceability into the functional specification, test cases, and change log.
- Requirement statement: Written in the form “The system shall…” or “The system must…” to make it unambiguous. Avoid “should” and “could” in requirement statements as they allow developers to deprioritise without any formal agreement.
- Rationale: One sentence explaining the business reason behind the requirement. When a developer questions a design decision, this is the reference point.
- Priority: I use a three-tier scale: Must Have, Should Have, Could Have. Avoid labelling everything as Must Have unless you want a constant scope negotiation during sprints.
- Acceptance criteria: The measurable conditions under which the requirement is considered satisfied. Without this, testing becomes subjective and sign-off becomes political.
- Source: The stakeholder or document that originated this requirement. On projects with multiple stakeholder groups this prevents contradictory requirements from appearing without a decision trail.
A Real Example: When the Template Saved the Build (and When It Almost Did Not)
On Project X, a case management system replacement for a government justice agency, I was brought in to write the BRD after an earlier attempt had stalled. The original document ran to 60 pages but had no requirement IDs, no acceptance criteria, and no non-functional requirements section at all. The vendor had responded to the RFP with a compliance matrix referencing numbered specification clauses, but because the BRD had no numbering, the evaluation panel could not map vendor responses to specific requirements. The procurement was six weeks behind before the build had even started.
I restructured the document using the template format above, assigning sequential IDs to 147 functional requirements and a separate block of non-functional requirements covering performance, security, and integration. The integration section was particularly important: the system had to exchange data with a court scheduling platform using a defined interface standard, and the original BRD had mentioned this in passing in a single sentence buried in the background section.
The friction came when the lead technical architect at the vendor reviewed my revised draft and pushed back on the concurrent user requirement. The business had specified 155 concurrent users. The vendor’s standard licence model was priced at 100 users, and their product had not been performance-tested beyond 120. Rather than accepting a “Partially Complies” response and moving forward, I worked with the procurement lead to require the vendor to provide a written commitment and test evidence before contract execution. That decision held up contract signing by three weeks and caused significant tension with the project sponsor who wanted to proceed. We held the line. The vendor ultimately provided the evidence and the contract proceeded with an agreed performance test milestone built into the implementation plan. Without the non-functional requirement being explicitly stated with an acceptance criterion, that conversation would never have happened formally and the system would almost certainly have failed under production load.
What to Put in the Scope Section (and What Most BRDs Get Wrong)
The scope section is where most software BRDs lose their usefulness. I have read BRDs that describe scope as “the implementation of a new system to replace the current process.” That tells no one anything. A useful scope statement in a software BRD includes three components: the features and functions the system will include, the features and functions it will explicitly not include, and the assumptions that the scope relies on.
The out-of-scope list is the one most practitioners skip. On Project X, the out-of-scope list included items such as integration with the financial management system, mobile access, and bulk document scanning. Each of those had been raised in stakeholder workshops and documented in meeting notes. By naming them explicitly as out of scope in the BRD, I prevented them from re-emerging as requirements during UAT, which is the most expensive place to discover that scope has expanded without anyone’s agreement. If you want a practical framework for managing this kind of scope drift, the article on scope creep governance covers the mechanics in detail.
Using the Template in Agile and Hybrid Environments
I am often asked whether a formal BRD has a place in agile software projects. My answer is that it depends on the project size, the number of stakeholders, and the procurement method. On a small agile delivery with a co-located product owner and development team, a backlog and a set of well-written user stories may be sufficient. But on a project involving a formal vendor procurement, a fixed-price contract, or a regulatory compliance obligation, a BRD is not optional. The vendor needs to price against something. The contract needs to reference something. Regulators need to see that requirements were documented before the build, not reconstructed after it.
In hybrid environments, I use the BRD to capture business and non-functional requirements at a level that supports contracting and governance, and then let the functional detail live in the backlog. The BRD does not need to contain every user story. It needs to contain enough that a vendor, a contract manager, or a regulator can verify that the system built is the system that was commissioned.
Writing a software BRD that developers can actually build from is not about producing the longest or most detailed document on the project. It is about making the right things explicit: what the system must do, the conditions it must do it under, what it will not do, and how you will know when it has done it correctly. Get those four things right and the document will do its job at every stage of the delivery, from vendor evaluation to UAT sign-off.
Frequently asked questions
What should be included in a software business requirements document?
A software BRD should include a scope statement, stakeholder and user group descriptions, uniquely identified business requirements with rationale and acceptance criteria, non-functional requirements covering performance and security, integration requirements, data requirements, and a glossary. Each requirement should have a unique ID to support traceability. The document should also include an explicit out-of-scope list to prevent scope creep during development.
What is the difference between a BRD and an FRD for software projects?
A BRD captures what the business needs the system to do, expressed in business language with rationale and acceptance criteria. An FRD translates those business needs into specific system behaviours, logic, and interface designs that the development team implements. On most software projects the BRD is written first and the FRD follows once the solution approach has been agreed.
How do I write requirements in a software BRD that developers can understand?
Write each requirement using the form ‘The system shall…’ or ‘The system must…’ followed by a measurable outcome. Include an acceptance criterion for every requirement so that testing is objective rather than subjective. Avoid vague language such as ‘should support’ or ‘may allow’ because these give developers no clear obligation to build against.
Do I need a BRD for an agile software project?
On small agile projects with a co-located team and a single engaged product owner, a well-maintained backlog may be sufficient. On projects involving vendor procurement, fixed-price contracts, or regulatory compliance, a BRD is necessary because it provides the documented baseline that contracts and audits require. The BRD does not need to contain every user story, only enough detail to support contracting and governance.
How long should a software BRD be?
There is no fixed length, but a useful rule is that every page should earn its place by containing information a developer, tester, or contract manager will refer back to. A typical mid-sized software project BRD runs between 20 and 50 pages, with the business requirements section being the longest. Length should be driven by project complexity, not by a desire to appear thorough.
Try Ash, Your Virtual BA
If you have just worked through the template structure in this article and you are now staring at a blank document wondering how to turn your stakeholder notes into properly structured, numbered requirements with acceptance criteria, Ash can help you do exactly that. Ash is a virtual BA assistant built specifically for writing business requirements documents, including software BRDs with the section structure, requirement IDs, and non-functional requirements that development teams actually need. Feed in your project context and Ash will help you produce a first draft that is ready to review, not a generic placeholder. Try Ash Virtual BA.
Further reading
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
- Managing the product requirements definition process
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.