Sample BRD Document
Sample BRD Document
Business Requirements
Document
For
Version: 1
Release: 1
Table of Contents
CONTENTS ...................................................................................................................................................................... 2
1 INTRODUCTION .................................................................................................................................................... 5
1.1 DOCUMENT PURPOSE ..................................................................................................................................... 5
1.2 INTENDED AUDIENCE AND DOCUMENT OVERVIEW ........................................................................................ 5
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................................................................................ 5
1.4 DOCUMENT CONVENTIONS ............................................................................................................................. 5
1.5 REFERENCES AND ACKNOWLEDGMENTS ....................................................................................................... 6
2 REQUIREMENTS SCOPE ................................................................................................................................... 7
2.1 IN SCOPE ......................................................................................................................................................... 7
2.2 OUT OF SCOPE................................................................................................................................................ 7
3 PROJECT DESCRIPTION ................................................................................................................................... 8
3.1 PROJECT BACKGROUND ................................................................................................................................. 8
3.2 PURPOSE OF BUSINESS REQUIREMENTS....................................................................................................... 8
3.3 BUSINESS GOALS / OBJECTIVES TO BE ACHIEVED ....................................................................................... 8
3.4 BENEFITS / RATIONALE ................................................................................................................................... 8
3.5 STAKEHOLDERS .............................................................................................................................................. 8
3.6 PRODUCT PERSPECTIVE ................................................................................................................................. 9
3.7 PRODUCT FUNCTIONALITY .............................................................................................................................. 9
3.8 USERS AND CHARACTERISTICS ...................................................................................................................... 9
3.9 OPERATING ENVIRONMENT ............................................................................................................................ 9
3.10 DESIGN AND IMPLEMENTATION CONSTRAINTS............................................................................................... 9
3.11 USER DOCUMENTATION ................................................................................................................................ 10
3.12 ASSUMPTIONS ............................................................................................................................................... 10
3.13 DEPENDENCIES ............................................................................................................................................. 10
4 FUNCTIONAL REQUIREMENTS...................................................................................................................... 11
4.1 ACTOR PROFILES SPECIFICATION ................................................................................................................ 11
4.2 ESSENTIAL USE CASE DIAGRAM .................................................................................................................. 11
4.3 ESSENTIAL USE CASE SPECIFICATIONS ...................................................................................................... 12
4.4 FUNCTION HIERARCHY DIAGRAM ................................................................................................................. 13
4.5 FUNCTION DEFINITION REPORT.................................................................................................................... 13
4.6 BUSINESS RULES .......................................................................................................................................... 13
5 DATA REQUIREMENTS .................................................................................................................................... 14
5.1 DATA ARCHITECTURE ................................................................................................................................... 14
5.2 DATA VOLUMES ............................................................................................................................................. 14
5.3 DATA CONVERSION ....................................................................................................................................... 14
5.4 DATA RETENTION AND ARCHIVING ............................................................................................................... 14
5.5 FOI/PRIVACY IMPLICATIONS ......................................................................................................................... 14
5.6 DATA DEFINITION REPORTS ......................................................................................................................... 15
6 INTERFACE REQUIREMENTS ......................................................................................................................... 16
6.1 USER INTERFACES ........................................................................................................................................ 16
APPROVAL .................................................................................................................................................................... 24
Document Summary
Version Primary Author(s) Description of Version Date Completed
Version 1 Basu Mukherjee Information about the revision. This table 06/13/2012
does not need to be filled in whenever a
document is touched, only when the
version is being upgraded.
1 Introduction
The main intended audience for this document are the business owners of the proposed system.
This document should be readable by business owners of the proposed system. They must be
able to verify that their business requirements have been documented here completely, accurately
and unambiguously.
Data Architects, Application Architects and Technical Architects would also find the information in
this document useful when they need to design a solution that will address these business
requirements.
Since the requirements are documented here in Technology-independent manner, the end-users
of the system should be able to comprehend the requirements fairly easily from this document.
This document follows the IEEE formatting requirements. Several formatting conventions have
been followed throughout the entire document:
• Keywords and acronyms are bolded upon their first appearance in the document.
• Comments are shown in italics.
• All text contained in this document is 10pt Arial font.
• Section titles are 18pt Arial font.
• Subsection titles are 14pt Arial font.
• Any further subsection breakdown is 12pt Arial font.
• All sections and subsection are numbered using the X.X.X… format, where X represents
numbers.
• Introduced terms are in bolded Arial font.
• Any further repetition of these terms is in Arial font.
The naming conventions are the means of making the BRD more understandable and easier to
follow. They are also used to build a structure for the whole software system. The conventions are
used for variables, function names, packages, etc.
The following naming conventions have been used to define the different variables in this BRD
document:
• All constants are CAPITALIZED.
• All variables representing input are prefixed with i_.
• All variables representing output are prefixed with o_.
• All internal states are prefixed with s_.
• All system variables are prefixed with v_.
• All function names are using “Camel Case” naming convention with first letter lower case.
2 Requirements Scope
This section shows what business functionality is in scope and out of scope for Implementation. In
Use case approach, the out of scope Use cases are indicated in a separate boundary box.
Typically,1-4 paragraphs describing the scope of the product. And another 1-3 paragraphs on
those considered out of scope.
2.1 In Scope
3 Project Description
Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals. Also, describe the benefits associated with the product. Provide
System Architecture Diagram.
3.5 Stakeholders
Stakeholders are the individuals or groups who have a vested interest in this project and whose
interests need to be considered throughout the project. This section lists the Stakeholders of the
Application / Project for which these Business requirements are documented.
3.12 Assumptions
This section describes major assumptions that were made prior to or during the Business
Requirements gathering and documentation. List any assumed factors (as opposed to known
facts) that could affect the requirements stated in the BRD. These could include third-party or
commercial components to be used, issues around the development or operating environment, or
constraints. The project could be affected if these assumptions are incorrect, are not shared, or
change. Also identify any dependencies the project has on external factors, such as software
components that are intended to be reused from another project. Provide a short list of some
major assumptions that might significantly affect the design
3.13 Dependencies
This section describes the dependencies between the Application for which these Business
Requirements are written and the other existing applications/systems.
List any assumed factors (as opposed to known facts) that could affect the requirements stated in
the BRD. These could include third-party or commercial components to be used, issues around
the development or operating environment, or constraints. The project could be affected if these
assumptions are incorrect, are not shared, or change. Also identify any dependencies the project
has on external factors, such as software components that are intended to be reused from another
project.
4 Functional Requirements
Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform. Here, list in detail the
different product functions with specific explanations regarding every function. Break the functional
requirements to several functional areas and divide this section into subsections accordingly.
Provide a detailed list of all product operations related to these functional areas.
In Use case approach, the Actor Profile is documented in a separate template available on the
ADE web site.
cases are of primary importance early in a project’s requirements/analysis phase. Their purpose is
to document the business process that the Application must support without bias to technology
and implementation.
A use case defines a goal-oriented set of interactions between external actors and the system
under consideration. Since sometimes it is not possible to specify completely the behaviour of the
system by just State Diagrams, use-cases will be used to complete the requirement. Provide a use
case diagram which will encapsulate the entire system and all possible actors. Include a short
description of what every use-case is, who the actors in the diagram are.
If the number of use cases is less than 15, the Essential Use case specifications in narrative form
are included in this BRD in tabular format. Each use case is described in a separate table. If the
number of use cases is greater than 15, the Essential Use case specifications in narrative form are
attached as a separate document with this BRD.
Use Case Id : ##
Actors
Business Rules List the business rules of Section 4.6 that this use
case references. Mention only the Business rule
Id here. Provide hyperlinks to the business rules
of section 4.6.
Non-Functional Requirements
Pre-Conditions
Post-Conditions
5 Data Requirements
This section describes the Data requirements part of the Business Requirements.
This section is applicable only to Use case approach. This section depicts the Data Architecture in
the form of Domain Class Diagram. In the Use case approach, the conceptual data architecture
(structural aspects) for the Business Requirements is modeled using Domain Class Diagram. The
Domain Class Diagram is used to model the conceptual classes, its attributes (fields) and
operations (methods) and also the interrelationships (association, composition, aggregation and
generalization) between the classes. Domain model is a representation of real world conceptual
classes, not of software components.
This section describes the Data retention (time frames for online Data retention before archiving)
and also the archiving requirements.
• Non-sensitive information that would not reasonably be expected to cause injury (harm) if
released to the public;
This section is applicable only to Use case approach. This section describes Data Architecture /
definition (Domain Class model) in narrative text form.
Class Name
Class Description
6 Interface Requirements
7 Non-functional Requirements
This section describes the non-functional requirements part of the Business Requirements. A non-
functional requirement is typically a special requirement that is not easily or naturally specified in
the text of the use case’s or function’s event flow. Examples of non-functional requirements include
legal and regulatory requirements, application standards, and quality attributes of the system to be
built including usability, reliability, performance or supportability requirements.
Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.
Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc…) provide requirements related to the
different software quality attributes. Indicate the plan on how to achieve the attributes.
7.1.1 Authentication
This section describes the Authentication requirements part of the Business Requirements.
Authentication is the process of verifying the genuineness of claims that a person/group makes to
establish identity/eligibility for access to services. In order to ascertain the Authentication
requirements of the Application, it is required to analyse the type of transactions that different Use
cases/Business Functions trigger within the Application. The following criteria is used in
determining transaction types of each use case/function (in line with the Government Core Policy
Manual) :
This section describes the Authorization and Access Control requirements part of the Business
Requirements at a high-level. Authorization is the process of determining if the person/group, once
identified through the “Authentication process”, is permitted to have access to certain services. The
Authorization and Access Control requirements are best described through a matrix.
C Create
R Read
U Update
D Delete
8 Revision Logs
Data dictionary is used to track all the different variables, states and functional requirements that is
described in the document. Include the complete list of all constants, state variables (and their
possible states), inputs and outputs in a table. In the table, include the description of these items
as well as all related operations and requirements.
Approval
This document has been approved as the official Business Requirements Document for the Project
Name project.
Following approval of this document, changes will be governed by the project’s change
management process, including impact analysis, appropriate reviews and approvals, under the
general control of the Master Project Plan and according to Project Support Office policy.
Prepared by Signature Date
Author's Name
[Title]
[Organization]