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: Prepared for: Date Submitted: Project Sponsor: lient !cceptor: Project "ana#er:

Author's Name [Date] Project Sponsor's Name

Document Number: 6450 !0/Project Num"er /#$D Security lassification: $o% &ersion: 0%& $ast 'pdated: reation Date: Apri' !6( !0&) *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....................................................................................................................................... 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.Authori ation 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

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 (ho $houl! )e #n*ol*e! in the Creation of the )RD+.........................................................................26 ,rere-uisites for )RD...........................................................................................................................26 .*erall ,ro/ect Details an! )est ,ractices..........................................................................................27 )est ,ractices.......................................................................................................................................27 ,ac0aging the )RD...............................................................................................................................27 )usiness ,artner $ign1off.....................................................................................................................2" A!!itional Details.................................................................................................................................2" Data to %e 2el!3 $ample A!*ice...........................................................................................................2& $ummary...............................................................................................................................................2&

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'ogy in-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 applicable.]

(),) *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'ogy in-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 enable hidden te!t" under the # ools $ %ptions $ &ie'( tab" ma)e sure that *+idden e!t* is chec)ed. o print the template 'ith hidden te!t displa,ed" under the # ools $ %ptions $ Print( tab" ma)e sure that *+idden e!t* is chec)ed. he te!t in black colour is meant to be 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 -arious sections of this document. Please fill in the sections as per instructions and then delete the red coloured te!t .instructions and e!amples/. Please do not lea-e an, section blan). 0f a section is not applicable" then t,pe in #Not 1pplicable( in that section. Please ensure not to describe 2,stem Design issues in this document.

Business Requirements Document

Project Name

Currentl, t'o approaches to modeling the Business Requirements are supported b, 3inistr,4s 1D5 standards 6 738 7se case modeling using an, tool that supports the 738 notation and standards as described in the 1D5 standards 'eb site 9 5ntit, Relationship Diagram .5RD/ and :unction +ierarch, Diagram .:+D/ modeling using %racle Designer tool.

his document template supports both 7se case and Designer modeling approaches. 0t is highl, recommended that onl, one of the t'o modeling approaches is adopted for describing the Business Requirements in this document and not a h,brid approach. Data models ma, be presented either in 5RD notation or in 738 class notation" regardless of 'hich modeling approach 'as used. 1ll 3odeling should conform to 3inistr,4s 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. 1fter finishing the document" please re;generate the complete able of Contents to reflect the correct page numbering. .2elect the able of contents9 right;clic)9 select #update fields( and select #update entire table( commands./

()-) 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%

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%

Business Requirements Document ()(:) !ssumptions

Project Name

+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%

Business Requirements Document ,)() *n Scope

Project Name

,),) 3ut of Scope

-) ;unctional Requirements
+his section -escri"es the :unctional requirements part o, the #usiness $e.uirements% 7n 8se case approach( the :unctional 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 :unctional 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%

Business Requirements Document

Project Name

A !"# N$%&

!ctor Type

!ccess Type needed

omments

S&'()*+,-). P./0'.1 A2&+. S344+.&/56 A2&+. S&'()*+,-). P./0'.1 A2&+. S344+.&/56 A2&+. S&'()*+,-). P./0'.1 A2&+. S344+.&/56 A2&+. S&'()*+,-). P./0'.1 A2&+. S344+.&/56 A2&+.

C.)'&) R)'U4-'&) D),)&) C.)'&) R)'U4-'&) D),)&) C.)'&) R)'U4-'&) D),)&) C.)'&) R)'U4-'&) D),)&)

P./5& E74+.& O&*).8 P./5& E74+.& O&*).8 P./5& E74+.& O&*).8 P./5& E74+.& O&*).8

