If you are sitting down to write a business requirements document for a software development project, the first question is not what to write. It is what sections the document needs to contain so that developers, testers, architects, and stakeholders all get what they need from a single source of truth. Get the structure wrong and you will spend the next three months answering the same questions in different meetings. I have written BRDs across government, utilities, health, and enterprise environments, and the documents that held up best under scrutiny were always the ones built around a consistent, logical structure that made scope, context, and requirements easy to locate.
What follows is that structure, explained section by section, with a real example drawn from a public sector software procurement to show exactly where friction tends to appear and what it costs when you have not planned for it.
The seven core sections a software development BRD must contain
Some organisations combine or rename sections, but the content below needs to be present in some form for the document to be genuinely useful to anyone working on or approving the project.
- Executive summary. A short, plain-language description of what the project is trying to achieve, who commissioned it, and what the expected outcome is. This is written last but read first.
- Business context and problem statement. An explanation of the current state, why it is not fit for purpose, and what the business is trying to change. This section justifies the project’s existence.
- Scope and out of scope. A precise boundary statement covering what the proposed software will and will not do. Without this, scope creep begins on day one.
- Stakeholders and user groups. The people and roles affected by or involved in the system, including who has authority to sign off requirements.
- Business requirements. The core of the document. Each requirement states what the business needs the system to do, not how it should do it. Numbered, unambiguous, and testable.
- Non-functional requirements. Performance, security, availability, scalability, and compliance requirements. These are the sections most frequently under-specified and the ones that cause the most post-launch pain.
- Assumptions, constraints, and dependencies. The things the requirements are predicated on, the limits within which the solution must operate, and the external systems or decisions the project depends on.
Writing the business context section so it actually argues for change
The business context section is not background reading. It is the argument for change, and it needs to be treated as such. When I worked on a public sector information management project for Organisation A, the existing system managed spatial and textual datasets through a desktop-only environment that required expensive, high-specification hardware and specialist training for every user, regardless of how limited their actual data needs were. The business case noted that roughly 50% of users were accessing only around 10% of the system’s capability. That single observation was more persuasive than three pages of narrative because it quantified the waste.
In your BRD, the business context section should answer three questions: what does the current situation look like, what is it costing the business to stay in that situation, and what does success look like once the new software is in place. If you can put numbers against any of those answers, do it. Vague problem statements generate vague solutions.
Writing business requirements that hold up
The requirements section is where most BRDs either earn their credibility or lose it. In a software development context, the difference between a useful requirement and a useless one usually comes down to three things: it is stated at the right level of abstraction, it is testable, and it does not accidentally specify a solution.
A requirement like “the system shall be fast” is not a requirement. A requirement like “the system shall return search results within three seconds for 95% of queries under normal load” is testable, measurable, and actionable. Developers know what to build toward. Testers know what to verify against. If you are working in an environment that also produces functional requirements or user stories downstream, your BRD requirements sit above that layer. They describe what the business needs, not how the software will implement it. For a detailed comparison of these two layers, see the article on the difference between a BRD and an FRD.
The section most BRDs get wrong: non-functional requirements
Non-functional requirements are consistently under-specified in software development BRDs. I have reviewed documents where the entire NFR section reads “the system must be secure and performant.” That tells a developer nothing and creates significant risk during acceptance testing when the organisation discovers the delivered software does not meet expectations that were never formally stated. For a software development project, your non-functional requirements should address at minimum the areas in the table below.
| NFR Category | What to specify | Common mistake |
|---|---|---|
| Performance | Response times, throughput, load thresholds | Leaving it vague: “must be fast” |
| Security | Authentication method, data encryption, access control levels | Deferring to IT without capturing business rules |
| Availability | Uptime percentage, maintenance windows, disaster recovery time | Not distinguishing between business hours and 24/7 |
| Scalability | Expected user growth, data volume projections | Specifying for current state only |
| Compliance | Relevant legislation, data residency, audit requirements | Assuming the development team knows the regulatory context |
| Usability | Accessibility standards, browser or device compatibility | Treating usability as a design concern rather than a requirement |
If you want a structured starting point for drafting this section, the non-functional requirements template on this site covers each category with example statements you can adapt for your own project context.
A worked example: where the BRD ran into trouble
On a data management platform project for Organisation A, the project team prepared a BRD to support the acquisition of an enterprise software solution. The document covered the business context clearly and included a solid set of business requirements. The NFR section addressed security and scalability adequately. The document looked complete. It was not.
Where things became difficult was in the assumptions and constraints section. The BRD assumed that the organisation’s existing desktop environment would remain in place for specialist users and that the new server-based platform would serve a broader, less technical audience. That assumption was reasonable. What the document did not capture explicitly was the dependency on a separate infrastructure procurement that was running in parallel on a different budget line.
When approval for the software purchase was sought, the review committee questioned whether the infrastructure would be ready in time. The BRD had no constraints section entry that flagged the tight delivery window or the dependency on hardware delivery by a specific date. The result was a revision cycle that cost three weeks and required the team to go back to stakeholders to get confirmation of infrastructure timelines before the software acquisition could proceed. The committee was not being obstructive. They were asking a question the document should already have answered.
The lesson is straightforward: assumptions and dependencies are not optional sections. They are the content that prevents your document from being returned with questions you should have anticipated. I have also found that explicitly listing what the BRD does not cover is just as important as what it does. Stakeholders who see a pet feature missing from the requirements section are far less likely to raise it as a blocker at the wrong moment if the out-of-scope list acknowledges it directly. If scope management is a recurring challenge on your projects, the scope creep and governance guide on this site is worth reading alongside this one.
Structuring the document for sign-off
A BRD that nobody will sign off is just a word document with a lot of text in it. Structure the document so that sign-off is easy to give. That means a clear version history, named reviewers and approvers, and a summary of what has changed between versions. If you are working in an environment where requirements change frequently, consider maintaining a requirements traceability matrix alongside the BRD so that each requirement can be tracked through to design, build, and test.
Keep the main body of the BRD focused on requirements and context. Appendices are the right place for detailed process maps, data dictionaries, and supporting analysis. Decision-makers should be able to read the first half of the document and understand what is being built and why, without needing to wade through supporting detail.
How a BRD sits alongside other document types in a software project
| Document type | Purpose | Audience | Level of detail |
|---|---|---|---|
| Business Requirements Document | Captures what the business needs | Stakeholders, BA, project sponsors | Business-level, solution-agnostic |
| Functional Requirements Document | Describes system behaviour | Developers, architects, testers | System-level, solution-specific |
| Software Requirements Specification | Full technical and functional specification | Development team | Detailed and technical |
| User Stories | Captures individual feature needs | Agile delivery team | Granular, narrative format |
If your project is using an agile delivery methodology, the BRD still has a role to play. It provides the foundation from which the product backlog is built and gives the product owner a documented record of the business intent behind the features. The BRD and the backlog are not in competition. One defines what the business needs. The other organises delivery.
The strongest business requirements documents I have produced for software development projects were not the longest ones. They were the ones where every section had a clear purpose, every requirement was traceable to a business need, and the constraints section was honest about what the team did not yet know. A well-structured BRD reduces rework, accelerates sign-off, and gives the development team a reliable foundation to build from. The time you invest in getting it right at the start will save you significantly more time defending decisions later in the project.
Frequently asked questions
What should be included in a business requirements document for a software project?
A BRD for software development should include an executive summary, business context and problem statement, scope boundaries, stakeholder and user group identification, numbered business requirements, non-functional requirements, and an assumptions and constraints section. Each requirement should be testable and stated at the business level rather than specifying a technical solution. The document should also include a version history and named approvers to support formal sign-off.
What is the difference between a BRD and an FRD in software development?
A BRD captures what the business needs a system to do, without specifying how it should be built. An FRD translates those business needs into specific system behaviours and functional specifications that developers can work from. The BRD comes first and is owned by the business stakeholders, while the FRD is typically produced by the BA or technical team as a downstream document.
How long should a BRD be for a software development project?
There is no fixed length, but a BRD should be as long as it needs to be to cover all seven core sections clearly and no longer. A straightforward internal tool might require ten to fifteen pages, while a complex enterprise platform could require significantly more. Appendices are the right place for detailed supporting content so that the main document remains readable by non-technical stakeholders.
Can you use a BRD in an agile software project?
Yes. In an agile environment, the BRD provides the documented business intent that sits behind the product backlog. It gives the product owner and development team a reference point for why features exist and what business problem they are solving. The BRD does not replace user stories but provides the foundation from which the backlog is built.
What are non-functional requirements in a software BRD?
Non-functional requirements describe how the system should perform rather than what it should do, covering areas like response times, security controls, availability targets, scalability, and compliance obligations. They are frequently under-specified in BRDs and are a common source of disputes during acceptance testing. Every software BRD should include a dedicated NFR section with measurable, specific statements rather than vague descriptions like ‘must be secure.’
Try Ash, Your Virtual BA
If you are working on a business requirements document for a software development project right now, Ash can help you build it section by section. Ash is trained on real BA practice and will guide you through structuring your requirements, tightening your problem statement, drafting non-functional requirements that will hold up under scrutiny, and capturing the assumptions and constraints that review committees always ask about. You do not have to start from a blank page. Try Ash Virtual BA and get your BRD moving today.
Further reading
- Eliciting Requirements With Use Case | IIBA
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.