How to Write a Business Requirements Document: Guidelines, Templates, and Useful Tips

Reading time:

11

minutes

Not all projects are winners. According to the 2021 survey conducted by the Project Management Institute, poor requirements gathering and poor upfront planning are among the key reasons why many projects fail. So, what can you do to make your project a winner? Start with a thoroughly written business requirements document or BRD.

From this article, you’ll learn everything about business requirements documents and get well-structured templates for a complete picture of the topic. Also check our video on technical documentation in software development.

Software documentation, explained

Business requirements vs other types of requirements

Before explaining how to write business requirements, let’s look at how they differ from other types of requirements used in product management. This will help you see the overall software documentation landscape. It’s worth noting that though separate categories of requirements may have shared high-level goals, it doesn’t mean they can be used interchangeably.

According to the BABOK (Business Analysis Body of Knowledge) guide, currently the main reference source for business analysis, project requirements can be classified in the following ways.

Product requirements classification schema

Business requirements define the strategic path of a project. They include high-level project requirements that describe the overall business objective from the company’s perspective. The objective could be to increase profit margin or capture a bigger market share. Based on the scope, business requirements can be as simple as a couple of lines describing key business needs or a very complex set of objectives across different work domains.

User requirements, also referred to as stakeholder requirements, are statements that describe what value individual user groups (customers, managers, etc.) expect a certain solution to deliver. These statements are often seen as a bridge between the broad-based business requirements and specific system requirements.

Product requirements, also referred to as solution requirements, are specific descriptions of the capabilities and qualities a solution must have to meet the requirements of users and the business itself. They come with a certain level of detail to enable effective solution development and implementation. Product requirements fall into two categories:

• functional requirements that describe the features and functions that a solution must have in terms of the behavior, and
• nonfunctional requirements that describe the general conditions of the solution to function properly, accordingly also known as quality of service requirements.

Transition requirements are additional requirements that define capabilities and conditions a system must have so that an organization can move from the current state to the future state. They have a temporary nature as they are used only during the transition phase. Such requirements may address questions of data conversion or staff training.

Whatever the case and type of requirements, you need to define them as clearly as possible for a project to succeed.

What is a business requirements document (BRD)?

A business requirements document (BRD) is a formal description of business-related objectives and expectations an organization has regarding a specific project or business solution. It commonly explains reasons to start a project, the set of business values it is expected to provide, and the purpose behind doing the project, etc. The main idea of a BRD is to clarify all the business aspects of a project.

People involved in creating a BRD

In a project lifecycle, a business requirements document is one of the first steps. It includes a broad view of the work that must be completed. As a rule, writing a BRD is the responsibility of business analysts, but there may be a lot of other specialists involved in documenting business requirements. They include the project’s development team, product managers, business partners, top-level managers, subject matter experts, and project sponsors, to name a few.

Why business requirements documents are important

While the advantages of writing a business requirements document may seem to be obvious, it’s worth pointing out some of the most significant ones.

With a thoroughly developed BRD, you can

• provide reasons for initiating a project,
• reduce the chance of project failure due to misinterpreted requirements,
• connect a project to needed business goals,
• minimize rework and costs associated with it,
• create a clear roadmap of project development and monitoring,
• improve communication between different stakeholders, and much more.

How to get started with BRDs

Before rolling up your sleeves and starting to write a BRD, you need to do some prep. Consider taking the following steps.

Getting all parties involved. To make sure that the document covers all aspects of the upcoming project, it is important to engage different stakeholders and gain their consensus. These can be product owners, business analysts, marketers, developers, and financial analysts, to name a few. Besides, this is a great way to look at the project from different angles, which may bring innovative solutions to the set of issues.

Eliciting the requirements. Discussing what requirements should be in a document is one of the first steps to take. There are many techniques that you can use to elicit the right business requirements for your project. The popular ones include:

• brainstorming — bringing different specialists such as product managers, business architects, UX teams, etc., together to generate ideas for the project and decide what will work well;
• one-on-one interviews — building a plan with an individual or a small group of end users and/or clients;
• observations — observing how a certain process or workflow functions; and
• surveys — gaining feedback from large groups of stakeholders by means of questionnaires.

Establishing standards for requirements. Since the project may consist of different phases and involve different experts, it’s smart to create the standards for requirements to take control of the quality of work and progress.

How to write a business requirements document

While every project is unique in terms of things like objectives, requirements, budget, timeframe, etc., the basic structure of BRDs often contains the following sections.

