Ministry/Agency Name

[Complete file/properties to populate fields on this page and in the document headers]
Project Name
Project #:
Business Requirements Document (BRD) Template
Prepared by: Author's Name
Prepared for:
Date Submitted: [Date]
Project Sponsor: Project Sponsor's Name
lient !cceptor:
Project "ana#er:
Document Number: 6450!0/Project Num"er /#$D
Security lassification: $o%
&ersion: 0%&
$ast 'pdated: Apri' !6( !0&)
reation Date: *une 06( !006
Business Requirements Document Project Name
Table of ontents
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.. STAKEHOLDERS..............................................................................................................................6
1.!. DEPENDENCIES ON E"ISTING S#STEMS..........................................................................................6
1.$. REFERENCES..................................................................................................................................6
1.1%. ASSUMPTIONS................................................................................................................................6
2. REQUIREMENTS SCOPE.................................................................................................................7
2.1. IN SCOPE........................................................................................................................................!
2.2. OUT OF SCOPE...............................................................................................................................!
3. FUNCTIONAL REQUIREMENTS....................................................................................................8
3.1. ACTOR PROFILES SPECIFICATION...................................................................................................!
3.2. ESSENTIAL USE CASE DIAGRAM...................................................................................................$
3.3. ESSENTIAL USE CASE SPECIFICATIONS.........................................................................................$
3.4. FUNCTION HIERARCH# 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/PRIVAC# 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. SECURIT# REQUIREMENTS...........................................................................................................1
5.1.1. Authentication........................................................................................................................17
5.1.2. Authoriation an! Access Controls........................................................................................1"
5.1.3. #nformation $ecurity Classification an! la%elling.................................................................1&
5.2. AVAILABILIT# REQUIREMENTS....................................................................................................2%
5.3. USABILIT# REQUIREMENTS.........................................................................................................21
5.4. S#STEM HELP REQUIREMENTS....................................................................................................21
5.5. PERFORMANCE REQUIREMENTS...................................................................................................22
5.6. SCALABILIT# REQUIREMENTS.....................................................................................................22
5.6.1. 'ser $cala%ility......................................................................................................................22
5.6.2. Application $cala%ility...........................................................................................................22
Last revised!"/#$/!#%& Page ! of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
6. INTERFACE REQUIREMENTS.....................................................................................................23
6.1. USER INTERFACE REQUIREMENTS...............................................................................................23
6.2. S#STEM INTERFACE REQUIREMENTS...........................................................................................23
7. BUSINESS GLOSSARY....................................................................................................................23
APMS UPDATE............................................................................................................................................24
REVISION LOG..........................................................................................................................................24
APPENDICES...............................................................................................................................................24
APPROVAL..................................................................................................................................................25
Last revised!"/#$/!#%& Page & of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
() *ntroduction
()() Document Purpose
+he purpose o, this -ocument is to -escri"e "usiness re.uirements o, an App'ication comp'ete'y(
accurate'y an- unam"iguous'y in +echno'ogyin-epen-ent manner% A'' attempts ha/e "een ma-e
in using most'y "usiness termino'ogy an- "usiness 'anguage 0hi'e -escri"ing the re.uirements in
this -ocument% 1ery minima' an- common'y un-erstoo- +echnica' termino'ogy is use-% 'se
case / Desi#ner approac+ is use- in mo-e'ing the "usiness re.uirements in this -ocument%
[Delete the approach that is not applica+le,]
(),) *ntended !udience
+he main inten-e- au-ience ,or this -ocument are the "usiness o0ners o, the propose- system%
+his -ocument shou'- "e rea-a"'e "y "usiness o0ners o, the propose- system% +hey must "e
a"'e to /eri,y that their "usiness re.uirements ha/e "een -ocumente- here comp'ete'y(
accurate'y an- unam"iguous'y%
Data Architects( App'ication Architects an- +echnica' Architects 0ou'- a'so ,in- the in,ormation in
this -ocument use,u' 0hen they nee- to -esign a so'ution that 0i'' a--ress these "usiness
re.uirements%
Since the re.uirements are -ocumente- here in +echno'ogyin-epen-ent manner( the en-users
o, the system shou'- "e a"'e to comprehen- the re.uirements ,air'y easi'y ,rom this -ocument%
Document filling instructions
-his document template contains hidden te.t, -o ena+le hidden te.t/ under the 0-ools 1
2ptions 1 3ie*4 ta+/ ma5e sure that 67idden -e.t6 is chec5ed, -o print the template *ith
hidden te.t displa)ed/ under the 0-ools 1 2ptions 1 Print4 ta+/ ma5e sure that 67idden -e.t6 is
chec5ed,
-he te.t in black colour is meant to +e part of the final filled in document, Please do not
delete them,
-he te.t in red colour is instructions and e.amples on *hat to fill in the various sections of
this document, Please fill in the sections as per instructions and then delete the red coloured
te.t 8instructions and e.amples9,
Please do not leave an) section +lan5, :f a section is not applica+le/ then t)pe in 0Not
;pplica+le4 in that section,
Please ensure not to descri+e ()stem Design issues in this document,
Last revised!"/#$/!#%& Page $ of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
Currentl) t*o approaches to modeling the Business Requirements are supported +)
<inistr)=s ;D> standards
?<L ?se case modeling using an) tool that supports the ?<L notation and standards as
descri+ed in the ;D> standards *e+ site @
>ntit) Relationship Diagram 8>RD9 and Aunction 7ierarch) Diagram 8A7D9 modeling
using 2racle Designer tool,
-his document template supports +oth ?se case and Designer modeling approaches, :t is
highl) recommended that onl) one of the t*o modeling approaches is adopted for descri+ing
the Business Requirements in this document and not a h)+rid approach, Data models ma)
+e presented either in >RD notation or in ?<L class notation/ regardless of *hich modeling
approach *as used, ;ll <odeling should conform to <inistr)=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.
;fter finishing the document/ please reBgenerate the complete -a+le of Contents to reflect the
correct page num+ering, 8(elect the -a+le of contents@ rightBclic5@ select 0update fields4 and
select 0update entire ta+le4 commands,9
()-) Project Bac.#round
+his section -escri"es i, these #usiness $e.uirements are as a resu't o, any pre/ious meetings(
correspon-ence( 'egis'ation etc%
()/) Purpose of t+e Business Requirements
+his section -escri"es the purpose o, the #usiness $e.uirements%
#usiness re.uirements ,or major enhancements to an e2isting app'ication%
#usiness re.uirements ,or ne0 app'ication -e/e'opment%
#usiness re.uirements ,or rep'acement app'ication -e/e'opment%
#usiness re.uirements ,or a re.uest ,or proposa's 3$4P5%
Last revised!"/#$/!#%& Page ' of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
()0) Business 1oals23bjecti4es to be ac+ie4ed
+his section -escri"es the major goa's/o"jecti/es to "e achie/e- 0ith the imp'ementation o, the
#usiness $e.uirements%
()5) Benefits2Rationale
+his section -escri"es the major "ene,its to "e achie/e- 0ith the imp'ementation o, the #usiness
$e.uirements%

