Business Requirements Report Template

Project ID:
Project Name:
Phase of the Project:
WBS ID:
BRD for “Project/Phase/Module”

Document # with Version:

Prepared By:

______________________________ ___________________________

Name of BA or User/Dept. Date

Approved By:

______________________________ ___________________________

Name of the User/Dept. (Cust) Date

______________________________ ___________________________

Name of the PM Date

Table of Contents:
1. Version Control Insert Final Page #
2. RACI Chart Insert Final Page #
3. Executive Summary Insert Final Page #
4. Scope Insert Final Page #
5. Risk Analysis Insert Final Page #
6. Schedule Insert Final Page #
7. Business Use Cases Insert Final Page #
8. User Requirements ` Insert Final Page #
9. Non- Functional Requirements Insert Final Page #
10. Business Rules Insert Final Page #
11. Test Plan Insert Final Page #
1. Version Control
This table is used to track the changes made in the document—and at what stage the changes were
made to the requirements, who initiated the projects and the reason for the changes. In short, the
approach by which change control is implemented in the BRD is shown.

Revision History:

Version # Date Revised By Authorized By Areas Changes due

Changed to

2. RACI Chart for this document

The RACI chart will give an indication as to who is to be contacted whenever changes are made to this
document. The codes used in this chart describe the roles/responsibilities of the stakeholders (internal
and external) in the production of BRD.

Codes used in this chart:

 Authorize: Has the approving authority for any changes made
 Responsible: Responsible for creating the document
 Accountable: Accountable for the contents as well the process followed in creating
 Consult: Input is provided
 Inform: Any changes in this document are to be informed

RACI Chart:

Name Position ** R A C I
3. Executive Summary
The Executive Summary should provide the summary of this whole document. Summary should indicate
the following:
a) Why is the BRD document being prepared?
b) Issues as part of this document
c) Conclusions of the BRD document

When the project management team members who don’t have time to read through the complete
document read the executive summary, they should get the complete details; the executive summary will
provide insight to the other readers to access if the complete document is to be read or not.

The following are sub-sections of the executive summary:

 Overview: explains the nature of the project in a single paragraph.

 Background: This section will provide details as to why the project came into existence and the
pain areas that are supposed to be addressed due to this project. May be the business case from
the perspective of Technology, Government Standards, Industry Standards, Customer
Requirements, etc.
 Requirements: Brief summary of the requirements that will be provided.
 Proposed Strategy: This section will talk about the strategy by which the project requirements
can be achieved. Alternative approach and the alternate solution will be part of this sub-section
as well.
 Next Steps: The activities to be performed will be provided briefly in this sub-section. The
following table can be a good way of putting the actions in order…

Sl. No. Action Responsibility Compl. Date

4. Scope
What is to be included, what is to be excluded, what are the assumptions, what are the constraints, what
business processes are impacted by the project and what impact does it creates on the stakeholders
(Impact Analysis)? Basically, this section will provide the conversion of objectives to tangible deliveries.

 Inclusions: This sub-section provides the business/non-business areas that are covered as part
of project.
 Exclusions: This sub-section provides the business/non-business areas that are not covered as
part of project.
  Assumptions: The assumptions based on how the scope is defined will be briefed in this sub-
section.
 Constraints: This sub-section provides the predefined conditions/requirements
 Impact Analysis for Business/Stakeholders: The usage of the following table can help in
analyzing the impact of the project on the business…

Desired Existing Change / New Justification for Stakeholders / Priority

Functionality Functionality the Desired Business
Functionality impacted

5. Risk Analysis
Risks will be described in this section. Risk is some uncertainty that may have an impact on the project
either positively (opportunities) or negatively (threats). Risks are supposed to be analyzed as the project
progresses. As risk is associated with the future, include likelihood of the risk event happening along with
the impact the risk will create on the project—and of course the strategy for handling the risk. Strategies
could be:
● Avoid/Enhance
● Mitigate/Exploit
● Transfer/Share
● Accept

Types of Risk
 Technological Risks: New technology issues that could have an impact on the project is
provided in this sub-section.
 Skill Risks: Risk of not getting the staff with the required expertise will be elaborated in this sub-
section.
 Political Risks: Political forces that could have an impact on the project are identified in this sub-
section.
 Business Risks: This sub-section will describe the implications that would be created on the
business either due to implementation of the project or due to non-implementation of the project.
 Resource Risks: Risks that come up due to not getting the required resources or not getting the
resources on time is determined in this sub-section. Resources could be human, material,
equipment or facility.
 Requirements Risks: Incorrect capture of the requirements is detailed in this sub-section.
 Other Risks: Any other risks not covered under the relevant sub-sections are captured here.

Note: The sub-sections can be changed as appropriate depending on the project.

6. Schedule

Planned Area of Requirement Responsibility Status Revised Date (If

Date not done on the
planned date)

7. Business Use Cases

This section will be completed with the changes involved in the business processes. For every change in
the business process, a business use case will be required. There should be a justification for the revision
in the business process.

Business use-case diagrams: Involvement of stakeholders in every business process (existing and
revised) is described in business use-case diagrams.

Business use-case descriptions: Every business case is to be described with a text and a diagram.
Template for the use-case description is provided separately.

Use Cases will be described in the following ways:

1. Brief of the use case: brief description, important flows and outputs
2. Objectives: what will be achieved due to this use case
3. Actors
4. Precedence: events that trigger this use case and the prerequisites (conditions that are to be
satisfied for the use case to begin)
5. Post-conditions: seen from the angle of what happens when the use case ends successfully and
what happens when the use case ends in failure
6. Priority
7. Status
8. Special requirements
9. Assumptions
10. Prompts/Business Rules
11. External Interfaces
12. Required Documents

Actors: Describe the people/organization who participate in the business processes that interact with the
business as well as the system.

Internal Stakeholders: List out the internal stakeholders who act within the business or interact with the
system
External Stakeholders: List out the external stakeholders (customers/vendors) who interact with the
business

This table can be used to track the stakeholders/actors for each of the business process:

Name of Stakeholder Entity Internal/External Business Impact

System/Processes: The computer systems/processes that will potentially affect the project or be
affected by the project are listed below:

System/Process Entity Business Impact

Role Map: The roles played by the actors that interact with the processes/system.

8. User Requirements
This section describes the requirements from the perspective of the users.

System use-case diagrams: Description of which users use which portion of the process/system and the
interaction with the use cases.

System use-case descriptions: During the initial stages of the project, only brief descriptions will be
provided. As the project progresses, more information is received and the description becomes more
detailed.

9. Non-Functional Requirements
The non-functional requirements not forming part of use-case documentation will be elaborated in this
section:

1. Performance Requirements
2. Stress Requirements
3. Response Time Requirements
4. Usability Requirements
5. Security Requirements
6. Volume and Storage Requirements
 7. Configuration Requirements
8. Compatibility Requirements
9. Reliability Requirements
10. Backup/Recovery Requirements
11. Training Requirements

Note: The level to which non-functional requirements are to be documented will depend on the
type of the project.

10. Business Rules

The list of business rules that are to be in place is to be detailed.

11. Test Plan

Testing is to be standardized, and this requires a clear test plan to be developed. Every project is unique;
however, the following will be a guideline:
1. Functional requirements-based testing
2. Non-functional requirements-based testing
3. Integration testing
4. Acceptance criteria-based testing