• Executive summary
• Project objectives
• Project scope
• Stakeholders
• SWOT analysis
• Financial statements
• Functional requirements
• Schedule and deadlines
• Cost-benefit analysis

Key sections of a business requirements document

Let’s now look at each one in more detail. But keep in mind that you may not need all of them in your document.

Executive summary

The executive summary is a short statement outlining the background and main points of the project. It sets the tone of the entire document and is the first thing those who are going to read it see. So, make sure that the section grabs readers’ attention, conveys all the necessary information in a concise form, and links a document to overall business goals. Also, if the BRD is a result of any previous meetings or documents, you can provide relevant references.

Useful tip: Keep the summary relevant and no more than three paragraphs long so that someone can quickly decide what the document is about.

Example: [A company name] currently faces several challenges that are impeding user engagement with its eCommerce website. The average time spent on a page is about 1 minute. Potential shoppers abandon the cart in 70 percent of the cases. The growth of new website visitors has decreased by 10 percent compared to the previous year. [A company name] needs to redesign the landing page and popular product pages of its eCommerce platform and improve checkout functionality to solve the challenges.

Project objectives

This is the place for defining all high-level goals of the project. Who is the project for? What are its end goals? How do the project objectives link to the overall business goal? Basically, this section provides detailed explanations of how you see success along with performance metrics.

Useful tip: During this step, you may use the SMART approach to clarify goals, ensuring that they are specific, measurable, achievable, realistic, and time-bound.

Example:

By redesigning a website, our company aims to achieve the following goals:

1. Launch 3 ad campaigns to promote a redesigned eCommerce website within a month.
2. Gain min 100,000 unique visitors to the website by the end of Q4 2021.
3. Increase average time on website from 1.2 minutes to 3 minutes by the end of Q4 2021.
4. Decrease cart abandonment by 40 percent by the end of Q4 2021.

Project scope

The scope part explains what and how much work needs to be completed. The clear scope of the project determines its boundaries and coordinates all teams, which helps to avoid resource waste.

Useful tip: This part of a document shows what business functionality is in scope and out of scope for implementation. So, it’s a good idea to make a clear distinction with bulleted lists of the areas the project will and will not cover.

Example:

In scope for the project:

• Redesign the user flow on the landing page.
• Redesign the checkout flow.
• Redesign product pages.
• . . .

This project does not cover:

• shapes and colors of click buttons, and
• the platform background theme.
• . . .

Stakeholders

Once the scope of work is outlined, it’s time to identify key stakeholders. These can be both internal and external analysts, consultants, managers, product owners, developers, and other individuals whose interests must be considered throughout the project. You can write down each person’s name, position, department and clarify their roles and responsibilities in the context of the project. With everyone being aware of what tasks are theirs, you eliminate ambiguity and confusion.

Useful tip: If you want some stakeholders to approve a document, make sure to list them separately along with such information as approval dates and document versions.

Example:

The table format that can be used to list stakeholders

SWOT analysis

SWOT is a strategic planning framework used by organizations to analyze their strengths, weaknesses, opportunities, and threats. Strengths and weaknesses belong to internal factors while opportunities and threats belong to external ones. It is a good practice to complement a business requirements document with a SWOT analysis of the business and the vision of how a project fits into it. This part is especially useful if you need to enhance your credibility in the eyes of other parties involved in a project.

Useful tip: The main idea of SWOT analysis is to concentrate on strengths and use existing opportunities while trying to avoid threats and minimize weaknesses.

Example:

SWOT analysis on the example of an eCommerce shop

Financial statements

Financial statements are another crucial step while documenting business requirements as they provide a general view of what impact the project will have on the company’s expenses and revenues.

Useful tip: This section should be accompanied by details about how the project will be financed.

Example:

The strategy and planning phase of the engagement totals $51,000 with production costs to be estimated after sitemap, wireframes, and comps are approved by the client. We are currently estimating production costs to be in the $80,000 range for Phase 1. We’ve identified additional functionality and website features that can be implemented in additional phases as more funds become available.

Functional requirements

The most important section summarizes all the functional requirements of a business project. Depending on the situation, they can be only high-level ones answering the “what” question or accompanied by technical requirements explaining the “how” part.

Useful tip: Avoid overstaffing your project with requirements. For this, you can use the Agile approach where all requirements are put in priority order with must-haves developed first. You can also include the name of a person who put forward a particular requirement.

Example:

