BRD TEMPLATE

Business Requirements Document (BRD) Template

Project Name:

Month: 20YY

Version: 1.XX

Company Information
 BRD Template

1 Version

DATE VERSION CHANGES

ddmmyyyy 1.0 xyz

2 Sign Offs/Approvals

NAME DESIGNATION/DEPARTMENT DATE

PM

BA

Scrum Master

TL

3 Introduction
3.1 Project Summary
3.1.1 Objectives
[These should describe the overall goal in developing the product, high level descriptions
of what the product will do, how they are aligned to business objectives, and the
requirements for interaction with other systems.]

3.1.2 Background
[Provide a brief history of how the project came to be proposed and initiated, including
the business issues/problems identified, and expected benefit of implementing the
project/developing the product.]

3.1.2.1 Business Drivers

[List the business drivers that make development of this product important. These can be
financial, operational, market or environmental.]

SOURCE: TECHWHIRL 2 SIMPLIFIED: PRABHUDATT PARASAR

BRD Template

3.2 Project Scope

[Explain what tasks are included in the project and, more importantly, what tasks are not
part of it. This includes anything that goes beyond the budget, available resources, and
the timeline agreed upon by the project stakeholders. This helps prevent the project from
growing too big with extra features and functions that weren't initially planned.]

3.2.1 In Scope Functionality

● Make a list of names for widgets based on their category, like Supply Chain,
Production Lines, Internal web apps, and External web apps.
● Allow only specific people to create or delete widget names based on their roles.
● Enable searching for widget names by their name, the team responsible, the date
they were created, or the last time they were changed.
● Ensure that widget information stays consistent across different parts of our product
and operations.
● Keep a record of all changes made to the widgets, so we can see who did what.
● Create reports that show us information about new widgets, changes to existing
ones, and widgets that have been archived, organized by time and the teams
involved.

3.2.2 Out of Scope Functionality

● Build widgets for the product lines of our subsidiary company.
● Allow searching for these widgets based on who approved them or the reasons
behind their creation.
● Make sure we can store away or put aside these widget items when we no longer
need them.

3.3 System Perspective (RAID)

[Give a detailed explanation of things that might either stop us from successfully
completing the project or speed it up. Pay special attention to things like legal and
rule-following requirements, the restrictions and limits of our current technology or how
things are done, and the amount of money and resources we have available.]

3.3.1 Assumptions (A)

● Inventory of existing widgets completed in Sprint-1.
● Testing data comprises scrubbed production data as of December 31.

3.3.2 Dependencies/Constraints (D)

● Impending changes to privacy regulations may impact data dictionary design.
● Timelines for enterprise platform updates will impact execution of testing plans.

SOURCE: TECHWHIRL 3 SIMPLIFIED: PRABHUDATT PARASAR

BRD Template

3.3.3 Risks (R)

● Previously approved Sprint 1/2/3 development projects may limit availability of development and QA
resources, necessitating outsourcing or additional budget requisitions to meet the anticipated
timeline.

3.3.4 Issues (I)

4 Business Process Overview

[Explain how things currently operate in our IT systems and across different parts of the
business. Show how different systems and teams work together. Use visual diagrams to
make it even clearer.

For the new product, use case documentation and diagrams can be helpful to outline
how we want things to work in the future. This helps us compare what we have now (the
"As-Is" process) to what we want to achieve (the "To-Be" process).]

4.1 Current Business Process (As-Is)

At any point during or after deployment of web apps or web sites (internal or external) to support
business activities, development/support teams may create and deploy widgets.

4.2 Proposed Business Process (To-Be)

● Technical Lead searches repository.
● If a widget is not found, the user creates a new widget name record.
● WINS validates that all fields have been completed.
● WINS confirms that no similar widgets exist.
● User confirms record to be created.

SOURCE: TECHWHIRL 4 SIMPLIFIED: PRABHUDATT PARASAR

BRD Template

● User searches repository to locate existing widget description.

● WINS displays records.
● User selects Edit to open and modify the record.
● WINS validates all fields completed correctly.
● User confirms changes.
● WINS confirms changes and updates the Audit table.

SOURCE: TECHWHIRL 5 SIMPLIFIED: PRABHUDATT PARASAR

5 Business Requirements
[List the particular business needs we've collected from the people involved in the project. Organize them by importance and
what part of the system they relate to. To make these requirements as clear as possible, add links to documents that provide
more details, like use cases and other important references.

For better tracking, it might be helpful to create a traceability matrix that shows how each requirement connects to the project,
both in terms of how the system should function (functional requirements) and any additional conditions (non-functional
requirements). This way, we can keep tabs on everything throughout the project..]

The requirements in this document are prioritized as follows:

Value Rating Description
1 Critical This requirement is critical to the success of the project. The project will not be possible without this
requirement.
2 High This requirement is high priority, but the project can be implemented at a bare minimum without this
requirement.
3 Medium This requirement is somewhat important, as it provides some value but the project can proceed without it.
4 Low This is a low priority requirement, or a “nice to have” feature, if time and cost allow it.
5 Future This requirement is out of scope for this project, and has been included here for a possible future release.

5.1 Functional Requirements (FR)

Use Case Impacted
Req# Priority Description Rationale
Reference Stakeholders
General / Base Functionality
Single repository simplifies Development
A new Master Widget repository shall be
management of widget teams
FR-G-001 1 created to house the name records and
development across 30+ Infrastructure
links to the widget objects.
global development teams engineers

SOURCE: TECHWHIRL 6 SIMPLIFIED: PRABHUDATT PARASAR

 Use Case Impacted
Req# Priority Description Rationale
Reference Stakeholders
A widget shall be defined in the repository ID+Name eliminates
FR-G-002 1 via a unique identifier and name duplicate widget name
combination. records

Security Requirements
Widget creation in the repository shall be
FR-S-001 1 limited to users with Team Lead or
System Administrator,

5.2 Non-Functional Requirements (NFR)

[Include technical and operational requirements that are not specific to a function. This typically includes requirements such
as processing time, concurrent users, availability, etc.]
ID Requirement
NFR-001 The WINS repository shall accommodate up to 1000 users concurrently.
NFR-002 The WINS repository shall be designated at Level 2 for availability and SLA purposes.

SOURCE: TECHWHIRL 7 SIMPLIFIED: PRABHUDATT PARASAR

6 Appendices

6.1 Acronyms
[If needed, create a list of acronyms used throughout the BRD document to aid in
comprehension.]

6.2 Glossary
[If needed, identify and define any terms that may be unfamiliar to readers, including
terms that are unique to the organization, the technology to be employed, or the
standards in use.]

6.3 References
[Provide a list of documents or web pages, including links, which are referenced in the
BRD.]

SOURCE: TECHWHIRL 8 SIMPLIFIED: PRABHUDATT PARASAR