How to create a business requirements document

A business requirements document answers two questions: What’s the problem and how do we solve it?

Along the way, a business requirements document—or BRD—also describes how your company is currently solving a problem (or not), noting existing processes and any obstacles a team might face.

Why is it important to create a good business requirements document? When you’re kicking off an ambitious project involving multiple people, a good BRD can help you clarify what’s wrong, along with what and who will be involved in correcting it. 

The BRD helps ensure there’s no “scope creep”—meaning a project sprawls in size, timeline, or budget after it’s already in progress. A solid BRD can also come in handy when you're working with outside partners like consultants, contractors, or new technology providers. 

Because it’s an important document, writing a BRD can be daunting. But fear not. We’ll walk you through each step in understanding—and then creating—a business requirements document. 

What is a business requirements document (BRD)?

A business requirements document, also known as "BRD", is a detailed guide that outlines a project’s stakeholders, timeline, goals, budget, and obstacles.

It can also provide a glossary or list of definitions for all the internal jargon and codewords that are often thrown around.  

BRD vs FRD (functional requirements document)?

A business requirements document is an overview of an entire project and its goals, while a functional requirements document (or FRD) is more technical and smaller in scale. 

The FRD provides a deep dive into how a specific team will accomplish goals outlined in the BRD. It usually outlines what must happen in order to achieve an outcome. At a software company, an FRD can also cover a program’s functionality, features, and design.

Components of a business requirements document

Unlike a details email you might send to an exec, a BRD should often—if not always—follow the same structure. Here’s how to write yours:

Executive summary statement

An executive summary describes high-level project needs. It should be short and crystal clear. There should be no ambiguity about how this project ties to your overall business goals.

A great executive summary statement helps unite your team under a clear purpose. In addition, it communicates the most critical aspects of your plan to other stakeholders and outside vendors—both of which can be critical to a project’s success. 

Project overview

If the executive summary statement sums up the “why,” the project overview details the “what.” It’s a roadmap for yourself, your team, and anyone else who needs to know what’s ahead.

In the project overview, be sure to include:

• High-level goals and objectives

• A list of involved stakeholders

• Business needs that make the project important

• How the proposed project compares to current projects or processes

Detailed objectives

What does success look like? Your BRD should define it—with specific metrics and how you can track performance. This is critical.

There are at least two ways to structure your objectives: SMART goals and OKRs. SMART goals are Specific, Measurable, Achievable, Relevant, and completed within a precise Timeframe. Setting OKRs (Objectives and Key Results) means you’re focused on achieving big goals (usually within a fiscal quarter, half, or year) and tracking all the relevant results—whether they be good or bad.

Both goal-setting frameworks help you better prioritize, align, and measure your efforts and outcomes. 

Project scope and deliverables

In your business requirements document, the project scope section should set some parameters for your project. What (or who) is and isn't included in this release? 

Deliverables are quantifiable assets that you, well, deliver. These are not always lofty documents or time-consuming designs. But they’re always pre-defined assets and they should always have a deadline. 

Both the scope and deliverables cover everyone's involvement and responsibilities, both internal and external.  

Project constraints

No project is without its limitations. That's what a project constraints section is for: to call out the obstacles a team may face as they work, including: 

• Scheduling constraints 

• Budget 

• Resources

• Quality

Glossary that defines terms and definitions

Another critical component of a BRD: a glossary of terms and acronyms with clear and succinct definitions. You should never assume that everyone involved in a project shares the same industry vocabulary. While a catchy acronym can sound pretty smart, jargon usually just wastes time. The least you can do is define the buzzwords, feature- and codenames that will be deployed.

How to write a business requirements document

So, how do you ensure that what you write in those sections is up to snuff? Consider these tips:

1. Carefully collect your requirements

In tech companies, collecting requirements often means defining software requirements. But every project can have different requirements, whether it’s software-related or not. Getting started might mean gathering feedback via brainstorming, focus groups, or prototyping. To ensure you're managing this process well, organize your work within a business roadmap framework.

2. Use simple language without jargon

When it comes to BRDs, being understood is better than being clever. You want everyone to know precisely what needs to happen, eliminating any chance of confusion or misinterpretation that can cost you time and money. A good rule is to use simple language. It's sometimes tempting to use complex or sophisticated terms and phrases, but they rarely make your writing more effective.

3. Gather information from past projects

Every project has its own life cycle and unique set of circumstances, but try to pull information from previously completed project documents to see what (if anything!) is relevant to your current project. This step is (way, way) more manageable if you're using a project database that's centralized, filterable, and easy for everyone to access.

4. Send your BRD out for review

Writing a business requirements document often involves people inside and outside your company. Those people will have varying levels of involvement, knowledge, and expertise. 

That's why it's important to have subject-matter experts and relevant stakeholders review your business requirements document. In addition, having an easy-to-use and collaborative tool for sharing and managing document feedback for this step is crucial.

5. Include images when possible

Photos, illustrations, and diagrams can convey certain types of information in a more engaging way than long, dense walls of text. Where possible, include screenshots, simple charts, and graphs to illustrate data, or sort through license-free stock image sites for images relevant to your project.

Write your business requirements document today

Writing a business requirements document (BRD) isn't like writing an email or any other business brief or memo. It contains specific components crucial to your project's success. Creating a business requirements document on a tool built for project management (like Airtable 🙂) can make the process easier for everyone involved. Here’s why. 

In Airtable, you can:

• Easily share documents inside and outside your organization.

• Share links to customizable views of your document so that each collaborator can see relevant information.

• Enhance communication and team workflow by allowing direct commenting on your documents.

• Integrate a BRD with your team's other methods of communication, such as Slack.

Wherever you are in your project, Airtable is your one workspace with endless solutions — get started with Airtable today.