BRD Sample

CONTENT
Business Requirements
Document Template
Prepared for:
Client Name
[Client.Company]
Prepared by:
Sender Name
[Sender.Company]
Table of contents
1. Executive summary
2. Business objectives
3. Background
4. Scope
5. Features
6. Functional requirements
7. Personnel requirements
8. Reporting and quality assurance
9. Delivery schedule
10.Other requirements
11.Limitations
12.Risks
13.Appendix A – Glossary of Terms

What a company needs to include in a BRD will vary depending on the services it provides. For
example, a BRD for changes to a banking system might require you to outline functionality for
making withdrawals, depositing money, or transferring funds from one account to another. This
template gives you a place to start. Feel free to modify it as needed.
1. Executive Summary
What is a business requirement document? A business requirement document (BRD) is one that
details the scope of work that your company will provide to a client on a specific project. It lists the
problems the client is bringing your company in to address as well as the specific outcomes the
client expects. A BRD is typically the product of multiple brainstorming sessions. It describes the
project life cycle, directs the project's flow, and keeps everyone on the same page.
Attached you'll find the business requirements document that covers the work required by [client
name]. Sections contained within the document include Business Objectives, Background, Scope,
Features, Functional Requirements, Personnel Requirements, Reporting and Quality Assurance,
Delivery Schedule, Other Requirements, Assumptions, Limitations, Risks.
One of the issues faced by [client name] is [client issue]. The goal of [project name] is to allow [client
name] to [client objective]. By bringing on [Company] to assist with the project, [client name] gets the
benefit of [Company]'s years of experience in services to [client's industry].
[Company] appreciates the faith that [client name] has placed in us. Our company's mission is
to [Company mission]. We understand the intricacies of services to the [client's
industry]. [Company] will work hard to ensure that [client name] receives everything necessary to
accomplish their business goals upon the successful delivery of [project name].
An executive summary, which indicates the purpose and contents of the rest of the document,
should be no more than three paragraphs long. It is usually best to draft this section last. Try to
avoid being overly formal as you showcase the character of your company and the reason why
you're the client's ideal choice.
2. Business objectives
Here, you go into detail about what you hope to accomplish with the project. Some of the topics
you might wish to touch upon include an overview of the current process, the business drivers
prompting the changes, and any users or business areas affected by the project.
2.1 Project Solution

The new [project solution] will help [client name] accomplish its goal of [business
deliverable]. [Company] will oversee quality control at each step of the process to avoid issues during
deployment.
You should also talk about the project's goals, what the client hopes to accomplish, and all
stakeholders involved, such as the project manager. And it's a good idea to mention how the
project impacts the client's overall business strategy
2.2 Value
Thanks to [project name], [client name] can move further toward their goal of [client objective]. By
doing so, [client name] puts itself in a position to [overall business strategy].
2.3 Next Steps

The success of [project name] will impact [client name] positively by [positive business impacts]. In
addition, there will be established metrics to gauge the impacts of the [project solution] release.
By implementing [project name], [client name] can put itself into a position to accomplish the
following business goals:
1. 2.3.1 [client name] should have the ability to [business objective 1].
You want to detail specific results that should occur upon the full implementation of the project.
For example, if you're rolling out a new communication system for employees, an objective might
be to have the new software installed on everyone's desktop by a specific date. It's a good idea to
hold a brainstorming session with colleagues to ensure you're covering every potential business
objective.
The stakeholders involved in the project include:
 [Stakeholder 1][stakeholder title][stakeholder department]

[Client name] decided to pursue [project name] because [description of business drivers].
Business objectives should reflect the commonly used SMART formula — specific, measurable,
actionable, realistic, and time-bound. If you are not familiar with this formula, an easy comparison
would be the generic "I will have healthier habits this year" with the SMART version: "I will lose 15
pounds in the next three months, I will do this by cutting out desserts and walking two miles every
day during that time period."
2.4 Functionality
The new functionality provided by [project name] will allow [client name] to accomplish their goal
of [business goal]. Changes will include modifications to [systems modified] and [business
processes modified].
[Additional functionality of new process]
2.5 Process diagrams

