____________________

Business Requirements
Document
For

Nursing Education Portal

Business Domain: Learning Management

Business Process: User Management, Training Management, Content Delivery

Title: Nursing Education Video Streaming e-Learning System

Version: 1
Release: 1

Project Sponsor: NEP Inc.

Prepared by: Basu Mukherjee
Prepared for: NEP Inc.
Date Submitted: 16/03/2013

Client Acceptor: John Doe

Project Manager: Jane Doe
Security Classification: Medium
Date of Creation: 06/13/ 2012
Last Updated: mm/dd/yyyy
Business Requirements Document for <NEP> Page 2

Table of Contents
CONTENTS ...................................................................................................................................................................... 2

DOCUMENT SUMMARY ............................................................................................................................................... 4

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

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 3

6.2 HARDWARE INTERFACES .............................................................................................................................. 16

6.3 SOFTWARE INTERFACES ............................................................................................................................... 16
6.4 COMMUNICATIONS INTERFACES ................................................................................................................... 16
7 NON-FUNCTIONAL REQUIREMENTS ........................................................................................................... 17
7.1 SAFETY AND SECURITY REQUIREMENTS...................................................................................................... 17
7.2 AVAILABILITY REQUIREMENTS ...................................................................................................................... 19
7.3 USABILITY REQUIREMENTS ........................................................................................................................... 19
7.4 SYSTEM HELP REQUIREMENTS .................................................................................................................... 19
7.5 PERFORMANCE REQUIREMENTS .................................................................................................................. 20
7.6 SCALABILITY REQUIREMENTS ....................................................................................................................... 20
8 REVISION LOGS ................................................................................................................................................. 21

APPENDIX A – DATA DICTIONARY ......................................................................................................................... 22

APPENDIX B – JAD SESSION LOGS ....................................................................................................................... 23

APPROVAL .................................................................................................................................................................... 24

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 4

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.

Release Primary Author(s) Description of Version Date Completed

Release 1 Basu Mukherjee Information about the release. This table 06/13/2012
does not need to be filled in whenever a
document is touched, only when the
release is being upgraded.

Document Owner Title Status

SynergyTech Nursing Education Video Streaming e-Learning System First Draft

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 5

1 Introduction

1.1 Document Purpose

Provide a brief introduction of the project whose software requirements are specified in this
document and a brief overview of what the reader will find in this section. Write 1-4 paragraphs
describing the purpose of this document. Identify the product whose software requirements are
specified in this document, including the revision or release number. Describe the scope of the
product that is covered by this BRD, particularly if this BRD describes only part of the system or a
single subsystem.

1.2 Intended Audience and Document Overview

Describe the different types of readers that the document is intended for, such as stakeholders,
developers, project managers, testers, and documentation writers. Describe what the rest of this
BRD contains and how it is organized. Suggest a sequence for reading the document, beginning
with the overview sections and proceeding through the sections that are most pertinent to each
reader type.

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.

1.3 Definitions, Acronyms and Abbreviations

Define all the terms necessary to properly interpret the BRD, including acronyms and
abbreviations. Build a separate glossary that spans multiple projects or the entire organization, and
just include terms specific to a single project in each BRD. Provide a list of all abbreviations and
acronyms used in this document sorted in alphabetical order.

1.4 Document Conventions

1.4.1 Formatting Conventions

This document follows the IEEE formatting requirements. Several formatting conventions have
been followed throughout the entire document:

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 6

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

1.4.2 Naming Conventions

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.

1.5 References and Acknowledgments

List any other documents or Web addresses to which this BRD refers. These may include user
interface style guides, contracts, standards, system requirements specifications, or a vision and
scope document. Use the standard IEEE citation guide for this section.

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 7

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

2.2 Out of Scope

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 8

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.1 Project Background

This section describes if these Business Requirements are as a result of any previous meetings,
correspondence, legislation etc.

3.2 Purpose of 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).

3.3 Business Goals / Objectives To be Achieved

This section describes the major goals/objectives to be achieved with the implementation of the
Business Requirements.

3.4 Benefits / Rationale

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

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.

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 9

3.6 Product Perspective

Describe the context and origin of the product being specified in this BRD. For example, state
whether this product is a follow-on member of a product family, a replacement for certain existing
systems, or a new, self-contained product. If the BRD defines a component of a larger system,
relate the requirements of the larger system to the functionality of this software and identify
interfaces between the two. In this part, make sure to include a simple diagram that shows the
major components of the overall system, subsystem interconnections, and external interface.
Provide at least 1-2 paragraph describing product perspective. Provide a general diagram that will
illustrate how the product interacts with the environment and in what context it is being used.

3.7 Product Functionality

Summarize the major functions the product must perform or must let the user perform. Provide
only a high level summary is needed here. Organize the functions to make them understandable to
any reader of the BRD. A picture of the major groups of related requirements and how they relate,
such as a top level data flow diagram or object class diagram, will be effective. Provide a bulleted
list of all the major functions of the system. Provide a Data Flow Diagram of the system to show
how these functions relate to each other.

3.8 Users and Characteristics

Identify the various users that will use this product. Users may be differentiated based on
frequency of use, subset of product functions used, technical expertise, security or privilege levels,
educational level, or experience. Describe the pertinent characteristics of each user. Certain
requirements may pertain only to certain users. Distinguish the most important users for this
product from those who are less important to satisfy.

