Start With the Template, Then Adapt It for the Work
If you have a BRD to write for a software development project and you are staring at a generic template wondering what to keep and what to change, you are asking exactly the right question. A standard business requirements document template works well enough for process improvement or policy change. When you are specifying a system, several sections need to change shape entirely, and a few critical sections need to be added from scratch.
This article tells you which sections those are, why they matter differently in a software context, and what they should actually contain. By the end you should be able to open your template and know precisely where to focus your effort.
Why a Software BRD Is Structurally Different
The core purpose of any BRD is the same: capture what the business needs, not how the solution should be built. But when the solution is a software system, the requirements you capture have consequences that are absent from process work. A requirement in a software BRD will drive architecture decisions, database design, integration scoping, and test plans. Vagueness is more expensive. Omissions get discovered at UAT rather than in a workshop.
The other difference is audience complexity. A process BRD might be read by three people. A software BRD will be read by developers, testers, architects, the project manager, procurement, and possibly a third-party vendor. Each of them needs to find the information relevant to their role without interpreting it differently. That changes how you write and structure the document.
If you want a clear breakdown of how business requirements relate to functional requirements in a software context, the article on business requirements document vs functional requirements document covers that boundary in detail.
The Sections That Change in a Software BRD
1. Scope Section: System Boundary, Not Just Project Boundary
In a process BRD, scope describes what activities are in and out. In a software BRD, you need to describe the system boundary explicitly: what the new system will do, what it will not do, and what it will connect to. This is where in-scope and out-of-scope integrations belong, not buried in assumptions.
When I worked on an EOI for a large public-sector education provider (Organisation A) who needed a timetabling and scheduling system across 53 campuses and nearly 79,000 students, one of the first things we established in the scope section was the integration boundary. The system needed to connect to a student information system, an HR platform, a finance system, a learning management system, and a building energy management system. Each of those connections was a discrete scope decision. Getting that into the BRD upfront meant vendors responding to the EOI could immediately understand what integration work they were being asked to price. Leaving it vague would have made every tender response incomparable.
2. Stakeholder Section: Add System Users and Administrators
Most stakeholder sections list people who have a business interest in the outcome. For software projects, you also need to list the people who will operate the system day to day and the people who will administer it. These are often different people with different requirements, and missing them means missing requirements. In Organisation A’s case, the stakeholder picture included campus planners, faculty heads, students, management wanting utilisation reports, and IT staff responsible for maintaining integrations. Each had different visibility and access needs. All of them needed to appear in the BRD to drive the access and permissions requirements later.
3. Current State Section: Document the Data, Not Just the Process
In a process BRD, current state is a description of how things work today. In a software BRD, you also need to document the current data landscape: what systems exist, what data they hold, what format it is in, and what will need to be migrated or integrated. Organisation A’s current state included scheduling being done entirely in spreadsheets across three separate institutes with no centralised data and inconsistent business rules from site to site. Documenting that was not just background context. It directly shaped the data migration requirements and the business rules section that followed, because we had to explicitly state which rules would be standardised and which would remain configurable per campus.
4. Requirements Section: Separate Functional and Non-Functional
This is where most early-career BAs underspecify. A software BRD needs both functional requirements (what the system does) and non-functional requirements (how the system performs, scales, and behaves under constraint). Non-functional requirements in a software context are not optional extras. They define the architecture. If you leave them out of the BRD, you will find them appearing as late change requests or, worse, as production incidents.
The non-functional requirements template on this site covers the categories you need to work through, including performance, security, availability, and scalability.
5. Assumptions and Constraints: Include Technical Constraints Explicitly
A process BRD usually lists organisational or resourcing constraints. A software BRD also needs to capture technical constraints: mandated platforms, existing infrastructure, integration protocols, data residency requirements, and licensing limitations. These are real constraints that will shape what is deliverable, and if they are not in the BRD, they will surface as surprises during design.
Sections to Add That Do Not Appear in a Standard Template
Beyond adapting existing sections, there are several sections a standard BRD template simply will not include that a software project needs.
- Integration Requirements: List each system the new application must connect to, the direction of data flow, the frequency, and any known API or protocol constraints. This is a standalone section, not a footnote in scope.
- Data Requirements: Define what data the system will create, store, consume, and output. Include data volumes where known, because scale affects architecture. In Organisation A’s case, the system needed to handle over 570,000 subject enrolments and 22,000 individual class instances. That is not a footnote. It is a sizing requirement that goes directly to the vendor.
- User Access and Permissions: Define role-based access requirements. Who can view, who can edit, who can approve, and who can administer. This section drives both the security architecture and the user acceptance test scripts.
- Reporting and Analytics Requirements: Software systems generate data. The business will want to report on it. Capture what reports are needed, at what level of granularity, and for which stakeholder groups. In Organisation A’s case, management needed utilisation views per campus, per programme, and per instructor. Each of those was a distinct reporting requirement that needed to appear in the BRD, not be discovered during UAT.
- Migration Requirements: If there is data to be moved from a legacy system, this needs its own section covering what is being migrated, the quality of the source data, any transformation rules, and acceptance criteria for migration success.
A Worked Example: Where the Friction Was
On the Organisation A timetabling project, we reached the requirements section and hit a significant problem. The business stakeholders could not agree on what the business rules for scheduling actually were. Each of the three institutes had evolved its own rules over years of using spreadsheets. When we tried to document a single set of scheduling business rules for the BRD, the heads of each institute disputed each other’s rules in the workshop.
The instinct of the project director was to park the issue and proceed with high-level requirements, leaving the detail for implementation. I pushed back on that. A software system cannot be built around ambiguous business rules. The vendor would make assumptions, build to those assumptions, and the organisation would spend the implementation phase arguing about configuration rather than delivering value. We escalated it as a scope risk and added an explicit pre-contract activity: a business rules workshop to produce an agreed rules register before the RFP went out. It delayed the procurement timeline by six weeks. It saved considerably more than that during implementation.
That kind of friction is normal in software BRD work. The document forces decisions that process work can sometimes defer. That is one of its most important functions.
Comparing a Standard BRD Template with a Software-Specific One
| Section | Standard BRD Template | Software Project BRD Template |
|---|---|---|
| Scope | Project boundary and deliverables | System boundary, in-scope and out-of-scope integrations |
| Stakeholders | Business sponsors and affected teams | Business sponsors, system users, administrators, IT operations |
| Current State | As-is process description | As-is process plus current data landscape and legacy systems |
| Requirements | Business and functional requirements | Business, functional, and non-functional requirements (separate) |
| Assumptions and Constraints | Organisational and resourcing constraints | Organisational, resourcing, and technical constraints |
| Integration Requirements | Not typically present | Dedicated section with per-system detail |
| Data Requirements | Not typically present | Data volumes, formats, migration, and data quality criteria |
| User Access and Permissions | Not typically present | Role-based access matrix by user type |
| Reporting Requirements | Mentioned briefly if at all | Dedicated section with report specifications per stakeholder group |
Practical Tips for Filling Each Added Section
If you are building your software BRD template now and staring at a blank integration requirements section, here is how to populate it without getting lost.
- Start with the system landscape: Ask IT or the architect to give you a list of all systems the proposed software will touch. You do not need to know the API details at BRD stage. You need to know the names, the data that crosses between them, and the direction.
- Use the data requirements section to drive conversations: Most business stakeholders have not thought about data volumes. Asking “how many records will the system hold in year one?” surfaces assumptions that, if left undocumented, become contractual disputes with vendors.
- Write access requirements from user stories, not from org charts: An org chart tells you job titles. A user story tells you what someone needs to do and therefore what access they need. Working backwards from tasks produces a more accurate permissions model.
- Treat non-functional requirements as a checklist: Performance, availability, security, scalability, maintainability, compliance. Work through each category and explicitly state whether it applies to your project. A stated “not applicable” is better than a blank field, because it shows the decision was made consciously.
- Cross-reference to your requirements traceability matrix from the start: Number your requirements as you write them. The requirements traceability matrix will need to pick those numbers up later, and retrofitting numbering after the fact is painful and error-prone.
The single biggest mistake I see early-career BAs make with software BRDs is treating the document as a process BRD with a technical flavour added at the end. The structural changes outlined here are not cosmetic. They reflect the fact that a software system is a complex artefact with its own internal logic, and the BRD is the document that tells developers, testers, and vendors what that logic needs to serve. Getting the structure right before you start writing saves you from the worst outcome in software BA work: a technically delivered system that nobody can use because the real requirements were never properly captured.
Frequently asked questions
What should a business requirements document for a software project include?
A software BRD should include a system boundary and scope section, stakeholder analysis covering both business users and system administrators, functional and non-functional requirements in separate sections, integration requirements for each connected system, data requirements including volumes and migration needs, and a user access and permissions section. It goes further than a standard BRD because the requirements directly drive technical architecture decisions. Leaving out non-functional requirements or integration scope is one of the most common and costly omissions.
What is the difference between a BRD and an FRD for software projects?
A BRD captures what the business needs the system to achieve, written in business language without specifying how the system will be built. An FRD translates those business requirements into specific system behaviours, features, and functions that developers can implement. On most software projects the BRD comes first and is owned by the BA, while the FRD follows and may involve input from solution architects or developers.
Do I need non-functional requirements in a BRD or only in an FRD?
Non-functional requirements belong in the BRD because they are business requirements, not just technical ones. Performance thresholds, availability expectations, security standards, and compliance requirements all originate from business context and constraints. If you leave them out of the BRD, they either get invented by the development team without business input or they surface as late-stage change requests.
How do I write integration requirements in a software BRD?
For each system the new software must connect to, document the system name, the data that will flow between the two systems, the direction of that flow, the frequency, and any known protocol or API constraints. You do not need to specify the technical implementation at BRD stage, but you do need enough detail that a vendor or architect can scope the integration work and identify risks. Missing integration requirements is a leading cause of cost overruns in software projects.
Can I use a standard BRD template for a software development project?
You can use a standard template as a starting point, but you will need to add or significantly adapt several sections before it is fit for purpose on a software project. The sections that need the most work are scope, constraints, requirements, and anything related to data or integrations. Using an unmodified process BRD template for a software project typically produces a document that satisfies governance but fails to give developers and vendors what they need.
Try Ash, Your Virtual BA
If you are working through a software BRD right now and need help structuring the integration requirements section, defining your non-functional requirements, or just getting the first draft written, Ash can help you do exactly that. Ash is built specifically for business analysis work and can produce a structured business requirements document tailored to a software project, including the sections that standard templates miss. Try Ash Virtual BA and get your BRD moving today.
Further reading
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
- Requirements improved project performance
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.