Business Requirements Document: What to Include on a BRD

A business requirements document (BRD) is a comprehensive document that describes what a business needs from a contractor, consultant, service provider, or internal project team. It is shared with all key stakeholders so that all parties understand the core project objectives.

A BRD plays a crucial role in getting all members of a project team aligned toward a common goal. At its core, it is a needs statement that outlines what a successful project will entail. An effective BRD can get all parties on the same page about the following elements.

• Business needs: This includes a summary of what the business needs to happen, which is the core cause of why it is paying a project team.
• Customer needs: This includes a summary of perceived client needs and how a successful project will advance business goals.
• Expectations for progress: A BRD should summarize a project lifecycle and describe expected milestones for each phase of the project.
• Shared understanding of business objectives: Before starting on the project, all project stakeholders should agree upon the scope of the project, project inputs and outputs, and the threshold for declaring the project finished.

A functional requirements document (FRD) is a close cousin of a business requirements document (BRD).

• Accessible vs. technical language: The primary difference is that a BRD uses accessible language that is clear to all team members. An FRD uses more technical terminology that may only make sense to subject matter experts.
• Level of detail: An FRD may also be more granular when describing workflow. It could include technical flowcharts, detailed descriptions of use cases, and product requirements specifications that could go beyond the scope of a more general BRD. These types of requirements will be quite relevant to some members of the project team, while they will read like gibberish to others.
• Intended audience: Sometimes an FRD will only circulate among a small group of stakeholders (like a software development team), while a BRD will get disseminated among a wider audience.

Every business project has its own unique project requirements, and this may require adjusting a BRD with agile efficiency. Still, you can start off by using this business requirements document template and adjusting it as needed.

1. 1. Executive summary: Most BRD templates start with an executive summary that lays out the full scope of the document to follow. Even though an executive summary comes at the top of your BRD, it may be wise to write it last.
2. 2. Needs statements: Explain your business needs and perceived customer needs. You do not need to propose a business solution in this section; you are simply laying out the current state of the business and what needs to change. Some business analysts prefer that this section be formatted as a SWOT analysis, which means it accounts for the business's strengths, weaknesses, opportunities, and threats.
3. 3. Summary of project objectives: Lay out measurable goals that project managers will be striving to reach. These will mostly be non-functional requirements of the project, which means you will describe the parameters of a successful project in non-technical terms. Still, you can use metrics like sales growth and higher rates of customer satisfaction.
4. 4. Project scope: With your project goals established, you now must spell out the full scope of the project. Explain what kind of work will be done and also what kind of work will not be part of the project.
5. 5. Functional requirements: This is where you might insert an FRD if you have one, or at least make reference to the existence of an FRD as a separate document.
6. 6. Personnel: You will need to name the specific job descriptions of the members on the project team. In some cases, you will want to single out individuals by name. You must also spell out dependencies so that each team member understands who is relying on them for what.
7. 7. Assumptions: Lay out some of the events you foresee occurring as the project progresses. You can rely on a business analysis of past projects to make your predictions as accurate as possible.
8. 8. Timeline for deliverables: Establish a project schedule and a series of incremental deadlines leading up to project completion. Set goals that the project team can reasonably meet, which will keep progress steady and morale high.
9. 9. Cost-benefit analysis: Last but not least, your business requirements document should include a cost-benefit analysis of the entire business process. Be honest and candid about the costs the stakeholders will endure along the way. Also lay out a reasonable expectation of benefits and savings from a successfully completed project.

As you draft your business requirements document, keep the following tips in mind.

1. 1. Solicit team input before writing. Ask trusted team members to participate in a brainstorming session before you start drafting your BRD. Focus on the elicitation of ideas and personal opinions about the project. This will help you understand how your team members are approaching the project. It will also provide you with perspectives that may be different from your own.
2. 2. Back up your assertions with data. Lean on the business analysis of past projects to set expectations and make predictions about your upcoming endeavor. The more that all stakeholders understand that you are basing your projections on research and not gut instinct, the more buy-in you can inspire.
3. 3. Include helpful visuals. Graphs, flowcharts, process diagrams, and visual data tools all help keep readers engaged with a potentially lengthy BRD.
4. 4. Emphasize action whenever possible. Spell out how the project will be completed and how all key stakeholders will be contributing to a common goal. The best BRDs spend little time dwelling in abstraction; they get to specific actions as quickly as possible.
5. 5. Keep your end-user in mind. At the end of the day, a major business project should improve a company's relationship with its base of clients. As you lay out goals in the business requirements document, allow yourself space to ponder whether what you're doing will truly improve that overall business relationship with your end-users. If you feel, in the course of writing, that the project has strayed from that fundamental goal, do not hesitate to go back and make revisions to the project goals.

Get the MasterClass Annual Membership for exclusive access to video lessons taught by business luminaries, including Sara Blakely, Chris Voss, Robin Roberts, Bob Iger, Howard Schultz, Anna Wintour, and more.