The following process diagrams outline the original business processes and the contrasting changes
put in place because of [project name]:
[Original process diagram]
[Current process diagram]
3. Background
Currently, [client name] handles [business process] by [description of current process]. Because of
changing business needs caused by [reason for change], the business must now [new process]. As a
result, [client name] is initiating [project name] to allow [company] to [new business process].
[Company] is the ideal partner to assist [client name] pursue their desired business strategy
because [Company services/experience].
[Additional background description of issues]
[Additional background text]
Provide information about the business and its current business practices, and outline the
business need that underlies this document. Use this section to indicate your understanding of
why the client felt that change was necessary. It's also a good idea to highlight the reasons why
your business is the right fit for the client.
4. Scope
The Scope section creates specifications around what work is included or not included as part of
the discussed project. Err on the side of more detail rather than less, because mutual
understanding between the parties as to scope can be a primary source of dispute and cost
overruns. Specify that any services or project items not explicitly outlined within this section of the
BRD are deemed to be excluded from the project.
The scope of the [project] initiated by [client name] should cover the following changes to business
processes:
Use the Scope section to define the boundaries of the project. If you're making changes to a
business application, for example, define which specific screens will receive updates or describe
any new functionality that will be provided to users as a result.
4.1 Project objective

[CLIENT COMPANY NAME]
[PROJECT DESCRIPTION (IF ANY)]
Prepared by:
[PREPARER]
[PREPARER COMPANY NAME]
MM / DD / YYYY
The primary objective of [project] is to [project objective].
[Additional description of overall project objective]
4.2 Project deliverables

The deliverables considered within the scope for [project] should include the following:
1. 4.2.1[Company] must provide [client name] with the ability to [deliverable 1].

4.3 Project milestones

The following milestones must be hit by [Company] on the dates indicated below:
1. 4.3.1[milestone 1][milestone date]
4.4 High-level requirements

[Company] must adhere to each of [client name]’s requirements as listed below:
1. 4.4.1[Company] must [requirements description 1] to meet the client’s need for [business

need 1].

need 2].

need 3].

need 4].
need 5].

need 6].

need 7].

need 8].
Outlining your project scope enables you to avoid "scope creep," where the expected deliverables
tend to expand as you progress through the project.
4.5 Assumptions
When you identify assumptions that you or the client have made about the business operations
and other details, you have an easier time identifying wrong assumptions before they throw an
entire process off track. It's always a good idea to go over the assumption section during a
brainstorming session with all stakeholders. That way, someone more familiar with a specific
business process may be able to spot an error before the project gets underway.
[Company] should keep the following assumptions in mind when performing the work required
by [client name]:
1. 4.5.1[Company] should assume that [client name][assumptions description 1].
4.6 Acceptance criteria

[Company] must adhere to the following acceptance criteria that define success for [project], as
outlined by [client name]:
1. 4.6.1 The user must be able to [acceptance criteria description].

2. 4.6.2 The system must allow the user to [acceptance criteria description].
3. 4.6.3 The user must be required to [acceptance criteria description].
4. 4.6.4 The system must validate [acceptance criteria description] before proceeding

with [system process].
5. 4.6.5 The system must prompt the user to [acceptance criteria description] before allowing
the user to [user process].
4.7 Constraints
[Company] must take the following constraints into consideration when mapping out the technical
details of [project]:
1. 4.7.1 The [business system] currently does not allow for [constraints description].
2. 4.7.2 Users of [business system] are currently limited to functions that include [constraints

description].
3. 4.7.3 There is currently a data storage limit of [data storage limit] that limits the system
to [constraints description].
4. 4.7.4 Reporting and other system insights are currently limited to [constraints

description] because of [additional constraint description].
5. 4.7.5 Users can only process up to [constraints description] within [business system].
5. Features
[Company] will introduce the following features upon completion of [project name]:
This section would include descriptive wording that defines the client's business needs as you
work on developing a timeline for project tasks. For example, a software developer client reviewing
this section might expect to see information that details how their customers would utilize the
new feature to perform routine business tasks, compile company data, and run a report.
5.1[Company] must add [feature name] to [business system].
The feature should give the user the ability to [feature description].

6. Functional requirements
The Functional requirements section is where to put more details about the structure behind what
the user of the end product or service sees. You may add appropriate subsections, data flow
diagrams and flowcharts, or similar types of information. Be detailed but not too technical. The
audience for this document is business decision-makers.
6.1 Context
[Company] must provide [client name] with the following system updates and expand the
functionality available to users as outlined in the context diagrams below:
 Exhibit 1: context diagram
 Exhibit 2: context diagram