-),) <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 start to ,inish path that the use case 0i'' ,o''o0( 0here as the a'ternate courses represent the in,re.uent'y use- paths ane2ceptions( error con-itions etc% +he comp'ete "usiness 'ogic o, a use case such as "asic course o, action( a'ternate course o, action( pre con-ition( post con-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

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%

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% !lternate ;lo%s

Basic ;lo%

Non=;unctional Requirements Pre= onditions Post= onditions <8tension Points $ist of >>included?? use cases <8tension ondition $ist of >>e8tended?? use cases <8tendin# 'se ase

$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

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%

Business Requirements Document

Project Name

Business Rule *d

Rule Name

Rule Description

Rule Source Po 'icy manua' Str ategic -ecisions Bo ntractua' o"'igations Su "ject matter e2perts 9t her Sources 3mention the sources5

#$AAAA

/) 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 anoperations 3metho-s5 an- a'so the interre'ationships 3association( composition( aggregation angenera'i<ation5 "et0een the c'asses% Domain mo-e' is a representation o, rea' 0or'- conceptua' c'asses( not o, so,t0are components%

Business Requirements Document

Project Name

/)(),) <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'eusing :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 usein -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 reasonabl, be e!pected to cause injur, .harm/ if released to the public9

Business Requirements Document

Project Name

!rotected "6 information that" if compromised" could reasonabl, be e!pected to cause injur, .harm/" e.g. loss of pri-ac,9 !rotected #6 information that" if compromised" could reasonabl, be e!pected to cause serious injur, .harm/" e.g. the conduct of a court proceeding 'ould be ad-ersel, affected9 !rotected $6 information that" if compromised" could reasonabl, be e!pected to cause e!tremel, gra-e injur, .harm/" e.g. loss of life.

onceptual Name

lass 2 <ntity

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%

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%

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

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 < triggers transactions that do not require or allo' a person to be identified" or transactions 'hich require protection of a person=s identit,. :or e!ample" access to online information about go-ernment programs or ser-ices or protecting a person=s identit,. Combining the transaction data 'ith other data must not allo' identification of a particular indi-idual. %evel ( ' !seudonymous transaction < triggers transactions that do not require a person to be identified but do require a means for further contact to deli-er a product or ser-ice. :or e!ample" a note from someperson>internet.ca can not be readil, translated into an indi-idual4s name" but it ma, be sufficient to request information" to pro-ide some ser-ices" or on;going follo' up. %evel ) ' Identified transaction < triggers transactions that require that a person be specificall, identified. he nature of the transaction ma, require confirmation of a person=s identit, .e.g." name" address" birth date" etc./ and/or data lin)ing the person to a transaction .e.g." in-oice number" personal health number" etc./. %evel * ' +erified transaction < triggers transactions that require6 the person to be specificall, identified9 -erification of the integrit, of the data e!changed and the e!change itself9 and" the creation of sufficient e-idence to indicate that the person agreed to be bound b, the transaction. :or e!ample" a note signed 'ith a digital certificate" audit trails and securit, logs ma, pro-ide sufficient e-idence 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

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 =0nformation securit, classification and labeling o, in,ormation assets> is a process pu"'ishean- 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 0nformation 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 associate0ith authori<e- an- unauthori<e- -isc'osures o, the app'ication?s -ata%

Business Requirements Document 0),) !4ailability Requirements

+his section -escri"es the system a/ai'a"i'ity re.uirements%

Project Name

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%

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 scalabilit, is not described here as it is alread, described in the #data -olumes( section earlier %

0)5)() 'ser Scalability

0)5),) !pplication Scalability

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

Business Requirements Document

Project Name

!P"S 'pdate
APMS up-ate re.uire-F APMS up-ate-/to "e up-ate- on 3-ate5E BommentsE Ges No

Re4ision $o#
Date [-ate] +ersion $hange ,eference ,eviewed by

!ppendices

:nter content here%

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
Author's Name [+it'e] [9rgani<ation]

-ignature

Date

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

-ignature

Date

Business Requirements Document

Project Name

WhoShouldBe Involvedin the Creationof the BRD?

A number of teams and partners should create the BRD:

Project core team Business partner(s) Process owner(s) or representatives Subject matter experts Change/project/product management, quality department and/or IT management as needed or available

Prerequisitesfor BRD
Prerequisite one for a BRD is the project charter, created during the define phase of a DMAIC project. The BRD provides the opportunity to review the project charter to ensure that the objective, goals, scope, project team, and approvers are accurately reflected. Prerequisite two is a current environment assessment created during the measure phase. This includes a detailed process map of the current environment highlighting areas that will be changed during the project. Detailed as is process maps should include:

Clearly defined start and end points of the process Level two and three process functions Defined areas of rework and non-value added steps Cycle time, capacity and rework information for each process step as available Baseline for each CTQ for the current environment Prerequisite three is CTQs, identified in either the define or measure phases, and validated with baseline measurements, targets and specifications.

Current measures: Data that defines and describes current performance sigma level of the CTQ includes a definition of how the product/services characteristic is to be quantified. Target/nominal value: What is the aim of the product/service? If there was never any variation in the product/service, this would be the constant value. Specification limits: How much variation is the customer willing to tolerate in the delivery of the product or service? Define upper and lower specification limits as required by the customer needs. Allowable defect rate: How often are the producers willing to produce a product/service outside the specification limits? Prerequisite four is the target environment assessment, created in the measure phase, and includes a detailed process map of the target environment including level two functions. When distinguishing between level two or three functions, group the process functions into the following categories:

People: People are processing information and making decisions [core team designs high-level design/low-level design (HLD/LLD)] Systems: Systems is processing information and making decisions Systems/people: System is processing information and people are making the decisions

Business Requirements Document

o o
be moved up Distinguish between employee and customer

Project Name

Distinguish leadership requirement for associate in case decision making authority has to Fishbone: For each process function for impact assessment