()6) Sta.e+olders
Sta6eho'-ers are the in-i/i-ua's or groups 0ho ha/e a /este- interest in this project an- 0hose
interests nee- to "e consi-ere- throughout the project% +his section 'ists the Sta6eho'-ers o, the
App'ication / Project ,or 0hich these #usiness re.uirements are -ocumente-%
()7) Dependencies on e8istin# systems
+his section -escri"es the -epen-encies "et0een the App'ication ,or 0hich these #usiness
$e.uirements are 0ritten an- the other e2isting app'ications/systems%
()9) References
+his section 'ists the re,erences to pre/ious -ocumentation( correspon-ence etc ( i, any( that are
re'ate- to these #usiness $e.uirements%
Last revised!"/#$/!#%& Page " of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
()(:) !ssumptions
+his section -escri"es major assumptions that 0ere ma-e prior to or -uring the #usiness
$e.uirements gathering an- -ocumentation%
,) Requirements Scope
+his section sho0s 0hat "usiness ,unctiona'ity is in scope an- out o, scope ,or 7mp'ementation%
7n 8se case approach( the out o, scope 8se cases are in-icate- in a separate "oun-ary "o2% 7n
9rac'e Designer approach the out o, scope 4unctions are sho0n in grey co'oure- "o2es%
Last revised!"/#$/!#%& Page C of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
,)() *n Scope
,),) 3ut of Scope
-) ;unctional Requirements
+his section -escri"es the Aunctional requirements part o, the #usiness $e.uirements% 7n 8se
case approach( the Aunctional Requirements comprises o, Actor Pro,i'e Speci,ication( :ssentia'
8se case -iagram an- :ssentia' 8se case speci,ication in narrati/e te2t ,orm% 7n 9rac'e Designer
approach the Aunctional Requirements comprises o, #usiness 8nit De,inition $eport( 4unction
;ierarchy Diagram an- 4unction De,inition $eport%
-)() !ctor Profiles Specification
+his section -escri"es a'' the Actors an- their pro,i'es 0ithin the conte2t o, the #usiness
$e.uirements "eing -ocumente-% An Actor is a person( organi<ation or an e2terna' system/su"
system/program that has interactions 0ith the App'ication% Actors( "y -e,inition( are e2terna' to the
system 0ith 0hich they are ha/ing interactions% Actors ha/e goa's that are achie/e- "y use
cases% +ypica''y( Actors ha/e "eha/iour an- are represente- "y the ro'es they p'ay in the use
cases% An Actor stimu'ates the system "y pro/i-ing input an-/or recei/ing something o,
measura"'e /a'ue ,rom the system%
7n 8se case approach( the Actor Pro,i'e is -ocumente- in a separate temp'ate a/ai'a"'e on the
AD: 0e" site,
7n 9rac'e Designer approach the Actor Pro,i'e in,ormation is -ocumente- un-er =#usiness 8nits>
,o'-er o, 9rac'e Designer an- the =#usiness 8nits De,inition> report ,rom 9rac'e Designer is
generate- an- attache- 0ith these #usiness $e.uirements%
Last revised!"/#$/!#%& Page D of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
A!"# N$%&
!ctor Type !ccess Type needed omments
S&'()*+,-).
P./0'.1 A2&+.
S344+.&/56 A2&+.
C.)'&) P./5&
R)'- E74+.&
U4-'&) O&*).8
D),)&)
S&'()*+,-).
P./0'.1 A2&+.
S344+.&/56 A2&+.
C.)'&) P./5&
R)'- E74+.&
U4-'&) O&*).8
D),)&)
S&'()*+,-).
P./0'.1 A2&+.
S344+.&/56 A2&+.
C.)'&) P./5&
R)'- E74+.&
U4-'&) O&*).8
D),)&)
S&'()*+,-).
P./0'.1 A2&+.
S344+.&/56 A2&+.
C.)'&) P./5&
R)'- E74+.&
U4-'&) O&*).8
D),)&)
-),) <ssential 'se ase Dia#ram
+his section is app'ica"'e on'y to 8se case approach% +his section -epicts the #usiness
$e.uirements in the ,orm o, :ssentia' 8se case -iagram% 7n the 8se case approach( the
4unctiona' $e.uirements are -ecompose- into a num"er o, :ssentia' 8se cases% :ssentia' use
cases are o, primary importance ear'y in a project?s re.uirements/ana'ysis phase% +heir purpose
is to -ocument the "usiness process that the App'ication must support 0ithout "ias to techno'ogy
an- imp'ementation%
-)-) <ssential 'se ase Specifications
+his section is app'ica"'e on'y to 8se case approach% +his section -escri"es each :ssentia' 8se
case in narrati/e te2t ,orm% A use case typica''y has one "asic course o, action an- one or more
a'ternate courses o, actions% +he "asic course o, action is the main startto,inish path that the
use case 0i'' ,o''o0( 0here as the a'ternate courses represent the in,re.uent'y use- paths an-
e2ceptions( error con-itions etc% +he comp'ete "usiness 'ogic o, a use case such as "asic course
o, action( a'ternate course o, action( precon-ition( postcon-ition etc is not -epicte- in the 8se
case -iagram% $ather they are -ocumente- in narrati/e sty'e in use case speci,ications%
7, the num"er o, use cases is 'ess than &5( the :ssentia' 8se case speci,ications in narrati/e ,orm
are inc'u-e- in this #$D in ta"u'ar ,ormat% :ach use case is -escri"e- in a separate ta"'e% 7, the
Last revised!"/#$/!#%& Page E of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
num"er o, use cases is greater than &5( the :ssentia' 8se case speci,ications in narrati/e ,orm
are attache- as a separate -ocument 0ith this #$D%

Last revised!"/#$/!#%& Page %# of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
'se ase *d : ##
'se ase Name
Description
!ctors
Business Rules @ist the "usiness ru'es o, Section )%6 that this use
case re,erences% Mention on'y the #usiness ru'e
7- here% Pro/i-e hyper'in6s to the "usiness ru'es
o, section )%6%
Basic ;lo% !lternate ;lo%s
Non=;unctional Requirements
Pre=onditions
Post=onditions
<8tension Points <8tension ondition <8tendin# 'se ase
$ist of >>included?? use
cases
$ist of >>e8tended?? use
cases
$ist of @in+erited from
(parent)A use cases
-)/) ;unction Bierarc+y Dia#ram
+his section is app'ica"'e on'y to Designer approach% +his section -epicts the #usiness
$e.uirements in the ,orm o, 4unction ;ierarchy Diagram 34;D5% 7n the 9rac'e Designer
approach( the 4unctiona' $e.uirements are -ecompose- into a num"er o, #usiness 4unctions%
-)0) ;unction Definition Report
Last revised!"/#$/!#%& Page %% of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
+his section is app'ica"'e on'y to Designer approach% +his section -escri"es each #usiness
4unction in narrati/e te2t ,orm%
-)5) Business Rules
+his section 'ists an- -escri"es the "usiness ru'es app'ica"'e to the propose- system%
Last revised!"/#$/!#%& Page %! of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
Business
Rule *d
Rule Name Rule Description Rule Source
#$AAAA
Po
'icy manua'
Str
ategic -ecisions
Bo
ntractua' o"'igations
Su
"ject matter e2perts
9t
her Sources 3mention
the sources5
/) Data Requirements
+his section -escri"es the Data re.uirements part o, the #usiness $e.uirements%
/)() Data !rc+itecture
+his section -escri"es the Data Architectura' re.uirements part o, the #usiness $e.uirements%
/)()() Domain lass Dia#ram
+his section is app'ica"'e on'y to 8se case approach% +his section -epicts the Data Architecture
in the ,orm o, Domain B'ass Diagram% 7n the 8se case approach( the conceptua' -ata architecture
3structura' aspects5 ,or the #usiness $e.uirements is mo-e'e- using Domain B'ass Diagram% +he
Domain B'ass Diagram is use- to mo-e' the conceptua' c'asses( its attri"utes 3,ie'-s5 an-
operations 3metho-s5 an- a'so the interre'ationships 3association( composition( aggregation an-
Last revised!"/#$/!#%& Page %& of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
genera'i<ation5 "et0een the c'asses% Domain mo-e' is a representation o, rea' 0or'- conceptua'
c'asses( not o, so,t0are components%
/)(),) <ntity Relations+ip Dia#ram
+his section is app'ica"'e on'y to 9rac'e Designer approach% +his section -epicts the Data
Architecture in the ,orm o, :ntity $e'ationship Diagram 3:$D5% 7n the 9rac'e Designer approach(
the conceptua' -ata architecture 3structura' aspects5 ,or the #usiness $e.uirements is mo-e'e-
using :ntity $e'ationship Diagram 3:$D5%
/),) Data &olumes
+his section -escri"es the e2pecte- appro2imate Data /o'umes 3initia' /o'ume an- annua' gro0th
C5 ,or each conceptua' B'ass or :ntity%
/)-) Data on4ersion
+his section -escri"es the high'e/e' Data Bon/ersion $e.uirements%
/)/) Data Retention and !rc+i4in#
+his section -escri"es the Data retention 3time ,rames ,or on'ine Data retention "e,ore archi/ing5
an- a'so the archi/ing re.uirements%
/)0) ;3*2Pri4acy *mplications
+his section -escri"es the sensiti/ity 'e/e's o, each c'ass o, -ata% +he ,o''o0ing criteria are use-
in -etermining the sensiti/ity 'e/e' o, each conceptua' c'ass/entity in 'ine 0ith the Do/ernment
Bore Po'icy Manua'5%
on-sensitive information that *ould not reasona+l) +e e.pected to cause injur) 8harm9
if released to the pu+lic@
Last revised!"/#$/!#%& Page %$ of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name