Your function requirements describe the new functions or features made available through the
completion of the project. Use this section to describe the behavior of your system when a
specific condition occurs.
6.2 Methodology
[Company] will adhere to an [Agile/Waterfall/Scrum/Kanban] framework when planning out the
different phases of [project]. That will afford the development team and all project stakeholders the
best chance of identifying potential risks to ensure they don’t disrupt the delivery of [project].
Use this section to help nontechnical users understand the approach taken to complete the
project.
6.2 User requirements

6.2.1 System use cases
The following diagrams provide a visualization of what [client name] requires from the system:
1. 6.2.1.1[system use case diagram 1]
6.2.2 System use case descriptions
The following system use cases provide a text description of what [client name] requires from the
system through changes put in place by [project name]:
1. 6.2.2.1 The system must [system use case description 1].
Make sure you clearly describe the needs of any users affected by your project. In addition, you
should account for any impacts to systems relied upon by the users for their job roles. You can
use text for the descriptions or add process flows that describe the impacts.
6.3 Data flow diagrams

The following data flow diagrams outline the flow of information through different systems affected
by the changes brought about as a result of [project name]:
1. 6.3.1[data flow diagram 1]
At this point, you should break down the high-level flows introduced in the business objectives
section down to a more granular level. You can still use flowcharts if a visualization makes things
more straightforward.
6.4 Logical data model

The following logical data model showcases the information captured and processed based on the
system changes implemented by [project name]:
In this section, you should lay out the logical data models and any business data requirements for
the project. You should not use this section to lay out any physical database characteristics.
7. Personnel requirements
[Client name] will require the following personnel in place to ensure the timely completion of [project
name] by [Company]:
For some business projects, the identity of personnel is just as critical as any other requirements.
Include enough detail to address those needs in the context of the rest of the project and any
potential impacts on the project budget.
1. 7.1[personnel job title][personnel job skills][personnel hours][personnel cost per hour]

Depending on your industry, it may be a good idea to spell out the hours required for personnel
and the cost of each resource. You can choose to include additional levels of detail as required for
your business needs.
8. Reporting and quality assurance

[Client name] requires that [Company] enables the reporting of the following metrics to measure the
successful delivery of each project milestone:
8.1[QA Metric 1]
[Company] must provide a metric that measures the success of [project deliverable] by [reporting

metric description].
8.2[QA Metric 2]

8.3[QA Metric 3]

8.4[QA Metric 4]

8.5[QA Metric 5]

The Reporting and Quality Assurance section will outline how progress is being measured and
assessed along the way. Make sure you clearly define the methods employed to oversee progress
on the project and show progress to stakeholders.
9. Delivery schedule
[Company] must adhere to [client name]’s delivery schedule for each project phase.
Include both final deadlines and detail around milestones.

9.1[Project phase 1]
[Company] must deliver [project phase] of [project name] by [project phase delivery date].

10. Other requirement

[Company] must adhere to the following requirements per the needs of [client name]:
1. 10.1 The company must provide [client name] with the ability to [additional requirement 1].
Using an IT example again, think about such things as interface requirements between old and
new systems, data conversion requirements where appropriate, hardware and software
requirements when instrumental to the rest of the project, and operational requirements if not
already discussed above. Details such as these may not fit into other requirement buckets but still
need to be documented within your BRD if they impact business processes.
11. Limitations
The following limitations may impact [Company]’s ability to comply with specific project deliverables
by [client name]'s outlined milestone dates:
Identify any limitations in terms of time, personnel, technical details, or other things that affect the
scope, time, and cost of the project under discussion. Be specific about any restrictions around
the project. Capture any potential obstacles that could arise in the future during project execution.
Having that knowledge upfront reduces the potential of the project getting thrown off track by any
unanticipated challenges.
1. 11.1 The [business system] prevents [Company] from [limitation 1].
2. 11.2 Current company policy prohibits users from [limitation 2].
3. 11.3 A lack of reporting resources limits the ability of upper management from [limitation 3].
4. 11.4 A need to comply with [regulatory policy] prohibits users from [limitation 4].
5. 11.5 Data that comes from [limitation 5] must be kept in a separate business system. The
company currently lacks the data storage resources to support that business requirement.
12. Risks
Every project has inherent risks that may cause delay or even failure of a project. You must identify
these risks to show you know what they are and identify ways to mitigate those risks. Excluding
this section from your BRD could cause you a lot of problems down the line. Take the opportunity
to meet with business stakeholders and brainstorm any risks to the project.
12.1 Technology Risks