Overall ProjectDetailsand Best Practices

The BRD appendix can be used to list a number of project details constraints, assumptions and dependencies, business rules, scope, measurements reporting and other topics critical to the project. Consider the following issues when looking at the overall project:

Are there any regulatory or geographic constraints (i.e., state law) to consider? If so, these constraints need to be clearly documented in the process detail table of the BRD or in the overall project details section of the appendix.

What assumptions or dependencies apply? What business rules apply? Are there any measurements or reporting requirements that apply to the project?

BestPractices
1. Validate scope: review and refine the scope as needed based on a process detail table, identifying any changes to what is in or out of scope now that the requirements have been developed. Complete this prior to obtaining the business partner(s) sign-off and lock down the scope of the project. Any changes to the project after this phase will be handled through a change control process. 2. Create systems impacted document: Create a design-elements diagram for each level two or three process function for impact assessment for: People Process Technology Materials and supplies Facilities Product Machinery and equipment Others as necessary (depending on the organization) Definitions and acronyms: Define any terms not clearly understood by all.

o o o o o o o o
3.

Packagingthe BRD
Package the BRD so it has a logical flow and is easy to follow. An example of a high-level list of sections follows:

Project overview including project charter information, scope, and objectives Current environment assessment and systems overview (see additional details below) Future process map Process detail table Overall project business rules and constraints Impact assessment (fishbone for process functions)

Business Requirements Document

Functional requirements (additional details below) Data to be held (additional detail available below) Schedule and budget Terms and definitions Approver information Team information

Project Name

BusinessPartnerSignoff
Business partners should be active participants in the development of the BRD, but a final review and signoff is also essential.

AdditionalDetails
There are a number of items included in the BRD that require detailed documentation to ensure successful implementation. Following is a high-level overview of the types of detail to consider: Sample questions for the current environment assessment and systems overview:

Who is the intended user? How many users are there? Are they the same type of user or different? What level of computer experience will the users have (or is needed)? What is the required security? Are there hardware constraints networked or stand-alone? What are the approximate numbers of records required initially plus the anticipated growth? What technical support is necessary and available in-house? What other systems need to integrate/communicate? Backup. Describe the current back-up regime (e.g., tape back-up one/day). How will the new system fit with this? If this is not currently defined then think how much data could be inadvertently lost. For example would it be a major disaster if the last 30 minutes of work was lost, or could yesterdays/last weeks data be retained?

Deliverables. What are the expectations system, help files, documentation, full source code, training, support, etc.? Detail what is essential versus nice. Do not automatically ask for everything unless necessary. If the project manager is to maintain the system make sure he states that he requires the full source code alternatively if the developer is to maintain the system consider settling for an escrow agreement (where the source is held by an independent third party). Be specific about tools necessary to help. If the developer is unwilling to provide the support necessary find someone else who will. The functional requirements section should describe what the system is to accomplish rather than the how. Develop a prioritized list similar to the following:

A detailed description of the requirement including goals (e.g., produce a report of spend/department/year on demand with the user selecting the department and the financial year required), it is necessary to know how the company defines the financial year.

How important is this requirement (essential, preferred, nice to have, not essential, etc.)? Any known design/implementation issues relating to this requirement?

Business Requirements Document

Does this requirement interact with other requirements?

Project Name

Datato be Held: SampleAdvice

Describe expected data tables. Examples include customer records, contact details, machine records, etc. Provide as much detail as possible a customer record might consist of a name, address, telephone number, fax, mobile number, region, business type, number of employees etc. Indicate any unique fields (such as a job number) and show how different tables relate to each other (very important). For example projects are related to customers through a customer number. Each customer can have none, one or many associated projects. Each project relates to one or more jobs. A job can exist independently of a project but will still be associated with a customer. A project will always have only one customer. It is not usually necessary to define the tables in database terms (e.g., customer number is a long integer) but examples of the data to be held in the fields is useful (e.g., a typical job number might be FH/1234 where FH indicates the department undertaking the job and 1234 is a unique number. In practice a good database designer would then recognize that the real job number is actually the 1234 part and the FH is just an associated field). If the maximum size of any field is known for example, a Company Name field is 100 characters then include this. If there are any table definitions from existing systems then provide these indicating any required changes.

Summary
As with any tool, the BRD can have both benefits and failure modes. Benefits derived from a good BRD include reduced changes during the improve and control phases of DMAIC and reduced time to deployment. Failure modes from a poor BRD means the system developed will not meet business requirements. Creating a successful BRD requires planning and coordination. There are a few best practices that should be followed in this process. The team should hold a dedicated off-site session to complete the BRD with all required resources 100 percent available. Scheduling is the key to success here. As each tool/deliverable is completed within the methodology build the BRD. Allow a one-week deadline to finish action items from the off-site session and hold a final review session two to three hours after completion of action items.