You have a project in front of you, a blank document, and a stakeholder meeting in two days. The question sitting in your way is not whether to write requirements — it is whether to write them in one document or two, and what that document should actually contain. This article gives you a working template for both approaches and tells you honestly when each one is the right call.
If you are already clear on the distinction between the two requirement types, skip straight to the template structures below. If you want a quick refresher before you start building your document, the article on business requirements documents vs functional requirements documents covers the difference in practical terms.
The Core Decision: One Document or Two?
Most early-career BAs default to whatever their organisation hands them or whatever they find first in a Google search. That is rarely the right starting point. The decision about structure should be driven by three things: project complexity, audience, and how your organisation governs requirements sign-off.
I have worked on projects where collapsing everything into a single document saved weeks of cycle time, and others where doing that created a governance nightmare because finance wanted to approve business requirements before the technology team had even been briefed. The context always determines the container.
When to Use a Combined Template
A single document that captures both business requirements (BRs) and functional requirements (FRs) works well in the following situations:
- Small to medium projects with a single delivery team. When the same group of people reads both the business intent and the functional detail, splitting them into two documents creates unnecessary navigation overhead.
- Agile or iterative environments. Where requirements evolve sprint by sprint, maintaining two separate living documents doubles your version control burden with limited benefit.
- Projects without a formal staged approval gate. If your organisation does not require business sign-off before functional design begins, the separation provides no governance value.
- Early-stage or discovery work. A combined document lets you trace the line from business need to functional response in one place, which is useful during workshops and reviews.
When to Keep Them Separate
- Large programmes with multiple workstreams. Different teams often own different layers. The infrastructure team does not need to read 40 business objectives to find the system integration requirements that affect them.
- Procurement scenarios. When you are issuing a request for tender or briefing external vendors, business requirements belong in the tender document and functional requirements belong in a specification attachment. I will come back to this with a real example.
- Staged governance environments. If a steering committee must formally approve business requirements before functional design proceeds, you need separate documents to support that process.
- Regulatory or compliance contexts. Auditors and compliance teams typically want to review business intent in isolation, without wading through system-level specifications.
Template Structure: Combined Business and Functional Requirements Document
This structure works for small to medium projects where one document serves the full team. Each section header below maps to a real area of content you need to populate.
Section 1: Document Control
Version number, date, author, approval status, and a brief change log. Do not skip this. Version confusion is one of the most common reasons requirements get disputed in reviews.
Section 2: Project Overview and Business Context
A short statement of the business problem, the objective of the project, and the scope boundary. Keep this to one page. This is where business requirements begin: what the organisation needs to achieve and why.
Section 3: Stakeholders and Roles
List who provided input, who will approve, and who will be affected. Link to your stakeholder register if you have one.
Section 4: Business Requirements
State each business requirement in plain language. Number them (BR-01, BR-02, etc.). Each BR should express a business outcome, not a system feature. “The organisation requires staff to be able to publish approved content without IT involvement” is a business requirement. “The system shall provide a WYSIWYG editor with role-based publish permissions” is not — that belongs in Section 5.
Section 5: Functional Requirements
State each functional requirement as a system behaviour or capability. Number them (FR-01, FR-02, etc.) and cross-reference to the BR they support. This cross-referencing is the most valuable part of a combined document. If a functional requirement cannot be traced to a business requirement, you need to ask whether it belongs in scope at all.
Section 6: Non-Functional Requirements
Performance, security, accessibility, availability, and any relevant standards or compliance constraints. These are easy to forget and expensive to retrofit. If you need a starting point, the non-functional requirements template on this site gives you a ready-made list to work from.
Section 7: Assumptions and Constraints
What you have assumed to be true in writing these requirements, and what constraints (budget, technology, regulation) limit the solution space.
Section 8: Out of Scope
Explicitly stating what is out of scope is as important as defining what is in scope. This section is your first line of defence against scope creep.
Template Structure: Separate BRD and FRD
When you split the documents, the BRD carries sections 1 through 4 from the combined structure above, plus the out-of-scope statement. The FRD then references the approved BRD and carries its own document control, a traceability matrix linking FRs back to BRs, the detailed functional specifications, and the non-functional requirements.
The traceability matrix is the connective tissue between the two documents. Without it, the FRD floats free of its business justification and reviewers cannot tell whether a functional requirement is responding to a stated need or to a developer’s preference.
| Feature | Combined BR/FR Document | Separate BRD and FRD |
|---|---|---|
| Best suited to | Small/medium projects, single team | Large programmes, procurement, staged governance |
| Approval process | Single sign-off event | Sequential: BRD approved before FRD begins |
| Traceability | Inline cross-referencing between sections | Formal traceability matrix in FRD |
| Maintenance overhead | Lower (one document to manage) | Higher (two documents must stay synchronised) |
| Audience flexibility | Lower (all readers see everything) | Higher (different audiences read relevant documents) |
| Risk of confusion | Higher if structure is not rigidly maintained | Lower, but handoff between documents can create gaps |
A Worked Example: Where Combining Them Created Friction
When I worked on a content management system procurement for Organisation A, the project team had prepared a combined requirements document that blended high-level business drivers with detailed functional specifications. The intention was efficiency: one document, one review, move fast.
The problem surfaced the moment we issued the request for tender to vendors. Organisation A’s procurement rules required that the tender document contain the business requirements so that vendors could assess strategic fit, while the functional specifications needed to sit in a separate attachment so that vendors could complete a structured compliance response against each clause. The format actually used in that RFT separated the project background and business requirements overview in Attachment 1 from the full functional specifications in Attachment 3, with vendors required to mark each functional requirement as Supported as Delivered, Supported via Configuration, Supported via Customisation, Supported via Third Party Solution, Future Support, or Not Supported.
Because the internal document had merged everything together, I had to unpick and redistribute content across two attachments under time pressure, with the tender closing date already set. The IT manager pushed back on the functional specifications section I produced, arguing that several items I had classified as functional requirements were actually business requirements dressed up in technical language. He was right about two of them, and we had to revise the document and reissue a clarification to all respondents before the last queries date. That delay cost three days on a 25-day tender window.
The lesson I took from that project was simple: before you open your template, find out how the document will be used and by whom. The tender process required a specific structure that the internal document had not anticipated. Understanding the downstream use of requirements documentation is just as important as getting the content right, which is a point worth reading more about in the context of how BRDs and FRDs serve different audiences.
Practical Tips for Either Approach
- Number every requirement from the start. BR-01 and FR-01 are your reference anchors for every review comment, change request, and test case that follows. Renumbering mid-project is a pain you do not want.
- Write business requirements before functional requirements. If you try to write both simultaneously, functional thinking tends to contaminate business statements. The business requirement should be writable without knowing anything about the solution.
- Get explicit sign-off on business requirements before writing functional ones. Even in a combined document, treat this as a logical gate. If business requirements change after functional design has started, the rework cost multiplies quickly.
- Include a glossary for any domain-specific terms. Especially in government or regulated environments, what a stakeholder means by “publish” or “approve” may differ significantly from what a developer assumes.
- Version your document at every review cycle, not just at approval. Draft reviews often produce verbal agreements that disappear. A version stamp and change log for each iteration protects you and the project.
The question of one document or two does not have a universal answer, but it does have a right answer for your project once you know who needs to read it, how they need to use it, and what approval process it has to support. Start with those questions, pick your structure, and then build into it — rather than filling out a generic template and hoping the structure fits the context. A requirements document that serves the wrong process is not a good document regardless of how well it is written.
Frequently asked questions
What is the difference between business requirements and functional requirements in a template?
Business requirements describe what the organisation needs to achieve and why, expressed in business language without reference to a specific solution. Functional requirements describe what a system or solution must do to meet those business needs. In a template, business requirements typically appear in an earlier section and functional requirements cross-reference back to them.
Should I put business and functional requirements in the same document?
It depends on your project size, team structure, and approval process. A combined document works well for smaller projects with a single delivery team and no staged governance gate. Separate documents are better for procurement, large programmes, or environments where business stakeholders must formally approve requirements before functional design begins.
What does a functional requirements template need to include?
A functional requirements template should include document control information, a reference to the approved business requirements, a traceability matrix linking each functional requirement to a business requirement, numbered functional requirement statements, non-functional requirements, and assumptions and constraints. The traceability matrix is the most commonly omitted section and the most valuable one.
How do I write business requirements separately from functional requirements?
Write each business requirement as a statement of what the organisation needs to achieve, without mentioning any technology or system feature. Test it by asking whether the statement would still make sense if the solution were entirely manual. Once all business requirements are written and reviewed, use each one as the starting point for one or more functional requirements that describe how a system will meet that need.
Can I use one template for both a BRD and an FRD?
Yes, a combined template with clearly separated sections works for many projects. The key is to maintain strict separation within the document so that business requirement statements never describe system behaviour and functional requirements always cross-reference a business requirement. Without that discipline, the document becomes difficult to review and sign off.
Try Ash, Your Virtual BA
If you are ready to start writing your requirements document and want a shortcut past the blank page, Ash can help you produce a structured business requirements document or a combined BR/FR document tailored to your project context. Tell Ash what you are working on, what stage you are at, and who your audience is, and it will guide you through the content section by section. Try Ash Virtual BA and turn your next requirements document from a chore into a structured, reviewable artefact you can take straight into stakeholder sign-off.
Further reading
- 4.4 Understanding Requirements and Designs | The International Institute of Business Analysis™
- Requirements improved project performance
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.