12.1.1 If [business system] does not [business process], then the users will not be able to [business
function].
12.1.2 If the data team fails to perform information backups every night, then the system will not have
the ability to [system process].
12.1.3 If the change management team fails to update the system on the scheduled date, then the
user will not be able to [business process].
12.1.4 If the system does not properly save user updates, then that will affect the integrity of
information stored in [database/datastore].
Describe any risks that might arise with the technology used to build or support the project.
12.2 Skills Risks

The following risks might arise due to not having personnel in place to perform the necessary system
or business functions:
1. 12.2.1 If the developer does not possess knowledge of [technology/programming language],

they will not be capable of making the necessary updates to [business process/application].
2. 12.2.2 If the user does not understand how to [business capability], then they will not have the
ability to take full advantage of the changes put in place by [system change].
Describe any risks that might arise regarding the skills necessary to deliver the project.
12.3 Environmental/political risks

The following environment or political risks might impact [Company]’s ability to provide the changes
required by [client name] for [project name]:
1. 12.3.1 If [client name] is unable to obtain buy-in from [stakeholder], then that impacts the
ability to deliver on [project milestone].
2. 12.3.2 If [local/state/federal law title] becomes implemented, [Company] will be unable to

proceed with [project milestone].
3. 12.3.3 If [client name] fails to win approval to proceed with [business change], then that

impacts [Company]’s ability to provide client with [project milestone].
Describe any risks that might arise because of internal business environment forces or those
caused by changes at the local, state, or federal level.
12.4 Business risks

