SANSANK ACADEMY

Project Name : Website Implementation

Business Requirements Document (BRD)

Prepared by: Ayesha Naaz

Prepared for: SanSank Acedemy
Date Submitted: June 24, 2021

Client Acceptor: Ankita Mehta

Project Manager: ANZ

Security Classification: Low

Version: 0.1

Last Updated: June 23,2021

Creation Date: June 23, 2021
Business Requirements Document Project Name

Table of Contents

TABLE OF CONTENTS....................................................................................................2
1. INTRODUCTION.....................................................................................................4
1.1. DOCUMENT PURPOSE...........................................................................................4
1.2. INTENDED AUDIENCE...........................................................................................4
1.3. PROJECT BACKGROUND.......................................................................................5
1.4. PURPOSE OF THE BUSINESS REQUIREMENTS........................................................5
1.5. BUSINESS GOALS/OBJECTIVES TO BE ACHIEVED.................................................6
1.6. BENEFITS/RATIONALE..........................................................................................6
1.7. STAKEHOLDERS....................................................................................................6
1.8. DEPENDENCIES ON EXISTING SYSTEMS................................................................6
1.9. REFERENCES.........................................................................................................6
1.10. ASSUMPTIONS.......................................................................................................6
2. REQUIREMENTS SCOPE......................................................................................7
2.1. IN SCOPE..............................................................................................................8
2.2. OUT OF SCOPE......................................................................................................8
3. FUNCTIONAL REQUIREMENTS.........................................................................8
3.1. ACTOR PROFILES SPECIFICATION.........................................................................8
3.2. ESSENTIAL USE CASE DIAGRAM..........................................................................9
3.3. ESSENTIAL USE CASE SPECIFICATIONS................................................................9
3.4. FUNCTION HIERARCHY DIAGRAM......................................................................11
3.5. FUNCTION DEFINITION REPORT.........................................................................11
3.6. BUSINESS RULES................................................................................................12
4. DATA REQUIREMENTS......................................................................................13
4.1. DATA ARCHITECTURE........................................................................................13
4.1.1. Domain Class Diagram.................................................................................13
4.1.2. Entity Relationship Diagram.........................................................................14
4.2. DATA VOLUMES.................................................................................................14
4.3. DATA CONVERSION............................................................................................14
4.4. DATA RETENTION AND ARCHIVING...................................................................14
4.5. FOI/PRIVACY IMPLICATIONS.............................................................................14
4.6. DATA DEFINITION REPORTS...............................................................................15
4.6.1. Domain Class Definition Report...................................................................15
4.6.2. Entity Definition Report................................................................................16
5. NON-FUNCTIONAL REQUIREMENTS............................................................17
5.1. SECURITY REQUIREMENTS.................................................................................17
5.1.1. Authentication...............................................................................................17
5.1.2. Authorization and Access Controls...............................................................18
5.1.3. Information Security Classification and labelling........................................19

Last revised:26/04/2013 Page 2 of 26

Security Classification: Low

Business Requirements Document Project Name

5.2. AVAILABILITY REQUIREMENTS..........................................................................20

5.3. USABILITY REQUIREMENTS................................................................................21
5.4. SYSTEM HELP REQUIREMENTS..........................................................................21
5.5. PERFORMANCE REQUIREMENTS.........................................................................22
5.6. SCALABILITY REQUIREMENTS............................................................................22
5.6.1. User Scalability.............................................................................................22
5.6.2. Application Scalability..................................................................................22
6. INTERFACE REQUIREMENTS..........................................................................23
6.1. USER INTERFACE REQUIREMENTS.....................................................................23
6.2. SYSTEM INTERFACE REQUIREMENTS.................................................................23
7. BUSINESS GLOSSARY.........................................................................................23
APMS UPDATE...............................................................................................................24
REVISION LOG..............................................................................................................24
APPENDICES..................................................................................................................24
Approval............................................................................................................................25

Last revised:26/04/2013 Page 3 of 26

Security Classification: Low

