SIMPLE BUSINESS REQUIREMENTS DOCUMENT

PROJECT NAME

SIMPLE BUSINESS REQUIREMENTS DOCUMENT TEMPLATE

COMPANY NAME

Street Address

City, State and Zip

webaddress.com

Version 0.0.0

00/00/0000

VERSION HISTORY
VERSION	APPROVED BY	REVISION DATE	DESCRIPTION OF CHANGE	AUTHOR

TABLE OF CONTENTS

1.	EXECUTIVE SUMMARY SNAPSHOT	3

2.	PROJECT DESCRIPTION	3

3.	PROJECT SCOPE	3

IN SCOPE	3

OUT OF SCOPE	3

4.	BUSINESS DRIVERS	3

BUSINESS DRIVER #1	4

BUSINESS DRIVER #2	4

BUSINESS DRIVER #3	4

5.	CURRENT PROCESS	4

6.	PROPOSED PROCESS	4

7.	FUNCTIONAL REQUIREMENTS	5

PRIORITY	5

REQUIREMENTS CATEGORIES (RC1)	5

8.	GLOSSARY	6

9.	REFERENCES	7

EXECUTIVE SUMMARY SNAPSHOT

Provide a brief executive summary (overview of your business requirements) here.

Your executive summary should be a “snapshot” of the purpose of your business requirements, including a brief description of any analysis, findings, project description, scope, business drivers, proposed process, current process, and functional requirements. Here are the questions you should answer when writing your business requirements executive summary:

What is the goal (purpose) of this business requirements document (BRD)?

Who is the audience for this business requirements document?

PROJECT DESCRIPTION

In this section, describe the project for which you are writing this business requirements document. Describe the project’s purpose, what the current process/solution is for the project, what the challenges are, and why you need to undertake the project.

PROJECT SCOPE

Provide a high-level description of the project’s scope, including a list of project-specific goals, tasks, deliverables, costs, deadlines -- everything that is “in” and “out” of scope for the project. This information provides team members with guidelines for the scope of the project, so they can plan and resource accordingly.

IN SCOPE

The following are “in scope” for the project:

In-scope item 1

In-scope item 2

In-scope item 3

In-scope item 4

Etc.

OUT OF SCOPE

The following are “out of scope” for the project:

Not-in-scope item 1

Not-in-scope item 2

Not-in-scope item 3

Not-in-scope item 4

Etc.

BUSINESS DRIVERS

Enter the reasons (i.e., business drivers) why your business is initiating the project. In short, Why are you undertaking the project? Examples might include the following:

Legal requirements

Cost savings with a more efficient practice

Updated import/export laws

Improved efficiency

Improved sales

Etc.

BUSINESS DRIVER #1

Provide a detailed explanation for business driver #1.

BUSINESS DRIVER #2

Provide a detailed explanation for business driver #2.

BUSINESS DRIVER #3

Provide a detailed explanation for business driver #3.

CURRENT PROCESS

Provide details of your current process for addressing the primary issue your project attempts to solve. Feel free to include diagrams, flowcharts, or other visuals to illustrate the current process.

PROPOSED PROCESS

Provide details of the proposed process for addressing the primary issue your project attempts to solve. Feel free to include diagrams, flowcharts, or other visuals to illustrate the proposed process. For this process, we recommend you use the same illustrative tool/style that you used for your current process (above).

FUNCTIONAL REQUIREMENTS

Detail the project’s functional requirements by enumerating the ways in which the current process addresses the issue and by describing the functional requirements necessary to the project’s success.

PRIORITY

Use the following priority table. It allows you to apply a ratings system to your requirements, so you have the visibility (into the value, status, and description of each requirement) that’s necessary for determining whether a particular requirement is essential to project success:
Value	Rating	Description
1	Critical	The requirement is critical to the project’s success. Without fulfilling this requirement, the project is not possible.
2	High	The requirement is high priority re the project’s success, but the project could still be implemented in a minimum viable product (MVP) scenario.
3	Medium	The requirement is important to the project’s success, as it provides value, but the project could still be implemented in an MVP scenario.
4	Low	The requirement is low priority (i.e., it would be nice to have), but the project’s success is not dependent upon it.
5	Future	The requirement is outside of the project’s scope and is included as a possible component of a prospective release and/or feature.

REQUIREMENTS CATEGORIES (RC1)

In this section, detail the project’s functional use; break down your project’s requirements into categories so that they’re easy to understand. You can duplicate this section for any successive project categories as needed. The following table includes a unique ID for each requirement, the details of each requirement, the priority of each requirement, and the name of the person who is driving or is responsible for the requirement.
ID	Requirement	Priority	Raised By
RC 1
RC 2
RC 3
RC 4

NON-FUNCTIONAL REQUIREMENTS

Detail all non-functional requirements (NFRs) of the project, including such things as features, system behavior, and project characteristics that relate to user experience.
ID	Requirement
NFR 1
NFR 2
NFR 3
NFR 4
NFR 5
NFR 6
NFR 7
NFR 8
NFR 9

GLOSSARY

For easy reference, enter any terms, abbreviations, and/or acronyms that you include in this document.
Term / Abbreviation	Explanation

REFERENCES

Provide links to all referenced resources (websites, documents, etc.) throughout this document.
Name	Location

DISCLAIMER Any articles, templates, or information provided by Smartsheet on the website are for reference only. While we strive to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the website or the information, articles, templates, or related graphics contained on the website. Any reliance you place on such information is therefore strictly at your own risk.