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
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:
Learn more about the difference between functional and non-functional requirements from our detailed explainer.
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.
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.
We have a BRD explained in a video format too
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.
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
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:
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.
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.
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.
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.
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:
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:
This project does not cover:
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 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 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.
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.
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) . . .
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.
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.
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.
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.
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.
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.
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.