Business Requirements Document Project Name

1. Introduction

1.1. Document Purpose

The purpose of this document is to describe business requirements for SanSank

Academy for their website completely, accurately and unambiguously in
Technology-independent manner. All attempts have been made in using mostly
business terminology and business language while describing the requirements
in this document. Very minimal and commonly understood Technical terminology
is used.

1.2. Intended Audience

The main intended audience for this document is 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.

Developer, Maneger, Tester and Technical would also find the information in this
document useful when they need to design a solution that will address these
business requirements.

Document filling instructions

 This document template contains hidden text. To enable hidden text, under
the “Tools | Options | View” tab, make sure that "Hidden Text" is checked. To
print the template with hidden text displayed, under the “Tools | Options |
Print” tab, make sure that "Hidden Text" is checked.

 The text in black colour is meant to be part of the final filled in document.
Please do not delete them.

 The text in red colour is instructions and examples on what to fill in the
various sections of this document. Please fill in the sections as per
instructions and then delete the red coloured text (instructions and
examples).

Last revised:26/04/2013 Page 4 of 26

Security Classification: Low

Business Requirements Document Project Name

 Please do not leave any section blank. If a section is not applicable, then type
in “Not Applicable” in that section.

 Please ensure not to describe System Design issues in this document.

 Currently two approaches to modeling the Business Requirements are

supported by Ministry’s ADE standards :

 UML Use case modeling using any tool that supports the UML notation
and standards as described in the ADE standards web site ;

 Entity Relationship Diagram (ERD) and Function Hierarchy Diagram

(FHD) modeling using Oracle Designer tool.

 This document template supports both Use case and Designer modeling
approaches. It is highly recommended that only one of the two modeling
approaches is adopted for describing the Business Requirements in this
document and not a hybrid approach. Data models may be presented either
in ERD notation or in UML class notation, regardless of which modeling
approach was used. All Modeling should conform to Ministry’s modeling
standards.

 If Use case approach is followed, then please delete Designer sections

and vice versa. The section numbers in the document are automatically
re-sequenced when certain sections are deleted.

 After finishing the document, please re-generate the complete Table of

Contents to reflect the correct page numbering. (Select the Table of contents;
right-click; select “update fields” and select “update entire table” commands.)

1.3. Project Background

This section describes if these Business Requirements are as a result of any

previous meetings, correspondence, legislation etc.

Last revised:26/04/2013 Page 5 of 26

Security Classification: Low

Business Requirements Document Project Name

1.4. Purpose of the Business Requirements

This section describes the purpose of the Business Requirements.

Business requirements for major enhancements to an existing

application.

Business requirements for new application development.

Business requirements for replacement application development.

Business requirements for a request for proposals (RFP).

1.5. Business Goals/Objectives to be achieved

This section describes the major goals/objectives to be achieved with the

implementation of the Business Requirements.

1.6. Benefits/Rationale

This section describes the major benefits to be achieved with the implementation
of the Business Requirements.

1.7. 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.

1.8. Dependencies on existing systems

This section describes the dependencies between the Application for which these
Business Requirements are written and the other existing applications/systems.
Last revised:26/04/2013 Page 6 of 26

Security Classification: Low

Business Requirements Document Project Name

1.9. References

This section lists the references to previous documentation, correspondence etc ,

if any, that are related to these Business Requirements.

1.10. Assumptions

This section describes major assumptions that were made prior to or during the
Business Requirements gathering and documentation.

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. In Oracle Designer approach the out of scope
Functions are shown in grey coloured boxes.

Last revised:26/04/2013 Page 7 of 26

Security Classification: Low

Business Requirements Document Project Name

2.1. In Scope

2.2. Out of Scope

3. Functional Requirements

This section describes the Functional requirements part of the Business

Requirements. In Use case approach, the Functional Requirements comprises of
Actor Profile Specification, Essential Use case diagram and Essential Use case
specification in narrative text form. In Oracle Designer approach the Functional
Requirements comprises of Business Unit Definition Report, Function Hierarchy
Diagram and Function Definition Report.