The following business risks might hinder the ability of [Company] to deliver on the goals of [project
name] for [client name]:
1. 12.4.1 If [client name] fails to provide [Company] with all information pertaining to [business

process], then that may impact [Company]’s ability to deliver on [project milestone].
2. 12.4.2 If [client name] fails to provide [Company] with all information pertaining to [user

3. 12.4.3 If [client name] fails to provide [Company] with all information pertaining to [system
Describe any risks to the company that could occur if the project ends up getting canceled or
delayed.
12.5 Requirements risks

12.5.1 If [Company] and [client name] fail to account for all systems impacted by the changes caused
by [project name], then that may impact the ability to deliver on some or all project milestones.
12.5.2 If [Company] and [client name] fail to account for all constraints around various aspects

of [project name], then that may impact the ability to deliver on some or all project milestones.
12.5.3 If [Company] and [client name] fail to account for all user needs when outlining the scope
of [project name], then that may impact the ability to achieve [client name] business objectives.
Describe any risks that could arise because of issues with the requirements. For example, what
could happen to the project timeline if you discovered that a section of the requirements was
incomplete?
12.6 Additional risks

The following additional risks must be accounted for by [Company] when considering the scope of
the project:
1. 12.6.1 The potential of [additional risk] occurring during the project development phase could
impact [Company]’s ability to deliver on [company milestone].
2. 12.6.2 The potential of [additional risk] occurring during the project testing phase could
3. 12.6.3 The potential of [additional risk] occurring during the project release phase could
Continue to describe any other risks that do not fall into the risk buckets above.
Appendix A – Glossary of Terms

[Glossary term] — [glossary definition]

Add a glossary if there are a lot of technical terms that need defining to add clarity to the
document. Remember, you'll have technical and nontechnical personnel reviewing it. It's always
helpful to have a handy reference within your BRD that helps everyone understand the terminology
and business vocabulary used throughout.
BLOCKS
 TEXT
 IMAGE
 VIDEO
 TABLE
 PRICING TABLE
 PAGE BREAK
FIELDS
 TEXT FIELD
 CHECKBOX
 DROPDOWN
 DATE
Use this template
No credit card required



Introducing: Community Gallery

Looking for inspiration for your next document? Our Community Gallery is a hall of fame full of beautiful
work by our top creators to help you get inspired and find ideas.
Get Inspired
Related templates
Business Sale Agreement Template
This business sale agreement template can be used as a binding document to govern the sale of a business to a
new owner.
Operating Agreement Template
An Operating Agreement is an agreement amongst an LLC's members to govern it's business and financial and
managerial rights.
Exclusivity Agreement Template
This exclusivity agreement template can be used by a vendor to secure exclusive rights to provide goods or
services to another organization.
Founders’ Agreement Template
Your startup is just starting up. You and your partner have the idea. Now you need the Founders' Agreement.
Disclaimer
Parties other than PandaDoc may provide products, services, recommendations, or views on PandaDoc’s site (“Third Party
Materials”). PandaDoc is not responsible for examining or evaluating such Third Party Materials, and does not provide any
warranties relating to the Third Party Materials. Links to such Third Party Materials are for your convenience and does not
constitute an endorsement of such Third Party Materials.

BRD Sample

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRD Sample

Uploaded by

Copyright:

Available Formats

CONTENT

8. Reporting and quality assurance

13.Appendix A – Glossary of Terms

2.1 Project Solution

2.3 Next Steps

1. 2.3.1 [client name] should have the ability to [business objective 1].

2. 2.3.2 [client name] should have the ability to [business objective 2].

3. 2.3.3 [client name] should have the ability to [business objective 3].

4. 2.3.4 [client name] should have the ability to [business objective 4].

5. 2.3.5 [client name] should have the ability to [business objective 5].

The stakeholders involved in the project include:

 [Stakeholder 1][stakeholder title][stakeholder department]

 [Stakeholder 2][stakeholder title][stakeholder department]

 [Stakeholder 3][stakeholder title][stakeholder department]

 [Stakeholder 4][stakeholder title][stakeholder department]

[Client name] decided to pursue [project name] because [description of business drivers].

[Additional functionality of new process]

2.5 Process diagrams

[Original process diagram]

[Current process diagram]

[Additional background description of issues]

[Additional background text]

4.1 Project objective

[PROJECT DESCRIPTION (IF ANY)]

[PREPARER COMPANY NAME]

The primary objective of [project] is to [project objective].

[Additional description of overall project objective]

4.2 Project deliverables

1. 4.2.1[Company] must provide [client name] with the ability to [deliverable 1].

3. 4.2.3[Company] must provide [client name] with the ability to [deliverable 3].

4. 4.2.4[Company] must provide [client name] with the ability to [deliverable 4].

5. 4.2.5[Company] must provide [client name] with the ability to [deliverable 5].

6. 4.2.6[Company] must provide [client name] with the ability to [deliverable 6].

7. 4.2.7[Company] must provide [client name] with the ability to [deliverable 7].

4.3 Project milestones

1. 4.3.1[milestone 1][milestone date]

2. 4.3.2[milestone 2][milestone date]

3. 4.3.3[milestone 3][milestone date]

4. 4.3.4[milestone 4][milestone date]

5. 4.3.5[milestone 5][milestone date]

4.4 High-level requirements

1. 4.4.1[Company] must [requirements description 1] to meet the client’s need for [business

2. 4.4.2[Company] must [requirements description 2] to meet the client’s need for [business

3. 4.4.3[Company] must [requirements description 3] to meet the client’s need for [business

4. 4.4.4[Company] must [requirements description 4] to meet the client’s need for [business

6. 4.4.6[Company] must [requirements description 6] to meet the client’s need for [business

7. 4.4.7[Company] must [requirements description 7] to meet the client’s need for [business

8. 4.4.8[Company] must [requirements description 8] to meet the client’s need for [business

1. 4.5.1[Company] should assume that [client name][assumptions description 1].

2. 4.5.2[Company] should assume that [client name][assumptions description 2].

3. 4.5.3[Company] should assume that [client name][assumptions description 3].

4. 4.5.4[Company] should assume that [client name][assumptions description 4].

5. 4.5.5[Company] should assume that [client name][assumptions description 5].

4.6 Acceptance criteria

1. 4.6.1 The user must be able to [acceptance criteria description].

3. 4.6.3 The user must be required to [acceptance criteria description].

4. 4.6.4 The system must validate [acceptance criteria description] before proceeding

1. 4.7.1 The [business system] currently does not allow for [constraints description].

2. 4.7.2 Users of [business system] are currently limited to functions that include [constraints

4. 4.7.4 Reporting and other system insights are currently limited to [constraints

5. 4.7.5 Users can only process up to [constraints description] within [business system].

5.1[Company] must add [feature name] to [business system].

5.2[Company] must add [feature name] to [business system].