How to write a business requirements document: Template, examples, tips
When beginning a project and partnering with a vendor, it’s crucial that everyone involved understands the expected outcomes of the partnership. That’s where a business requirements document (BRD) comes in handy. Often, a BRD is used to detail a business’s needs when seeking a new technology provider, consultant or contractor.
In order for the business requirements document to be clear and successful, many factors must be carefully considered and included. In this article, we’ll explore what a business requirements document is, how to write one, what to include as well as templates and examples to get you started.
What is a business requirements document?
A BRD is a formal document that outlines the goals and expectations an organization hopes to achieve by partnering with a vendor to complete a specific project. Remember, it’s important to understand this is not the same as a functional requirements document (FRD).
What’s the difference between a business requirements document and functional requirements document?
A BRD deals with what an organization hopes to achieve through a vendor partnership. On the other hand, a functional requirements document (FRD) deals with how they expect to achieve it.
For example, imagine an organization that’s recently purchased an applicant tracking system to help with their recruiting efforts. They might use a BRD to explain that they expect to increase their candidate pipeline by 10 percent. Then, they might create an FRD to detail how they expect to achieve that goal — perhaps through integrations with popular job boards. To learn more about FRDs check out this blog.
So, how exactly do you create a BRD that effectively informs your vendor about the outcomes and expectations you have around a project?
What are the components of a business requirements document?
While each BRD is unique, they generally contain a few common sections. You’ll find each of these sections in our downloadable business development requirements template.
Executive summary
The executive summary sets the stage for the entire document. In fact, this is the first section your vendor will read. So, make sure you hold their attention and quickly convey all the necessary information. Essentially, the executive summary should set the stage for the BRD.
Project overview and objectives
In this section, you’ll go into detail about the project. Certainly there’s a lot of ground to cover in this section. For example, you can explore the current process, business drivers, users and departments affected. You’ll want to be as specific as possible to avoid confusion once the project begins.
Consider including:
- Overall goal(s) for the project
- A high-level description of what the project will accomplish
- How the goal supports larger strategic objectives
- A list of stakeholders involved
- Background of the project (How it came to be and issues or problems experienced)
- Business drivers that make this project important (Operational, market, environmental or financial)
- Description of current process and proposed process (Diagrams can be helpful)
Business requirements
Here is where you’ll cover your goals in greater detail. Generally, we recommend using SMART goals — which are specific, measurable, achievable, relevant and time-bound. Not only will this will help you effectively communicate your expectations with your vendor but it also provides a simple way to evaluate success when you finish the project. You can learn more about SMART goals in this blog from FitSmallBusiness.com.
While brainstorming your business requirements, consider your priorities. For example, designate each of your requirements as critical, high priority, medium priority, low priority or a future requirement. Ultimately, you’ll need to assign importance to each in your final BRD.
Project scope
The project scope is one of the most important sections in your BRD. This will explain what your organization is responsible for and what your vendor is responsible for.
Remember, be as detailed as possible, and don’t make any assumptions. Unfortunately, when misunderstandings with a vendor arise over the course of a project, you can usually trace them back to a vague or confusing project scope.
Glossary
Try to use common language as much as possible within your business requirements document. However, that’s not always possible. Use this section to define any terms the vendor might not understand. For instance, if you’re using terminology specific to your business, industry jargon or acronyms, this section is crucial to effectively communicate your requirements to your vendors.
Interested in seeing how RFP360 could improve your business requirements document and procurement processes? You can see it for yourself by scheduling a demo now.
9 business requirements document templates to get you started
Every organization, partnership and project is unique. From simple to highly-complex projects, you’ll find a template to fit your needs in this collection. Above all, you must ensure your BRD captures the intricacies of your specific requirements. Use the templates below as a starting place, but make edits when needed.
1. RFP360
This business requirements document template is a quick and easy guide to creating your own BRD. In the template you’ll find the sections including executive summary, project overview and objectives, business requirements, project scope and glossary. Along with each section you’ll see handy tips and guidance for how to use them.
2. SFSU
San Francisco State University (SFSU) created this three-page BRD template. It’s fairly short, so you can use it to convey your requirements for simple projects. For this reason, this format is best when you only need a small amount of detail before proceeding. A great option for quick projects.
3. PandaDoc
This PandaDoc BRD template guide includes 13 sections — and tips for how to best prepare each one. For example, in the executive summary, the document offers the following advice:
“An executive summary should be no more than three paragraphs long and should provide a concise summary of the purpose and contents of the rest of the document. It is usually best to draft this section last.
4. TechWhirl
TechWhirl’s BRD template is primarily designed for a technology project. It includes several charts and spreadsheets to document edits, revisions, approvals, requirements and more. In addition, it contains brief descriptions of the information each section should contain, as well as examples of how to present that information.
For example, in the objectives section, it explains:
“These should describe the overall goal in developing the product, high level descriptions of what the product will do, how they are aligned to business objectives, and the requirements for interaction with other systems.”
Directly below this description, it offers the following example:
- Deliver a Widget Interactive Naming System (WINS) that synchronizes naming and linking of all widgets in all systems across the enterprise
- Avoid duplication of widget names and reduce time to production for existing projects
- Support text searching on widget names or business descriptions
- Sync widget names and changes to Windows and Linux platform administration tools
- Track changes to widgets including new widgets, modified widgets and widgets to be archived
5. Requirements experts
The RequirementsExperts template is a nice option if you prefer working in Excel over Word. In addition, each section includes a short description of the information needed.
The spreadsheet consists tabs for the following sections:
- Business requirements
- System-product requirements
- Lifecycle trace matrix
- Requirements trace matrix
6. British Columbia
The BRD template from British Columbia includes black text intended to remain in the final document. Similarly, it includes red text that contains instructions or examples. This text is meant to be deleted and replaced with the information specific to your requirements.
7. T System
This T System BRD template contains 11 pages full of spreadsheets, charts and boilerplate content. Included are examples and flow charts to help provide guidance for creating your own. Unfortunately, the template isn’t downloadable. However, it does provide excellent inspiration.
8. New York University
This template from New York University is fairly advanced. Notably, it includes version tracking charts, spreadsheets, diagrams, and blue-highlighted text, which indicates where to insert your specific requirements.
Because of the detail this template covers, it’s probably not a good choice for those creating their first BRD. But, if you’re experienced creating BRDs and want to cover all of your bases, this is a great option.
9. DatabaseStar
DatabaseStar’s BRD template contains 12 sections over 14 pages. Luckily, each section includes detailed instructions about the information you should include. Uniquely, this document also covers functional requirements, which may not be necessary for every project.
- Executive summary
- Project description
- Project scope
- Business drivers
- Current process
- Proposed process
- Functional requirements
- Non-functional requirements
- Glossary
- References
- Appendix
- Document history
4 business requirements document examples to show you how it’s done
While templates can give you a great starting point, chances are you could use some extra help. Especially if you’re writing your first BRD. The first thing to remember is you have to make it work for your business.
The BRD examples listed below show what an effective BRD looks like. In addition, they also provide direction as you start documenting your own requirements.
1. Simplicable
Simplicable created “an illustrative example of a business requirements document for a system project undertaken by a fictional telecom company.”
It includes the following seven sections:
- Background
- Business case
- Assumptions
- Constraints
- Functional requirements
- Non-functional requirements
- Glossary of terms
In each section, they demonstrate how their fictional telecom company, Neverland Telecom, would outline their requirements. For example, in the Business Case section, they use the chart below to outline the goals and objectives.
2. GLSEN
This BRD example outlines the goals and expectations of a website redesign definition. The example uses a marketing agency completing the redesign for GLSEN.
Consequently, the document explains the purpose.
“…to express the requirements of the customers and stakeholders to be served by the deliverables of the project-the perceived customer wants and needs for a product, system, or service.”
3. IATA
The International Air Transport Association (IATA) created a BRD to help create “a standard process for airlines to distribute product offers created within their own systems and to manage the resulting orders.”
Uniquely this example includes highly-detailed explanations and charts. It is perfect for those who need some inspiration to create a highly technical or detailed BRD.
4. Department of Veterans Affairs
The Department of Veterans Affairs explains the purpose of this BRD below.
“The Business Requirements Document (BRD) is authored by the business community for the purpose of capturing and describing the business needs of the customer/business owner. The BRD provides insight into the AS-IS and TO-BE business area, identifying stakeholders and profiling primary and secondary user communities. It identifies what capabilities the stakeholders and the target users need and why these needs exist, providing a focused overview of the requirements, constraints, and Information Technology (IT) options considered. This document does not state the development methodology. The intended audience for this document is the Office of Information and Technology (OIT).”
This BRD example is great for organizations who want to see how to outline very technical and stringent project requirements.
How does a business requirements document fit into the RFx process?
While BRDs are similar to many RFx documents — including requests for proposals ( RFPs), requests for information ( RFIs), requests for quotations ( RFQs), and more — they do serve a distinct purpose.
Here’s how The Balance Small Business explains the difference between BRDs and procurement documents like RFPs.
“Typically, a request for proposal (RFP) is created for the purpose of soliciting proposals from various vendors.
“A BRD, on the other hand, is prepared for a specific vendor or joint venture partner who has already been selected by the hiring company. The BRD contains more details and more specifications and deadlines to be met along the way and at the end of the project.”
Put simply, RFx documents are used to identify which vendors your organization wants to partner with. Then, BRDs outline the goals and expectations you have for the vendor you ultimately select. Certainly each process and document has a place in the procurement team’s tool box.
RFP360 supports strategic vendor partnerships with capabilities that.