3.1. Actor Profiles Specification

This section describes all the Actors and their profiles within the context of the
Business Requirements being documented. An Actor is a person, organization or
Last revised:26/04/2013 Page 8 of 26

Security Classification: Low

Business Requirements Document Project Name

an external system/sub-system/program that has interactions with the

Application. Actors, by definition, are external to the system with which they are
having interactions. Actors have goals that are achieved by use cases. Typically,
Actors have behaviour and are represented by the roles they play in the use
cases. An Actor stimulates the system by providing input and/or receiving
something of measurable value from the system.

In Use case approach, the Actor Profile is documented in a separate template

available on the ADE web site.

In Oracle Designer approach the Actor Profile information is documented under

“Business Units” folder of Oracle Designer and the “Business Units Definition”
report from Oracle Designer is generated and attached with these Business
Requirements.

Last revised:26/04/2013 Page 9 of 26

Security Classification: Low

Business Requirements Document Project Name

Actor Name Actor Type Access Type needed Comments

Stakeholder Create Print

Primary Actor Read Export
Supporting Actor Update Others
Delete
Stakeholder Create Print
Primary Actor Read Export
Supporting Actor Update Others
Delete
Stakeholder Create Print
Primary Actor Read Export
Supporting Actor Update Others
Delete
Stakeholder Create Print
Primary Actor Read Export
Supporting Actor Update Others
Delete

3.2. Essential Use Case Diagram

This section is applicable only to Use case approach. This section depicts the
Business Requirements in the form of Essential Use case diagram. In the Use
case approach, the Functional Requirements are decomposed into a number of
Essential Use cases. Essential use 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.

3.3. Essential Use Case Specifications

This section is applicable only to Use case approach. This section describes
each Essential Use case in narrative text form. A use case typically has one
basic course of action and one or more alternate courses of actions. The basic
course of action is the main start-to-finish path that the use case will follow,
where as the alternate courses represent the infrequently used paths and
exceptions, error conditions etc. The complete business logic of a use case such
as basic course of action, alternate course of action, pre-condition, post-condition
etc is not depicted in the Use case diagram. Rather they are documented in
narrative style in use case specifications.

Last revised:26/04/2013 Page 10 of 26

Security Classification: Low

Business Requirements Document Project Name

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.

Last revised:26/04/2013 Page 11 of 26

Security Classification: Low

Business Requirements Document Project Name

Use Case Id : ##

Use Case Name

Description

Actors

Business Rules List the business rules of Section 3.6 that

this use case references. Mention only
the Business rule Id here. Provide
hyperlinks to the business rules of
section 3.6.

Basic Flow Alternate Flows

Non-Functional Requirements

Pre-Conditions

Post-Conditions

Extension Points Extension Condition Extending Use Case

List of <<included>> List of <<extended>> List of “inherited from

use cases use cases (parent)” use cases

3.4. Function Hierarchy Diagram

This section is applicable only to Designer approach. This section depicts the
Business Requirements in the form of Function Hierarchy Diagram (FHD). In the

Last revised:26/04/2013 Page 12 of 26

Security Classification: Low

Business Requirements Document Project Name

Oracle Designer approach, the Functional Requirements are decomposed into a

number of Business Functions.

3.5. Function Definition Report

This section is applicable only to Designer approach. This section describes each
Business Function in narrative text form.

3.6. Business Rules

This section lists and describes the business rules applicable to the proposed
system.

Last revised:26/04/2013 Page 13 of 26

Security Classification: Low

Business Requirements Document Project Name

Business Rule Name Rule Description Rule Source

Rule Id
BR#### - P
olicy manual
- St
rategic decisions
- C
ontractual
obligations
- S
ubject matter
experts
- Ot
her Sources
(mention the
sources)

4. Data Requirements

This section describes the Data requirements part of the Business Requirements.

4.1. Data Architecture

This section describes the Data Architectural requirements part of the Business
Requirements.