3.9 Operating Environment

Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coexist. In this part, make sure to include a simple diagram that shows the major
components of the overall system, subsystem interconnections, and external interface. As stated
above, in at least 1-2 paragraphs, describe the environment the system will have to operate in.
Make sure to include the minimum platform requirements for the system.

3.10 Design and Implementation Constraints

Describe any items or issues that will limit the options available to the developers. These might
include: hardware limitations (timing requirements, memory requirements); interfaces to other
applications; specific technologies, tools, and databases to be used; parallel operations; language
requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customer’s organization will be responsible for
maintaining the delivered software).Consider all of the information gathered so far, analyze it and
correctly identify at least 5 -10 constraints.

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 10

3.11 User Documentation

List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software. Identify any known user documentation delivery formats
or standards.

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.

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 11

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.

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

Actor Name Actor Type Access Type needed Comments

Student Stakeholder Create Print

Primary Actor Read Export
Supporting Actor Update Others
Delete
Instructor Stakeholder Create Print
Primary Actor Read Export
Supporting Actor Update Others
Delete
Institute Stakeholder Create Print
Primary Actor Read Export
Supporting Actor Update Others
Delete
Admin Stakeholder Create Print
Primary Actor Read Export
Supporting Actor Update Others
Delete

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

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 12

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.

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

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 : ##

Use Case Name

Description

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.

Basic Flow Alternate Flows

Non-Functional Requirements

Pre-Conditions

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 13

Post-Conditions

Extension Points Extension Condition Extending Use Case

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

cases cases (parent)” use cases

4.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 Oracle Designer approach,
the Functional Requirements are decomposed into a number of Business Functions.

4.5 Function Definition Report

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

4.6 Business Rules

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

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 14

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

5.1 Data Architecture

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

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

5.2 Data Volumes

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

5.3 Data Conversion

This section describes the high-level Data Conversion Requirements.

5.4 Data Retention and Archiving

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

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

• Non-sensitive information that would not reasonably be expected to cause injury (harm) if
released to the public;

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 15

• 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 / Entity Data Sensitivity Level

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

5.6 Data Definition Reports

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

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

Class Name

Class Description

Initial Data Volume (approx.)

Annual Data growth rate (in approx. %)

Attributes (fields) of the class Name :

Description :
Name :
Description :

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 16

6 Interface Requirements

6.1 User Interfaces

Describe the logical characteristics of each interface between the software product and the users.
This may include sample screen images, any GUI standards or product family style guides that are
to be followed, screen layout constraints, standard buttons and functions (e.g., Cancel) that will
appear on every screen, error message display standards, and so on. Define the software
components for which a user interface is needed. Provide different User Interfaces and the
different screens that will be available to the user.

6.2 Hardware Interfaces

Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware. Provide a short
description of the different hardware interfaces. If some special libraries are used to communicate
with the software, mention them here. In case more than one hardware interfaces are used, divide
this section into subsections.

6.3 Software Interfaces

Describe the connections between this product and other specific software components (name
and version), including databases, operating systems (Windows? Linux? Etc…), tools, libraries,
and integrated commercial components. Identify the data items or messages coming into the
system and going out and describe the purpose of each. Describe the services needed and the
nature of communications. Identify data that will be shared across software components. If the
data sharing mechanism must be implemented in a specific way (for example, use of a global data
area in a multitasking operating system), specify this as an implementation constraint.

6.4 Communications Interfaces

Describe the requirements associated with any communications functions required by this product,
including e-mail, web browser, network server communications protocols, electronic forms, and so
on. Define any pertinent message formatting. Identify any communication standards that will be
used, such as FTP or HTTP. Specify any communication security or encryption issues, data
transfer rates, and synchronization mechanisms. Provide 1-2 paragraphs to outline the major
communication standards. If encryption is used there is no need to specify the exact encryption
standards, but rather, specify the fact that the data will be encrypted and name what standards
that mat be considered using.

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 17

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 Safety and Security Requirements

Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well as
actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied. Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements. Provide at least 3-6 different safety requirements based on interview
with the client. Describe briefly the level of security is expected from this product by the client and
provide a bulleted list of the major security requirements.

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

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.

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 18

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)

7.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 / Business Conceptual Class / Type of Access Control

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

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

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 19

7.2 Availability Requirements

This section describes the system availability requirements.

Use Case / Business Availability Requirements

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

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

7.4 System Help Requirements

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

Use Case / Business Help Requirements

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

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 20

7.5 Performance Requirements

If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. Need to state performance requirements for individual functional requirements
or features.

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

Use Case Name / Business Performance Requirements

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

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

7.6.1 User Scalability

7.6.2 Application Scalability

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 21

8 Revision Logs

Date of Change Version Release Sections Changed Summary of Changes Reviewed by

mm/dd/yyyy

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 22

Appendix A – Data Dictionary

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.

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 23

Appendix B – JAD Session Logs

Date Participants Topics Discussed
mm/dd/yyyy

Last Revised Date: Confidential document not for circulation.

Business Requirements Document for <NEP> Page 24

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 Date: Confidential document not for circulation.