Start With the Content, Not the Label
If you have a document in front of you and you are not sure whether it is a BRD or an FRD, or you are trying to work out which one you need to write, the fastest way to sort it out is to look at the content, not the title on the cover page. I have seen documents labelled “Business Requirements Document” that were full of system behaviour specifications, and documents called “Functional Specifications” that were essentially scope statements dressed up with technical headings. The label tells you very little. The content tells you everything.
What I want to do in this article is show you, using real sample text and a worked example, exactly what belongs in each document and where the line sits between them. If you need a deeper conceptual grounding first, the article on BRD vs FRD covers the theory. This article is about the content itself: what a sentence in a BRD looks like versus what the equivalent sentence in an FRD looks like, and why that difference matters in practice.
The Core Distinction in Plain Language
A BRD captures what the business needs to achieve. An FRD describes how a system will behave to meet those needs. The BRD is written from the business perspective. The FRD is written from the system perspective. When I write a BRD, I am speaking on behalf of stakeholders. When I write an FRD, I am translating those needs into something a developer, configuration engineer, or vendor can build or configure against.
Here is the simplest test I use: if you removed every reference to technology from the sentence and it still made sense as a business statement, it belongs in the BRD. If the sentence describes what a system does in response to a user action or a data condition, it belongs in the FRD.
Sample Content Side by Side
The table below shows the same business need expressed first as a BRD requirement and then as the corresponding FRD functional requirement. These examples are drawn from a utilities sector project (Project X) involving a document management solution, a waterfall COTS procurement, and from a health sector patient scheduling project I worked on. I have also included a finance sector example to show how the pattern holds across domains.
| Business Requirement (BRD) | Functional Requirement (FRD) | Domain |
|---|---|---|
| The organisation must be able to retrieve engineering drawings by asset identifier, revision number, and document status. | The system shall provide a search interface allowing users to filter documents by asset ID, revision number, and status (Active, Superseded, Draft). Results shall be returned within three seconds for any dataset up to 500,000 records. | Utilities / Asset Management |
| Clinical staff must be able to view a patient’s upcoming appointments across all care settings from a single location. | The system shall display a consolidated appointment list for a selected patient, ordered by date ascending, showing appointment type, location, clinician, and status. The list shall refresh automatically when a new appointment is booked within the same session. | Health |
| Finance teams must be able to generate monthly expenditure reports grouped by cost centre and approved budget line. | The system shall allow users with the Finance Reporting role to generate a monthly expenditure report. The report shall group transactions by cost centre and budget line, display variance against approved budget, and export to CSV and PDF formats. | Finance |
| Users in regional locations must be able to access the system with acceptable performance over low-bandwidth connections. | The system shall load the primary dashboard within five seconds on a connection speed of 2Mbps or above. Performance requirements shall apply equally to users in metropolitan and regional network zones. | Utilities / Infrastructure |
Notice what is happening in each row. The BRD column describes a business capability or outcome. The FRD column specifies the system behaviour, the user role, the data fields, the performance threshold, and the format. The FRD is not more important than the BRD. It is the downstream translation of it. You cannot write the FRD well without a solid BRD to work from, and that sequencing matters.
A Worked Example: Project X Document Management Solution
On Project X, a waterfall COTS procurement for an engineering drawing management solution in the utilities sector, the BA approach document was explicit: the BRD would focus on process flows and use cases in enough detail to select the preferred vendor. Individual functional requirements would not be captured in the Develop phase. Instead, the vendor would provide the Functional / Configuration Specification in the Deliver phase, with Organisation A’s BA team responsible for quality assurance of those vendor-produced artefacts.
That sounds clean on paper. In practice, it created a significant problem during vendor evaluation. We had written process flows and use cases at the BRD level, but the procurement team needed to score vendors against functional criteria. When the evaluation criteria were drafted, the procurement lead asked me for a list of functional requirements to underpin the scoring matrix. I had none, because the approach document said we were not producing them in this phase.
The friction came when I pushed back on this. The procurement lead’s position was that vendors needed something concrete to respond to. My position was that jumping to functional requirements at this stage would mean I was pre-determining the solution before we had selected a vendor, which undermined the purpose of a COTS evaluation. We went back and forth for two weeks. The resolution was a compromise: I produced a set of “capability statements” derived directly from the use cases, written at a level of specificity that was functional enough to evaluate against without being a full FRD. These sat outside both the BRD and the eventual FRD, and the project governance team had to decide how to classify them for traceability purposes.
The lesson from that experience is that the boundary between BRD and FRD is not always a clean line on a project. The documents serve different audiences at different phases, but the phases do not always cooperate with the theory. If you are on a COTS procurement, plan early for the gap between what your BRD delivers and what your evaluation process needs.
What Each Document Must Contain: A Checklist
When I review BA documents for quality, these are the elements I expect to find in each type. Each item below is what I check for specifically, not a generic list of possible content.
- BRD: Problem or opportunity statement. A clear articulation of what business problem is being solved or what business opportunity is being realised, written without reference to any specific system or technology.
- BRD: Scope statement with explicit inclusions and exclusions. What is in scope for this piece of work, and what is explicitly out of scope, agreed with stakeholders and signed off before requirements elicitation begins.
- BRD: Stakeholder-attributed business requirements. Each requirement should be traceable to a stakeholder group or business objective, not to a technical team or system component.
- BRD: As-is and to-be process context. Even at a high level, the BRD should show the current state and the target state so that requirements are grounded in a process change, not just a wish list.
- FRD: Individually referenced functional requirements. Each requirement needs its own unique identifier so it can be traced, tested, and managed through change control independently.
- FRD: System behaviour descriptions with trigger, action, and response. A well-formed functional requirement describes what triggers the behaviour, what the system does, and what the output or result is.
- FRD: User roles and permissions. The FRD should specify which user roles can perform which actions, because access control decisions belong at the functional level, not in the BRD.
- FRD: Non-functional requirements cross-referenced. Performance, security, and availability requirements are not functional requirements, but the FRD should reference them where they constrain system behaviour. For a dedicated resource on this, the non-functional requirements examples and templates article is worth reading alongside this one.
- FRD: Traceability to BRD. Every functional requirement should trace back to at least one business requirement or use case in the BRD. This is what enables impact assessment when requirements change. The requirements traceability matrix article explains how to structure that linkage.
The Sections That Confuse People Most
Use Cases: BRD or FRD?
Use cases sit in a difficult position. In my experience, high-level use cases, meaning the main flows and alternate flows written at a process level, belong in the BRD. Detailed use cases that describe specific system interactions, screen transitions, error handling paths, and data validation rules belong in the FRD. On Project X, the BA approach document specified that use cases in the Develop phase should cover main flows and alternate flows at the BRD level. In the Deliver phase, the vendor was required to expand these into detailed use cases as part of the Functional / Configuration Specification. That is a sensible split, and it is the one I would recommend as a default.
Data Requirements
Data requirements are another area where I see a lot of overlap between documents. At the BRD level, data requirements describe what data the business needs to capture, access, or report on, without specifying data types, field lengths, or database structures. At the FRD level, data requirements become specific: field names, data types, validation rules, mandatory versus optional, and the conditions under which data is created, updated, or archived. If your BRD contains field-level data specifications, you have gone too far. Pull them into the FRD and replace them with a business-level statement of what data is needed and why.
Non-Functional Requirements
Non-functional requirements are not functional requirements, but they affect how functional requirements are written. The performance requirement on Project X, that the system should perform particularly well for users in regional locations, was noted at the BRD level as a business constraint. In the FRD, it would become a specific measurable threshold, such as a maximum response time at a defined connection speed, as I showed in the sample table above. Capture the business intent in the BRD. Specify the measurable threshold in the FRD.
A Note on Document Order and Traceability
One practical point I want to make before closing: on projects where the BRD and FRD are produced by different parties, as they were on Project X where the vendor was responsible for producing the FRD, you need to be explicit about what the vendor is expected to trace back to. If your BRD contains use cases with unique identifiers, tell the vendor that every functional requirement in their FRD must reference one of those use case IDs. If you leave this unspecified, you will receive a functional specification that is untraceable to your requirements, and your quality assurance review will be far more painful than it needs to be. I have been in that situation and spent two weeks retrospectively mapping vendor specifications back to BRD elements that should have been linked from the start.
The real value of keeping BRD and FRD content separate is not tidiness. It is that they serve different conversations at different times: the BRD is what you use to align stakeholders and define scope before a solution exists, and the FRD is what you use to hold a vendor or development team accountable to something precise and testable. Conflating them does not save time; it just means you have one document that does neither job well.
Frequently asked questions
What is the difference between a BRD and an FRD with examples?
A BRD captures what the business needs to achieve, while an FRD describes how a system will behave to meet those needs. For example, a BRD might state that finance teams must be able to generate monthly expenditure reports by cost centre, while the FRD would specify the exact report fields, user roles, export formats, and performance requirements. The BRD is written for business stakeholders; the FRD is written for developers, configuration engineers, or vendors.
Can you have an FRD without a BRD?
Technically yes, but it creates real problems in practice. Without a BRD, there is no agreed business foundation for the functional requirements, which means you cannot trace system behaviour back to a business need or assess the impact of changes accurately. On COTS and vendor-led projects in particular, skipping the BRD often results in a functional specification that reflects what the vendor can build rather than what the business actually needs.
What goes in an FRD that does not go in a BRD?
The FRD contains system-specific content that has no place in a BRD: individual functional requirements with unique IDs, system behaviour triggered by user actions, user roles and permission levels, field-level data specifications, validation rules, and error handling flows. The FRD also links each functional requirement back to a business requirement or use case in the BRD via a traceability reference.
Where do use cases go in a BRD vs an FRD?
High-level use cases covering main flows and alternate flows at a process level belong in the BRD. Detailed use cases that describe specific system interactions, screen transitions, data validation, and error handling belong in the FRD. This split allows the BRD to serve solution selection and stakeholder alignment, while the FRD supports build, configuration, and testing.
How do I know if my requirements document is a BRD or an FRD?
Remove every reference to technology from a requirement and check whether it still makes sense as a business statement. If it does, it belongs in the BRD. If the requirement describes what a system does in response to a user action, a data condition, or a trigger event, it belongs in the FRD. If your single document contains both types, it is doing two jobs and should probably be split.
Try Ash, Your Virtual BA
If this article has helped you understand what belongs where, Ash can take that further by helping you actually produce the content. Ash is a virtual BA assistant that can help you draft BRD sections, write well-formed functional requirements, and structure your FRD from scratch, all based on the specifics of your project. Rather than staring at a blank template and trying to remember whether a requirement is business-level or functional, you can work through it with Ash in real time. Try Ash Virtual BA and see how quickly a structured, traceable requirements document comes together.
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.