4.1.1. Domain Class Diagram

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
Last revised:26/04/2013 Page 14 of 26

Security Classification: Low

Business Requirements Document Project Name

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.

4.1.2. Entity Relationship Diagram

This section is applicable only to Oracle Designer approach. This section depicts
the Data Architecture in the form of Entity Relationship Diagram (ERD). In the
Oracle Designer approach, the conceptual data architecture (structural aspects)
for the Business Requirements is modeled using Entity Relationship Diagram
(ERD).

4.2. Data Volumes

This section describes the expected approximate Data volumes (initial volume
and annual growth %) for each conceptual Class or Entity.

4.3. Data Conversion

This section describes the high-level Data Conversion Requirements.

4.4. Data Retention and Archiving

This section describes the Data retention (time frames for online Data retention
before archiving) and also the archiving requirements.

4.5. FOI/Privacy Implications

This section describes the sensitivity levels of each class of data. The following
criteria are used in determining the sensitivity level of each conceptual
class/entity in line with the Government Core Policy Manual).

Last revised:26/04/2013 Page 15 of 26

Security Classification: Low

Business Requirements Document Project Name

 Non-sensitive information that would not reasonably be expected to

cause injury (harm) if released to the public;

 Protected A: information that, if compromised, could reasonably be

expected to cause injury (harm), e.g. loss of privacy;

 Protected B: information that, if compromised, could reasonably be

expected to cause serious injury (harm), e.g. the conduct of a court
proceeding would be adversely affected;

 Protected C: information that, if compromised, could reasonably be

expected to cause extremely grave injury (harm), e.g. loss of life.

Conceptual Class / Data Sensitivity Level

Entity Name (Non-sensitive,
Protected A,
Protected B,
Protected C)

4.6. Data Definition Reports

This section describes the Data Architecture / definition in a report format.

4.6.1. Domain Class Definition Report

This section is applicable only to Use case approach. This section describes
Data Architecture / definition (Domain Class model) in narrative text form.

Last revised:26/04/2013 Page 16 of 26

Security Classification: Low

Business Requirements Document Project Name

Class Name

Class Description

Initial Data Volume (approx.)

Annual Data growth rate (in

approx. %)
Attributes (fields) of the class Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :

4.6.2. Entity Definition Report

This section is applicable only to Oracle Designer approach. This section

describes Data Architecture / definition (Entity Relationship model) in narrative
text form.

Last revised:26/04/2013 Page 17 of 26

Security Classification: Low

Business Requirements Document Project Name

Entity Name

Entity Description

Initial Data Volume (approx.)

Annual Data growth rate (in

approx. %)
Attributes (fields) of the Entity Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :

5. 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.

5.1. Security Requirements

This section describes the Security requirements part of the Business

Requirements.

Last revised:26/04/2013 Page 18 of 26

Security Classification: Low

Business Requirements Document Project Name

5.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) :

Level 0 : Anonymous transaction – triggers transactions that do not require

or allow a person to be identified, or transactions which require protection of a
person's identity. For example, access to online information about
government programs or services or protecting a person's identity.
Combining the transaction data with other data must not allow identification of
a particular individual.
Level 1 : Pseudonymous transaction – triggers transactions that do not
require a person to be identified but do require a means for further contact to
deliver a product or service. For example, a note from
someperson@internet.ca can not be readily translated into an individual’s
name, but it may be sufficient to request information, to provide some
services, or on-going follow up.
Level 2 : Identified transaction – triggers transactions that require that a
person be specifically identified. The nature of the transaction may require
confirmation of a person's identity (e.g., name, address, birth date, etc.)
and/or data linking the person to a transaction (e.g., invoice number, personal
health number, etc.).
Level 3 : Verified transaction – triggers transactions that require: the person
to be specifically identified; verification of the integrity of the data exchanged
and the exchange itself; and, the creation of sufficient evidence to indicate
that the person agreed to be bound by the transaction. For example, a note
signed with a digital certificate, audit trails and security logs may provide
sufficient evidence that a specific person intended to conduct a transaction.