• A user can intuitively navigate to the most popular product pages from the landing page.
• A user can access a shipping calculator within a cart before checkout.
• A user can add an item to a cart and remain on a product page to browse other products.

Schedule and deadlines

Your business requirements document should also contain a detailed schedule along with all important deadlines and critical milestones to monitor progress and get timely deliverables. This will help you keep your team accountable and stakeholders updated on the project at specific phases.

Useful tip: You shouldn’t forget that there are always things that don’t go as planned. So, make sure you have left some wiggle room in case of any unforeseen challenges.

Example:

The redesign project will consist of four phases. Each phase will build on learnings from the previous phase to deliver specific items.

Phase I – Strategy and Planning (Timeline: 3-4 Weeks) . . .

Phase II – Design (Timeline: 10-12 Weeks) . . .

Cost-benefit analysis

The next part of the document contains information about the costs associated with the project and the expected benefits. For this purpose, you conduct a cost-benefit analysis, which is the process of predicting whether the financial gains of a project outweigh its costs.

How to approach it: To carry out the cost-benefit analysis, you will have to determine all associated costs first. Those having an impact may include upfront development costs, unexpected costs, future operating costs, tangible costs, and intangible costs.

The same thing should be done for potential benefits. Decide on your company’s ROI and ways to measure it. Will today’s investment deliver a profit?

Also, both costs and benefits should be assigned the same monetary value. Not to mention that the value of money now is thought to be greater than the value of money later on so the discount rate should be also taken into account.

Last but not least, you will need to identify the payback period – the amount of time it will take for benefits to repay the costs.

Example:

An example of the cost-benefit analysis carried out for the development of a new automated invoicing system. Source: TechnologyUK

With the initial investment of £50,000, a projected payback period of five years, and a discount rate of 15 percent, an organization can already expect a positive return during the second year with an overall internal rate of return to be £133,686.

Ready-to-use business requirements document templates

All of the above-mentioned should already have given you a general idea of how to write a BRD. However, as we said, every company and project is unique, and it may be difficult to put the puzzle together by just following the guidelines. In case you need some ready-to-use business requirements document templates and examples to fill in the necessary information, the following resources will come in handy.

• At TechWhirl, you can download a detailed BRD template that is specifically designed for a technology project. It consists of several sections for documenting requirements, edits, approvals, etc. along with brief descriptions of what information should be there and text samples.
• Stanford University IT offers a well-structured business requirements template in Microsoft Word and Google Docs formats. Within each section, you will find highly descriptive instructions of the required contents.
• TemplateLab provides a great variety of different BRD templates to download. Some of them like the one granted by the Government of British Columbia contain extensive document filling instructions. Other documents also include customizable charts and graphs.
• The Requirement Experts resource provides a nice BRD template for those who prefer working with an Excel format over Word. It’s fairly simple yet each section is equipped with a short description of what information is needed.

Now that you have some BRD templates and examples at hand, we’d like to give you a few useful tips on how to document requirements effectively.

Best practices for documenting business requirements

There are different factors that may determine whether a project will succeed or fail. A business requirements document is one of such factors. Not only does it direct the project, but also ensures that those involved are on the same page. Now that you know the structure and have some examples in place, we’d like to provide you with a few general recommendations on writing an effective BRD.

Refer to past projects

A good practice to start documenting requirements is to research past projects similar to the one you’re working on now. Having business requirement document examples under the hood saves lots of time and effort compared to writing documentation from the ground up. In this way, you can quickly single out those points that worked well and apply them to existing tasks.

Include visuals

Business requirements documents may be quite text-heavy, complicating the process of digesting the information. That’s why you shouldn’t neglect visuals.

Research has proved that our brain processes visual data 60,000 times faster than textual data. So, instead of writing walls of text, consider mixing it up with some infographics, flowcharts, Venn diagrams, etc.

Visuals are especially useful when you present business information that contains lots of numbers, complex terms, or process details. Say, charts and graphs will make it easier for stakeholders to understand the financial requirements of the project.

Be clear and concise

Often long and stuffed with details, requirements documents can be quite confusing. It’s worth remembering that not all of the stakeholders who will read the document know technical terms. To avoid misunderstandings, short, clear sentences with a minimum of techy talk are recommended. In case you must use jargon, make sure you include a glossary explaining all of them.

Once writing the BRD is done, there’s a crucial step left — information validation. It’s a good idea to have a group of subject matter experts and project stakeholders check the document and leave feedback. Revision reduces the chance of critical error and ensures that all necessary information is included.