!rotected " information that/ if compromised/ could reasona+l) +e e.pected to cause
injur) 8harm9/ e,g, loss of privac)@
!rotected # information that/ if compromised/ could reasona+l) +e e.pected to cause
serious injur) 8harm9/ e,g, the conduct of a court proceeding *ould +e adversel) affected@

!rotected $ information that/ if compromised/ could reasona+l) +e e.pected to cause
e.tremel) grave injur) 8harm9/ e,g, loss of life,
onceptual lass 2 <ntity
Name
Data Sensiti4ity $e4el
(Non=sensiti4eC
Protected !C
Protected BC
Protected )
/)5) Data Definition Reports
+his section -escri"es the Data Architecture / -e,inition in a report ,ormat%
/)5)() Domain lass Definition Report
+his section is app'ica"'e on'y to 8se case approach% +his section -escri"es Data Architecture /
-e,inition 3Domain B'ass mo-e'5 in narrati/e te2t ,orm%
Last revised!"/#$/!#%& Page %' of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
lass Name
lass Description
*nitial Data &olume (appro8))
!nnual Data #ro%t+ rate (in appro8) D)
!ttributes (fields) of t+e class Name E
Description E
Name E
Description E
Name E
Description E
Name E
Description E
Name E
Description E
Name E
Description E
/)5),) <ntity Definition Report
+his section is app'ica"'e on'y to 9rac'e Designer approach% +his section -escri"es Data
Architecture / -e,inition 3:ntity $e'ationship mo-e'5 in narrati/e te2t ,orm%
Last revised!"/#$/!#%& Page %" of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
<ntity Name
<ntity Description
*nitial Data &olume (appro8))
!nnual Data #ro%t+ rate (in appro8) D)
!ttributes (fields) of t+e <ntity Name E
Description E
Name E
Description E
Name E
Description E
Name E
Description E
Name E
Description E
Name E
Description E
0) Non=;unctional requirements
+his section -escri"es the non,unctiona' re.uirements part o, the #usiness $e.uirements% A
non,unctiona' re.uirement is typica''y a specia' re.uirement that is not easi'y or natura''y
speci,ie- in the te2t o, the use case?s or ,unction?s e/ent ,'o0% :2amp'es o, non,unctiona'
re.uirements inc'u-e 'ega' an- regu'atory re.uirements( app'ication stan-ar-s( an- .ua'ity
attri"utes o, the system to "e "ui't inc'u-ing usa"i'ity( re'ia"i'ity( per,ormance or supporta"i'ity
re.uirements%
0)() Security Requirements
+his section -escri"es the Security re.uirements part o, the #usiness $e.uirements%
0)()() !ut+entication
+his section -escri"es the Authentication re.uirements part o, the #usiness $e.uirements%
Authentication is the process o, /eri,ying the genuineness o, c'aims that a person/group ma6es to
esta"'ish i-entity/e'igi"i'ity ,or access to ser/ices% 7n or-er to ascertain the Authentication
Last revised!"/#$/!#%& Page %C of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
re.uirements o, the App'ication( it is re.uire- to ana'yse the type o, transactions that -i,,erent 8se
cases/#usiness 4unctions trigger 0ithin the App'ication% +he ,o''o0ing criteria is use- in
-etermining transaction types o, each use case/,unction 3in 'ine 0ith the Do/ernment Bore Po'icy
Manua'5 E
%evel & ' "nonymous transaction F triggers transactions that do not require or allo* a
person to +e identified/ or transactions *hich require protection of a personGs identit), Aor
e.ample/ access to online information a+out government programs or services or protecting
a personGs identit), Com+ining the transaction data *ith other data must not allo*
identification of a particular individual,
%evel ( ' !seudonymous transaction F triggers transactions that do not require a person to
+e identified +ut do require a means for further contact to deliver a product or service, Aor
e.ample/ a note from somepersonHinternet,ca can not +e readil) translated into an
individual=s name/ +ut it ma) +e sufficient to request information/ to provide some services/ or
onBgoing follo* up,
%evel ) ' Identified transaction F triggers transactions that require that a person +e
specificall) identified, -he nature of the transaction ma) require confirmation of a personGs
identit) 8e,g,/ name/ address/ +irth date/ etc,9 and/or data lin5ing the person to a transaction
8e,g,/ invoice num+er/ personal health num+er/ etc,9,
%evel * ' +erified transaction F triggers transactions that require the person to +e
specificall) identified@ verification of the integrit) of the data e.changed and the e.change
itself@ and/ the creation of sufficient evidence to indicate that the person agreed to +e +ound
+) the transaction, Aor e.ample/ a note signed *ith a digital certificate/ audit trails and
securit) logs ma) provide sufficient evidence that a specific person intended to conduct a
transaction,
'se ase 2 Business
;unction Name
Transaction type tri##ered
($e4el : : !nonymousC
$e4el ( : PseudonymousC
$e4el , : *dentifiedC
$e4el - : &erified)

0)(),) !ut+oriEation and !ccess ontrols
+his section -escri"es the Authori<ation an- Access Bontro' re.uirements part o, the #usiness
$e.uirements at a high'e/e'% Authori<ation is the process o, -etermining i, the person/group(
once i-enti,ie- through the =Authentication process>( is permitte- to ha/e access to certain
Last revised!"/#$/!#%& Page %D of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
ser/ices% +he Authori<ation an- Access Bontro' re.uirements are "est -escri"e- through a
matri2%
!ctor 2 Business
'nit Name
onceptual lass 2
Business <ntity Name
Type of !ccess ontrol
needed on t+e
onceptual lass 2
Business <ntity :
reate
R Read
' 'pdate
D Delete
0)()-) *nformation Security lassification and labellin#
+his section is pro/i-e- ,or in,ormation purposes on'y% P'ease -o not -e'ete this section 0hi'e
creating the #usiness re.uirements Document ,rom this temp'ate%
+he =:nformation securit) classification and la+eling o, in,ormation assets> is a process pu"'ishe-
an- manage- "y 9B79% Accor-ing to this process( a'' go/ernment =recor-s> as -e,ine- in the
7nterpretation Act nee- to "e c'assi,ie-% 3=recor-> inc'u-es "oo6s( -ocuments( maps( -ra0ings(
photographs( 'etters( /ouchers( papers an- any other thing on 0hich in,ormation is recor-e- or
store- "y any means 0hether graphic( e'ectronic( mechanica' or other0ise5%
+here are no "usiness re.uirements 3,unctiona' or non,unctiona' re.uirements5 app'ica"'e to the
:nformation securit) classification o, the app'ication/project/initiati/e ,or 0hich the #$D is "eing
0ritten% ;ence there is no nee- to ,i''in anything in this section%
;o0e/er( p'ease "e a0are that the ,inishe- app'ication/initiati/e/project an- a'' its output
-e'i/era"'es 3such as -ocuments( mo-e's( -iagrams etc5 nee- to "e c'assi,ie- an- 'a"e''e- in
accor-ance 0ith the 9B79 gui-e'ines% +his 0i'' he'p in -etermining ho0 much protection the
,inishe- app'ication an- its -ata 0i'' nee- commensurate 0ith its sensiti/ity 'e/e's -etermine-
-uring in,ormation security c'assi,ication process% 7t 0i'' a'so he'p in e/a'uation o, ris6s associate-
0ith authori<e- an- unauthori<e- -isc'osures o, the app'ication?s -ata%

Last revised!"/#$/!#%& Page %E of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
0),) !4ailability Requirements
+his section -escri"es the system a/ai'a"i'ity re.uirements%
Last revised!"/#$/!#%& Page !# of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
'se ase 2 Business
;unction Name
!4ailability Requirements
= Re#ular %or. +ours
= ,/86
= !ny ot+er (please describe)
0)-) 'sability Requirements
+his section -escri"es the system usa"i'ity re.uirements% A usa"i'ity re.uirement speci,ies ho0
easy the system must "e to use% 8sa"i'ity is a non,unctiona' re.uirement( "ecause in its essence
it -oesn't speci,y parts o, the system ,unctiona'ity( "ut speci,ies on'y ho0 that ,unctiona'ity is to "e
percei/e- "y the user( ,or instance ho0 easy it must "e to 'earn an- operate the system%
0)/) System Belp Requirements
+his section -escri"es 0hat 6in- o, System ;e'p ,eatures are nee-e- to "e "ui't into the system%
Last revised!"/#$/!#%& Page !% of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
'se ase 2 Business
;unction Name
Belp Requirements
= ;ield le4el (online)
= Screen le4el (online)
= Belp Printin# 3ptions
= 3perations "anual (3ffline)
= !ny ot+er (please describe)
0)0) Performance Requirements
+his section -escri"es system per,ormance e2pectation 'e/e's 3response times5%
'se ase Name 2 Business
;unction Name 2 Transaction
description
Performance Requirements
(response time)
(in seconds or minutes)
0)5) Scalability Requirements
+his section -escri"es ho0 the system is e2pecte- to sca'e to ne0 higher or 'o0er 'e/e's% #oth
user an- app'ication sca'a"i'ity re.uirements are -escri"e- here% Data scala+ilit) is not descri+ed
here as it is alread) descri+ed in the 0data volumes4 section earlier%
0)5)() 'ser Scalability
0)5),) !pplication Scalability
Last revised!"/#$/!#%& Page !! of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
5) *nterface Requirements
+his section -escri"es 8ser an- System 7nter,ace re.uirements ,or the propose- system%
5)() 'ser *nterface Requirements
5),) System *nterface Requirements
6) Business 1lossary
Last revised!"/#$/!#%& Page !& of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
!P"S 'pdate
APMS up-ate re.uire-F Ges No
APMS up-ate-/to "e up-ate- on 3-ate5E
BommentsE
Re4ision $o#
Date +ersion $hange ,eference ,eviewed by
[-ate]
!ppendices
:nter content here%
Last revised!"/#$/!#%& Page !$ of !'
(ecurit) Classification Lo*
Business Requirements Document Project Name
!ppro4al
+his -ocument has "een appro/e- as the o,,icia' #usiness $e.uirements Document ,or
the Project Name project%
4o''o0ing appro/a' o, this -ocument( changes 0i'' "e go/erne- "y the project?s change
management process( inc'u-ing impact ana'ysis( appropriate re/ie0s an- appro/a's(
un-er the genera' contro' o, the Master Project P'an an- accor-ing to Project Support
9,,ice po'icy%
!repared by -ignature Date
Author's Name
[+it'e]
[9rgani<ation]

"pproved by -ignature Date
[B'ient Acceptor?s Name]
[+it'e]
[9rgani<ation]

Last revised!"/#$/!#%& Page !' of !'
(ecurit) Classification Lo*