Use Case / Business Transaction type triggered

Function Name (Level 0 : Anonymous,
Level 1 : Pseudonymous,
Level 2 : Identified,
Level 3 : Verified)

Last revised:26/04/2013 Page 19 of 26

Security Classification: Low

Business Requirements Document Project Name

5.1.2. Authorization and Access Controls

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.

Actor / Conceptual Class / Type of Access

Business Unit Business Entity Control needed on
Name Name the Conceptual Class
/ Business Entity :

C  Create
R  Read
U  Update
D  Delete

5.1.3. Information Security Classification and labelling

This section is provided for information purposes only. Please do not delete this
section while creating the Business requirements Document from this template.

Last revised:26/04/2013 Page 20 of 26

Security Classification: Low

Business Requirements Document Project Name

The “Information security classification and labeling of information assets” is a

process published and managed by OCIO. According to this process, all
government “records” as defined in the Interpretation Act need to be classified.
(“record” includes books, documents, maps, drawings, photographs, letters,
vouchers, papers and any other thing on which information is recorded or stored
by any means whether graphic, electronic, mechanical or otherwise).

There are no business requirements (functional or non-functional requirements)

applicable to the Information security classification of the
application/project/initiative for which the BRD is being written. Hence there is no
need to fill-in anything in this section.

However, please be aware that the finished application/initiative/project and all its
output deliverables (such as documents, models, diagrams etc) need to be
classified and labelled in accordance with the OCIO guidelines. This will help in
determining how much protection the finished application and its data will need
commensurate with its sensitivity levels determined during information security
classification process. It will also help in evaluation of risks associated with
authorized and unauthorized disclosures of the application’s data.

5.2. Availability Requirements

This section describes the system availability requirements.

Last revised:26/04/2013 Page 21 of 26

Security Classification: Low

Business Requirements Document Project Name

Use Case / Business Availability Requirements

Function Name - Regular work hours
- 24x7
- Any other (please
describe)

5.3. Usability Requirements

This section describes the system usability requirements. A usability requirement

specifies how easy the system must be to use. Usability is a non-functional
requirement, because in its essence it doesn't specify parts of the system
functionality, but specifies only how that functionality is to be perceived by the
user, for instance how easy it must be to learn and operate the system.

5.4. System Help Requirements

This section describes what kind of System Help features are needed to be built
into the system.

Last revised:26/04/2013 Page 22 of 26

Security Classification: Low

Business Requirements Document Project Name

Use Case / Business Help Requirements

Function Name - Field level (online)
- Screen level (online)
- Help Printing Options
- Operations Manual
(Offline)
- Any other (please
describe)

5.5. Performance Requirements

This section describes system performance expectation levels (response times).

Use Case Name / Performance

Business Function Requirements (response
Name / Transaction time)
description (in seconds or minutes)

5.6. Scalability Requirements

This section describes how the system is expected to scale to new higher or
lower levels. Both user and application scalability requirements are described
here. Data scalability is not described here as it is already described in the “data
volumes” section earlier.

Last revised:26/04/2013 Page 23 of 26

Security Classification: Low

Business Requirements Document Project Name

5.6.1. User Scalability

5.6.2. Application Scalability

6. Interface Requirements

This section describes User and System Interface requirements for the proposed
system.

6.1. User Interface Requirements

6.2. System Interface Requirements

7. Business Glossary

Last revised:26/04/2013 Page 24 of 26

Security Classification: Low

Business Requirements Document Project Name

APMS Update

APMS update required? Yes No

APMS updated/to be updated on (date):

Comments:

Revision Log

Date Versio Change Reference Reviewed by

n
[date]

Appendices

Enter content here.

Last revised:26/04/2013 Page 25 of 26

Security Classification: Low

Business Requirements Document Project Name

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]
Approved by Signature Date

[Client Acceptor’s
Name]
[Title]
[Organization]

Last revised:26/04/2013 Page 26 of 26

Security Classification: Low