For any important business decision, you need to weigh the pros and cons, risks, and potential return on investment. A business requirements document is the place to thoroughly describe a project in an organized format.
Below are some guidelines for writing a comprehensive business requirements document (known as BRDs) that you can use to articulate the rationale, goals, and shared vision for your next business endeavor.
What is a business requirements document?
A business requirements document (BRD) is a formalized description of a new project’s goals. It outlines why the company is embarking on the project, the scope of the effort, important risks or constraints to consider, and what successful implementation looks like.
You can use a BRD to define the “why” and “what” of a project—all that it entails and how it will benefit your company’s bottom line. A separate document, the functional requirements document (FRD), provides details about the project’s execution—the “how.”
What are the benefits of writing a business requirements document?
Writing a BRD for a new project allows you to:
- Define the business need. A BRD outlines why the business needs to take on the project, and what benefits may come from it. This reduces uncertainty, ambiguity, and anxiety as your business takes on a new project.
- Enhance transparency. BRDs improve project visibility between those working on the project and the department heads to whom they report. They also allow for more clarity of communication with vendors.
- Promote efficiency. Outlining budgets beforehand sets clear expectations from the top down so that vendors understand project parameters and project managers stay in the black.
Components of a business requirements document
A BRD should contain all information stakeholders may need to understand project goals and parameters. This includes:
- Project objective. Also known as the executive summary, this section discusses your goals for the new project. For example, if you want to optimize Facebook advertisements, your project objective might be to increase the return on investment (ROI) of such ads by 30%.
- Project governance. This section explains who will oversee the project and be responsible for reporting its results. You will likely appoint a single manager to lead the project team. Use this section to lay out the team structure.
- Stakeholders. Use this section to identify key stakeholders plus other staff and external partners who may have an interest in the project’s execution. Stakeholders might include the business’s C-suite, board of directors, and specific department leads, as well as the parties involved in implementing the project on a day-to-day-basis. This section should include detailed descriptions of each stakeholder’s role and responsibilities.
- Functional requirements. This section should identify the resources you’ll need to bring the project to fruition. Will you need to invest in new project management software? Will you need temporary workers or independent contractors? If the project concerns developing a new product, how will you manufacturer your prototype? What are all the costs involved?
- Scope of work. While all parts of the BRD are important, the section outlining the project’s scope is arguably the most crucial. A clearly defined project scope will identify milestones, deliverables, and acceptance criteria for the final product.
- Project limits. This section of the document outlines the project constraints. These factors include the project budget, company resources (both tools and people), technological limits, and availability of any external business partners.
- Business risks. This section outlines the potential risks associated with project implementation. Assign each risk a priority level and likelihood of occurrence, followed by mitigation strategies and designation of who is responsible for prevention and mitigation.
- Cost-benefit analysis. This process lets stakeholders understand the economic benefits and costs of a project. This analysis can help them decide whether it’s worth pursuing. A complete cost-benefit analysis considers direct costs (e.g., raw materials), indirect costs (e.g., overhead), intangible costs (e.g., opportunity cost or reputational damage), and risk costs (delays, unplanned work, etc.); it then compares them to the estimated value of benefits resulting from the project. These can also be tangible (profits) or intangible (brand goodwill).
- Success metrics. This section should include information on how you will measure a successful project. What is your desired outcome for the project? At a minimum, this section should discuss projected ROI as a direct result of the project—or the scope of loss avoided due to its implementation.
How to write a business requirements document
The best way to write a BRD is to have an existing template that you can quickly populate to meet the needs of each specific project. When constructing your first business requirement document, it helps to adhere to these best practices:
- Delegate. A business analyst typically drafts the BRD and assesses the business needs and costs associated with the project. A project manager oversees execution of the BRD, and a project director may track the manager’s progress and report to company leadership.
- Use simple language. Write your BRDs in straightforward, approachable language. Avoid jargon—you want to ensure that all stakeholders can easily understand the information in the BRD.
- Write living documents. BRDs do not need to be printed on paper and stored in a filing cabinet, never subject to change. By storing your BRDs in the cloud and permitting editing capabilities for appropriate stakeholders, you can allow for BRDs that can evolve as you and your colleagues learn more about project needs and solutions to problems.
- Include visual aids. Where appropriate, incorporate visual elements, such as charts, tables, diagrams, and illustrations to make BRDs more engaging and easy to digest.
- Collaborate. BRDs should never be written by a single stakeholder—unless you’re running your business solo. Obtain validation from a representative slate of stakeholders to ensure that your BRD meets as many potential project needs as possible.
Business requirements document FAQ
Who is responsible for creating an approved BRD?
Generally speaking, it’s best to assign a single project manager to oversee a BRD. The project manager can provide the broad outlines, which a business analyst then uses to draft the document. The project manager reviews the contents and presents a final draft to the project director and other key stakeholders for approval.
What is the difference between a BRD and an FRD?
A BRD describes a high-level business need, whereas a functional requirements document (FRD) describes the business processes needed to fulfill that need. An FRD can function as a more in-depth accounting of the functional project requirements section of a BRD. Think of a BRD as exploring the “what” and “why” of a business solution, while an FRD outlines the “how.”
What are the risks of not having a BRD?
The main risk of not having a BRD is disorganization. Without a single, coherent document guiding the implementation of a business solution, stakeholders may not understand deliverables, deadlines, and budgets—potentially leading to unexpected costs, frayed relationships with business partners, and lower employee morale.
Can a BRD be modified or updated during a project lifecycle?
A BRD can and should be modified or updated during a project lifecycle. Business is fluid, and needs and expectations may change as the project progresses. A flexible BRD will help your team to be more dynamic, responsive, and nimble.
