Requirment Spec

7/21/2019 Requirment Spec

http://slidepdf.com/reader/full/requirment-spec 1/32

Requirements Specification for <project name>

Target Technology Services

Requirements Specification –Scenario Based

for

Call Center Example

Created by:[Author Name]

Clarity roject ! [Number]

"able of Contentsa#e $ of %& 'ersion <()(>




Chan#e *istory)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) %"o use this template:)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) %$) +ntroduction))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))),

$)$) urpose of this Requirements Specification))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))),$)&) roblem Statement or -usiness .pportunity))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) ,

$)%) References)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) ,$),) /ey Contributors)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))),$)0) .pen +ssues))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) 0

&) 1oals and -usiness .bjecti2es)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))3%) Constraints and Assumptions))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))4,) Scenario))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))40) 5ser Classes and Characteristics))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) 63) Scenario and 5ser 7odel))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))64) Scenario rocess 8ia#ram))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) 96) unctional Requirements)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) $(9) Non;unctional Requirements)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))$3

$() +nformation Sources)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) $9$()$) +nternal +nformation Sources))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))$9$()&) =ternal +nformation Sources)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))$9

$$) Appro2al Si#nature a#e)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))&($&) +nstructions and 1uidelines))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) &$ A) 1eneral 1uidelines for usin# this template:)))))))) )))))))))) )))))))))) )))))))))) )))))))))) )))))))))) )))))))))) )))))))))) )))))))))) ))))))) )))))) )))))) )))))) )))))) ))&$-) Requirements *ierarchy))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))&&C) Specific Section +nstructions:)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))&%"emplate Chan#e *istory))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) %(

a#e & of %& 'ersion <()(>




Change History

"his document is located in <add document location>

Instructions for completing this template are included following the appendix. Click on a section title for instructions.

"his document as based on Requirements Specification ? Scenario -ased "emplate 2ersion ,)( effecti2e @une &((6)

"he folloin# important chan#es ha2e been made to this document:

Version ate !repared "y Comments

#$% &&''(((()uthor *nitial raft

To use this template+

• In the first line of the Change History, enter the location of your project document.

•

Add your project name on the title page and in the document header.• Add your document ersion num!er on the title page and in document footer.

• "se the Change History ta!le for changes to your document.

• #elete these instructions when you are done referring to them.

• #o not delete sections of the template. Indicate $A in the section if it is not applica!le to your

project.

• "pdate the %a!le of Contents of the document !y selecting it and then pressing the &' function

key.

• (pecific instructions for each topic are included in the Appendix of this template.

a#e % of %& 'ersion <()(>




#$ *ntroduction

1.1. Purpose of this Requirements Specification

"he purpose of this document is to clearly define the business functional and non;functional requirements of the project to#ain a#reement beteen the technical project team and the business clients on the requirements of this project and topro2ide direction for the technical project team in the desi#n construction and testin# of a solution) "he intended audience ofthis document is the project business clientBs and the technical project team)

1.2. Problem Statement or Business Opportunity

)roide a !rief description of the pro!lem !eing remedied !y this project, or the !usiness opportunity !eing ena!led !y this project. %he*usiness )erformance +pportunity from the )roject #efinition may proide this information and if so, can !e used for this section.

Currently no information is retained about customers callin# into the Call Center) "here is an opportunity to de2elop betterrelationships ith these customers by #atherin# information about these customers and #atherin# information about theefficiency of the call reps that handle the calls)

1.3. References

References ,ocation

roject 8efinition See roject ortal

1.4. Key Contributors

-ame Title.Role

SuDy Eue -A

a#e , of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23References

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23KeyContributors

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23References

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23KeyContributors




*erachio Smith -C

1.. Open !ssues

/ Entered "y ate Status escription

$ SuDy Eue $F$F(6 .pen Need to clarify if there are any other pieces of information that need to be captured for eachcustomer)

a#e 0 of %& 'ersion <()(>




0$ 1oals and Business 2"3ectives

8ocument the #oals and objecti2es from the roject 8efinition documentation) Assi#n unique ids to each #oal and objecti2e)

1oal ! 1oalsBs1oal;$ +mpro2e relationship ith Call Center

Customers

-us .bj ! Reference .bjecti2es.-@;$ 1oal;$ 1ather information about each customer that

calls into the call center .-@;& 1oal;$ +mpro2e efficiency of call center reps to better ser2e the customer





4$ Constraints and )ssumptions#ocument the glo!al constraints and assumptions that are related to the reuirements in this document. (pecific constraints andassumptions that are related to an indiidual reuirement are documented in the functional or non-functional reuirement ta!le.

Constraints and Assumptions +8

8escription

CA;$)( "he system ill not ha2e a batch processin# indo and ill need to ha2e a2ailable real;time information)

CA;$)$"he system does not need to capture information on corporate customers

5$ Scenario(cenarios are processes that actorsusers follow to accomplish tasks. )roject scenarios are those that tie directly to the project/so!jecties. *elow, list all new scenarios that may !e supported in this release and any scenario that the system currently supports that will !e altered in this release.

Include a er!noun com!ination that indicates the useractor0s1 interaction with the system.

/ 6sers7s8 9ho doscenario

Scenario -ame escription -e9: *nScope:

!riority

SCN;$ 5SR;$5SR;&

Go# Customer+nformation

Go# information from customer calls comin# intothe call center

Hes Hes *

SCN;& 5SR;& 'ie eeIlyacti2ity

Re2ie eeIly acti2ity data for call repsassi#ned to their department)

Hes Hes 7


http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23ScenarioInstruction

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23ScenarioInstruction




;$ 6ser Classes and Characteristics

/ 6ser.)ctor 6sage.Role <hat=s important to them:5SR;$ Call Rep Ansers calls from customers and enters

customer information into system durin# thecall)

Speed efficiency

5SR;& Customer ser2ice m#r 7ana#es eeIly acti2ity for Call Reps intheir department)

Accuracy

>$ Scenario and 6ser &odel#iagram0s1 of actor interactions with tasks and system0s1 appear here.


http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23UserClasses

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23ScenarioUserModelInstruction

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23UserClasses

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23ScenarioUserModelInstruction




?$ Scenario !rocess iagram

%his is a diagram of each scenario and the associated high-leel reuirements. %his should not get too detailed and shouldconcentrate on the high-leel to assist in defining the scenario scope. If applica!le, show the oerlaps and interactions !etweenthe scenarios.

SCN;$ Go# Customer +nfo SCN;& 'ie JeeIly Acti2ity





@$ Aunctional Requirements

%his ta!le should !e used to document !oth high leel and detail functional reuirements and !usiness rules. %he reuirements should !eorgani2ed !y scenario. "se the reference column to refer to other reuirements, !usiness rules, or o!jecties as appropriate. In addition, use the&unctional (pecification &low column to reference specific flows in the &unctional (pecification where the reuirement is !eing met. In mostcases flows would !e mapped to high-leel reuirements

a#e $( of %& 'ersion <()(>




+8! .bjecti2eF

Reference

ReqSourc

e

8escription .ner

+nScope

K

Release F

+teration

riority

Constraints and

Assumptions

+8 F Notes

unc)Spec lo

SC-'# .-@;$ @ane8oe

,og Customer*nformation

Hes & * CA;$)$

RE($)$.-@;$ @ane

8oe Ability to search fore=istin# customerinformation

Hes&

* G;$)$

8"($)$)$

.-@;$ @ane8oe

Ability to searchfor customer bylast name

Hes&

7

8"($)$

)&

.-@;$ @ane8oe

Ability to search

for customer bystate

Hes&

*Consider

usin# &letter dropdon bo=

8"($)$)%

.-@;$ @ane8oe

Ability to displayan error messa#eif customer is notfound

Hes&

* G;$)0

R5G($)$.-@;$ @ane

8oe A ildcard searchmust be a2ailablefor all searchcriteria

Hes&

*

RE($)&.-@;$ @ane

8oe Ability to add a necustomer

Hes&

7 G;$)&

8"($)&)$

.-@;$ @ane8oe

Ability to entercustomer lastname

Hes&

*

R5G($)&)$

.-@;$ @ane8oe

All customersmust ha2e a lastname and state

Hes&

* G;$),

a#e $$ of %& 'ersion <()(>




+8! .bjecti2eF

Reference

ReqSourc

e

8escription .ner

+nScope

K

Release F

+teration

riority

Constraints and

Assumptions

+8 F Notes

unc)Spec lo

8"($)&)&

.-@;$ @ane8oe

Ability to entercustomer firstname

Hes & 7

8"($)&)%

.-@;$ @ane8oe

Ability to entercustomer phonenumber

Hes&

*

RE($)%.-@;$ @ane

8oe Ability to 2erifycustomer information

Hes&

* G;$)%

8"($)%

)$

.-@;$ @ane8oe

Ability to 2erify

customer lastname

Hes&

7

8"($)%)&

.-@;$ @ane8oe

Ability to 2erifycustomer firstname

Hes&

*

8"($)%)%

.-@;$ @ane8oe

Ability to 2erifycustomer phonenumber

Hes&

*

8"($)%),

.-@;$ @ane8oe

Ability to indicatethat customer info

as 2erified

Hes&

7

8"($)%)0

.-@;$ @ane8oe

Ability to capturedate customer infoas last 2erified

Hes&

7

R5G($)%)0

.-@;$ @ane8oe

+f any customerinfo is chan#edupdate the datelast 2erified to datechan#e as made

Hes&

7

a#e $& of %& 'ersion <()(>




+8! .bjecti2eF

Reference

ReqSourc

e

8escription .ner

+nScope

K

Release F

+teration

riority

Constraints and

Assumptions

+8 F Notes

unc)Spec lo

8"($)%)3

.-@;$ @ane8oe

Ability to capturecall rep that last2erified customerinfo

Hes & 7

R5G($)%)3

.-@;$ @ane8oe

+f any customerinfo is chan#edupdate the call repthat last 2erifiedith the call repthat chan#ed thecustomer info

Hes&

7

RE($),.-@;$ @ane

8oe Ability to updatecustomer information

Hes&

* G;$)%

8"($),)$

.-@;$ @ane8oe

Ability to updatecustomer lastname

Hes&

*

8"($),)&

.-@;$ @ane8oe

Ability to updatecustomer firstname

Hes&

7

8"($),)%

.-@;$ @ane

8oe Ability to updatecustomer phonenumber

Hes&

*

8"($),),

.-@;$ @ane8oe

Ability to cancelupdate

Hes&

*

RE($)0.-@;& @ane

8oe Ability to tracI callduration

Hes&

* G;$)&G;$)%

8"($)0)$

.-@;& @ane8oe

Ability to tracI callbe#in time

Hes&

*

a#e $% of %& 'ersion <()(>




+8! .bjecti2eF

Reference

ReqSourc

e

8escription .ner

+nScope

K

Release F

+teration

riority

Constraints and

Assumptions

+8 F Notes

unc)Spec lo

8"($)0)&

.-@;& @ane8oe

Ability to tracI callend time

Hes & *

RE($)3.-@;& @ane

8oe Ability to tracI call repinfo

Hes&

* G;$)$

8"($)3)$

.-@;& @ane8oe

Ability to tracI callrep +8

Hes&

*

8"($)3)&

.-@;& @ane8oe

Ability to tracI callrep name

Hes&

*

8"($)3)%

.-@;& @ane

8oe Ability to tracI callrep location

Hes

&

*

SC-'0.-@;& @ane

8oeVie9 <eely )ctivity

Hes&

7

RE(&)$.-@;& @ane

8oe Ability to display eeIlycall rep acti2ity

Hes&

7 G;&)$

8"(&)$)$

.-@;& @ane8oe

Ability to displaythe number ofphone callsrecei2ed by eachcall rep

Hes&

7

8"(&)$)&

.-@;& @ane8oe

Ability to displaythe a2era#e len#thof phone calls foreach call rep

Hes&

7

RE(&)&.-@;& @ane

8oe Ability to select displayparameters

Hes&

7 G;&)$

a#e $, of %& 'ersion <()(>




+8! .bjecti2eF

Reference

ReqSourc

e

8escription .ner

+nScope

K

Release F

+teration

riority

Constraints and

Assumptions

+8 F Notes

unc)Spec lo

8"(&)&)$

.-@;& @ane8oe

Ability to selectdepartment

Hes & 7

8"(&)&)&

.-@;& @ane8oe

Ability to selectany eeI ithinthe last $% eeIs

Hes&

7

8"(&)&)%

.-@;& @ane8oe

Ability to select acall rep

Hes&

7

RE(&)%.-@;& @ane

8oe Ability to sort eeIlyacti2ity

Hes&

7 G;&)&

8"(&)%)$

.-@;& @oeSmith

Ability to sort bydepartment

Hes & 7

8"(&)%)&

.-@;& @oeSmith

Ability to sort byeeI

Hes&

7

8"(&)%)%

.-@;& @oeSmith

Ability to sort bycall rep

Hes&

7

RE(&),.-@;& @oe

Smith Ability to print eeIlyacti2ities

Hes&

7 G;&)%

a#e $0 of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23Iteration











$ -on'Aunctional Requirements8ocument belo any non;functional requirements that need to be considered for this system de2elopment project) 8efinitions for eacharea are articulated in the LinstructionsM of this document and additional #uidance can be referenced in the Non;unctional Requirements@ob Aid)

Note: -ased on the results of the Security Requirements Euestionnaire you may need to en#a#e ith Security)Consultin#"ar#et)com for special consultation) Security requirements should come from the completed Non;unctional Security Requirements deli2erableassociated ith your project)

Type +8 ! .bjecti2eFReferenc

e

Source

8escription .ner

+nScope

K

Release F

+teration

riority

Constraintsand

Assumptions

+8 F Notes

A2ailabilit

y

A'G;

$)(

@ane

8oe

OA7G: "he application ill

need to be a2ailable as needed inthe normal course of businessoperations B96P a2ailability notincludin# planned maintenanceouta#es hich is the equi2alent ofappro=imately % hours of unplanneddontime per eeI

@ohn

Smith

Hes $ *

Reco2er ability

RC;$)(

Supportability

S5;$)(

CapacityFScalability

CA;$)(

a#e $3 of %& 'ersion <()(>

http://insidetgt.target.com/content?contentid=PRD01-103617


http://teams.target.com/infosec/consulting/SRQ/Forms/template.xsn


mailto:[email protected]













e

Source

8escription .ner

+nScope

K

Release F

+teration

riority

Constraintsand

Assumptions

+8 F Notes

erformance

R;$)(

SCN;$

Screens used to tracI customerinformation must display ithin 0seconds 90P of the time

Hes $ *

R;&)(

SCN;&

Screens used to 2ie eeIlyacti2ity must display ithin $0seconds 90P of the time

Hes $ *

R;%)(

SCN;&

+f user selects a ne sort order itmust complete ithin $0 seconds90P of the time

Hes $ *

Security SC;$)(

SCN;&

Access to the 'ie JeeIly Acti2itymust be limited to Customer

Ser2ice 7ana#ers)

Hes $ *

+nter;App+nterfaces

+A+;$)(

7onitorin#

7.N;$)(

8ata+nte#rity

+N";$)(

a#e $4 of %& 'ersion <()(>





e

Source

8escription .ner

+nScope

K

Release F

+teration

riority

Constraintsand

Assumptions

+8 F Notes

8ataRetention

R";$)(

Note: "ar#etQs Record Retentionolicy is a2ailable on;line andpro2ides information about holon# each type of record is to beIept Bretention period and hat isto happen to the record at the endof that period Bdestruction)Consider requirements for dataretention data pur#e and dataarchi2e)

n2ironment

N';$)(

Note: System components shouldbe identified throu#h the R+process to ensure that the solutionis in ali#nment ith "ar#et standardsolutions)

"rainin#F8ocumentation

"RN;$)(

a#e $6 of %& 'ersion <()(>
















#%$ *nformation Sources

1".1. !nternal !nformation Sources

3ist and descri!e the logical data groups that are entirely under control of the application.

1".2. #$ternal !nformation Sources3ist and descri!e the logical data groups that are used or referenced !y this application !ut are maintained under control of anotherapplication.

##$ Requirements Specification )pproval Signatures"his project ill follo the Appro2al Si#nature Retention rocedure) lectronic appro2als ill contain the elivera"le -ameD Version-um"erD Clarity * and Clarity !ro3ect -ame in the "S8 JorIflo Appro2al messa#e bo= or the e;mail subject line) "he file location for any physical si#natures is documented in the =ternal Reference section of the "S8 roject ortal)

8eli2erable Name:

'ersion Number:

Clarity +8:

Clarity roject Name:

Title )pprover -ame !hysical Signature or ,ocation of Electronic )pproval ate

TTS &anager

B6C or B!C or Business&anager

a#e $9 of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23Sources

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23ApprovalInstruction


http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23Sources

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23ApprovalInstruction





%ote& 'n asteris( )*+ i,entifies a si-nature that is require, for S/. ',,itional si-natures may be a,,e,.

a#e &( of %& 'ersion <()(>




#0$ *nstructions and 1uidelines

)$ 1eneral 1uidelines for using this template+

•%his template may !e used for !oth internally deeloped software projects or for third party package implementation projects.

#eelopment teams who are following %%( software deelopment processes to implement third party package software

should use this template to document their reuirements. (pecial instructions for using this template for packageimplementations are included in red text. Any reuirements for customi2ation or deelopment of code for interfaces or otherreasons should !e identified in this document4. %he intent of this document is not to duplicate endor software documentation!ut rather to descri!e how the software will !e used in at %arget. 5endor documentation should !e identified in the 6eferencessection. %his document should !e started as !usiness reuirements are identified prior to selecting endor software.#etermining reuirements is often an iteratie process that inoles gathering initial reuirements, inestigating potentialendor solutions, ealuating those potential solutions against the reuirements and other !usiness ualifications, and thenanaly2ing the gap !etween stated reuirements and aaila!le endor solutions. As gaps are identified, the reuirements may!e dropped from the project scope, implemented using %%(-deeloped or other endor software, or saed for a future release.%he 5endor 7aluation 8atrix is a useful tool for ealuating potential endor software and recording the gap analysis. *e sureto inole 5endor 8anagement in deeloping a 6euest for )roposal 06&)1 and in negotiating endor contracts and license

agreements.

• &or additional information on gathering, analy2ing, documenting and managing project reuirements, see the Requirements

0ana-ement Process, Requirements atherin- Plan and Requirements atherin- echniques.

• *e sure to analy2e existing system functionality, !usiness processes, data flows, interfaces, user interfaces, jo! flows and !usiness

rules to identify reuirements that the !usiness client may not know a!out or may assume that they/ll hae with the new system.

• A Requirements raceability 0atri$ is aaila!le for project teams to use in tracing their reuirements from analysis through design

and coding. 6euirements are traced to test using either 9uality Center or the Requirements raceability 0atri$ .

• %his template is intended to !e used with a unctional Specification /ocument . %he 6euirements (pecification template

documents the :what; of the project from the perspectie of the users or clients. %he &unctional (pecification document !egins toexplain :how; the scenarios and reuirements will !e met.

• %he 6euirements (pecification and the &unctional (pecification are intended to !e inputs to the S/ /esi-n ,ocumentation. %he

#esign documents descri!e in further detail :how; the system will technically meet all the reuirements.

• %ypically you will iterate through the reuirements specification and functional specification seeral times, each time further refining and

detailing the reuirements as more information is uncoered. Include any constraints and assumptions as you document thereuirements.

a#e &$ of %& 'ersion <()(>











http://insidetgt.target.com/content?contentid=WCMP01-044491






http://insidetgt.target.com/content?contentid=WCMP01-044491




• %his template is designed to look at reuirements from different points of iew textual functional and non-functional reuirements, use

cases, process maps, user interface, and data reuirements. It is recommended and encouraged that you use different methods ofidentifying and documenting reuirements in order to get a complete understanding of the project reuirements.

• Consider off-shore system utili2ation when discussing operations with the *usiness clients.

• Add any regulatory related reuirements 0HI)AA, (+=, )CI, etc1 that are appropriate for the project.

a#e && of %& 'ersion <()(>




B$ Requirements Hierarchy

Business 1oals

o Specific measurable impro2ements

o 8efine the HQs of the project

o =: L-etter import allocations ill reduce by ) percent)M

Business 2"3ectives

o Specific measurable impro2ements that help to further define the #oals)

o 8efine the OQs of the project

o roject 8efinition "oll#ate typically occurs ith this le2el of detail

o =: LNumber of allocations tracIed at the item le2elM

Scenario

o *i#h le2el user acti2ities

o Should include hich users are in2ol2ed in the acti2ities

o =: Llace Split urchase .rderM

Business Rules

o olicies and practices that #uide day;to;day business decisions

o Constraints facts etc that are true o2er time

o =: L+mport allocation is defined as L

Aunctional Requirements 7 High level 8

o *as been referred to as -usiness Requirements

o 8escribes LJhat abilityM or LJhat featureFfunctionM is needed

o Should not be able to rite a desi#n document from this le2el of detail

o Contains System requirementsT may contain process information

o =: "he ability to tracI import allocations at the item le2el is required)

o =: L"he system shallMT alternati2ely utiliDe use case format

Aunctional Requirements 7 etail 8

o *elps further describe and clarify hi#h;le2el unctional Requirements

o =) 5ser entry of folloin# attributes needed to tracI items)))

o Requirements appro2al occurs ith this le2el of detail

o Requirements +nspection occurs ith this le2el of detail

o Analysis toll#ate typically ith this le2el of detail completed

-on'Aunctional Requirements

o

Requirements that can not be met by a specific function of the applicationo +ncludes infrastructure related abilities Bcapacity security reco2ery etc

o 8escribes the le2el to hich the system is to perform the ability

o "hese are often referred to as LstructuralM requirements because they describe ho ell built and LsturdyM the product

should be)o =: L"he system uptime required is 96PM

Aunctional Specification

o +s used ith the detailed requirements in the Requirements Specification to rite desi#n documents

o +ncludes ireframes and ireframe flos to pro2ide 2isual details of the requirements

o ro2ides further details for e=ceptions noted in the Requirement Specification such as details about error messa#es

esign *tems

o 8ocumented in the 8esi#n 8ocument

a#e &% of %& 'ersion <()(>

roject8efinition

Analysis

8esi#n




o 8escribes L*o toM implement the featureFfunction

o Should be able to rite a pro#rammers spec from this le2el of detail Bif needed

o =: Column names to add to the import allocation table

o 8esi#n +nspection typically occurs ith this le2el of detail

o 8esi#n "oll#ate typically occurs ith this le2el of detail completed

C$ Specific Section *nstructions+

1.2 Problem Statement or Business Opportunity& #escri!e the pro!lem that will !e fixed !y implementing this project or the!usiness opportunity that will !e ena!led !y this project. %his section is intended to help readers understand the context of this project.

1.3 References& &ill in the )roject #efinition reference as indicated. Include references to procedures, standards, or other releantdocuments related to this reuirements specification. Include title, author, and location 0pathname1 of the reference. Include ersionnum!er only if necessary. ou may also include a list of any other related projects that may hae an impact on this project/s reuirements.&or enhancement projects, include a reference to existing system documentation such as the current reuirements specification.

1.4 Key contributors 3ist people who helped create this document and who could !e contacted in the future with uestions a!outthe document.

1. !ssues #ocument any open issues or uestions related to this document.

0$% 1oals and Business 2"3ectives ? #ocument the goals and o!jecties from the project definition documentation. Assign uniue ids toeach goal and o!jectie.

3." Constraints an, 'ssumptions ? &or the reuirements, ela!orate the glo!al constraints and assumptions, if any. Constraintsand assumptions could coer functionality, performance, maintenance, support, and the enironment in which the product will operate,including the !oundary conditions. 7xample %he system will not hae a !atch processing window, and will need to hae aaila!le real-time information. Constraints or Assumptions that are specific to a reuirement should !e documented in the functional or non-functionalreuirement ta!le.

a#e &, of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_1.2_References

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_1.3_Key_Contributors

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_3._Goals_and_Business%20Objectives

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_5._Functional_Requirements

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_1.2_References

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_1.3_Key_Contributors

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_3._Goals_and_Business%20Objectives





%he constraints imposed on the system would result in certain assumptions made. %hese should !e documented and agreement must !eo!tained from the customer.

Constraints and assumptions need to !e ealuated and assessed for potential risks.

4." Scenario - 3ist all the scenarios that need to !e addressed with this project. %his includes new scenarios as well as existingscenarios that reuire a change. (cenarios are processes that users follow to accomplish tasks. %he scenarios will !e used to guide the!usiness users to identify what reuirements the system must proide to completely accomplish the tasks. 6euirements will !e grouped!y scenario which will help proide context to the technical teams and testing teams. &or each scenario proide the following

• &- A uniue id num!er 0for example (C$-@1

• sers)s+ 5ho ,o scenario A list of users who participate in the scenario. "se the user id assigned in the user classes

section.• Scenario %ame A scenario name that !riefly descri!es the process.

• /escription& A detailed description of the scenario

• %e56& 7nter es in the new column if the scenario is new to the system.

!n Scope6& 7hether the requirement is in scope )optional+. !f you 5ish to recor, potential requirements that 5ere

-athere, but are not in the scope of the current pro8ect9 you may use the :in scope; column. he out<of<scoperequirements may be ,one at a later time or you may use this column to trac( ,ecisions on 5hether a requirement5ill be inclu,e,.

• Priority& A priority 0typically High, 8edium, 3ow or a scale of @-@1

." ser Classes an, Characteristics )Roles+ identifies the arious users that will use this application. "ser classes may !edifferentiated !ased on freuency of use, su!set of application functions used, technical expertise, security or priilege leels, educationalleel, or experience. #escri!e the pertinent characteristics of each user class. Certain reuirements may pertain only to certain userclasses.

=." Scenario an, ser 0o,el - Include a diagram of the scenarios and the users associated with each scenario. %his is similar tothe concept of a "se Case 8odel

a#e &0 of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_2._User_Classes_and%20Characteristics

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_Scenario_and_User

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_2._User_Classes_and%20Characteristics

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_Scenario_and_User




>." Scenario Process /ia-ram < Include a diagram of the scenarios and the different pathsflows within a gien scenario. Benerallythese will map to the high-leel reuirements. Also, if there is interaction !etween multiple scenarios, show this in the diagrams and howthey are related.

?." unctional Requirements - &or each (cenario that is included in the scope of this project, ela!orate on, further clarify anddefine, or decompose into high leel and detailed functional reuirements. Include !usiness rules that tie to a specific reuirement 0thiscan !e a high leel or detailed reuirement1.

%his section is for a further decomposition or more detailed leel of the reuirements from (ection . It includes functional and

deploymentsupport reuirements. 7xample reuirements are included in the ta!leD delete these reuirements when you no longer needthem. &or each reuirement, include

• !/& A uniue id num!er 0see recommended naming conention !elow1

• Ob8ecti@eAReference& A reference to a !usiness o!jectie or another parent reuirement.

• Source %he source of the reuirement 0a client name, department, or other identifier which descri!es who identified the

reuirement1

• /escription& A detailed description of the reuirement or !usiness rule.

• O5ner& %his is an optional field that can !e used to specify who will !e responsi!le for fulfilling the reuirement. &or example,

if there are multiple deelopment teams working on the same project this column could !e used to indicate which team isresponsi!le for that specific reuirement. %his will aoid the situation where one team thinks another team would !e takingcare of that reuirement and therefore it gets missed in design.

• !n Scope6& Ehether the reuirement is in scope 0optional1. If you wish to record potential reuirements that were gathered

!ut are not in the scope of the current project, you may use the :in scope; column. %he out-of-scope reuirements may !edone at a later time or you may use this column to track decisions on whether a reuirement will !e included.

• unctional Spec lo5& %his field will reference the flow the high-leel reuirementscenario corresponds with in the

&unctional (pecification document. Benerally the high-leel reuirements will map to &unctional &lows

• ReleaseA!teration& %he release or iteration num!er 0optional1 when the reuirement will !e deliered. If you are using an

iteratie methodology or doing time-!ox releases, you may use the :iteration; or :release; column to indicate the iteration orrelease when the reuirement will !e implemented

• Priority& A priority 0typically High, 8edium, 3ow or a scale of @-@1

a#e &3 of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23SCNProcessDiag1


http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23SCNProcessDiag1





• Constraints an, 'ssumptions !/A%otes& Include the id of any constraints or assumptions from the constraints and

assumptions section or a constraint or assumption that relates to a specific reuirement. $otes that pertain to thereuirement or !usiness rule may also !e included in this column.

If you are implementing a third party package, indicate key functionality that must !e proided !y this product. Address anycustomi2ation or interfaces to other systems that will !e deeloped. Identify any desired reuirements that will not !e proided !y this

package 0you may wish to do this !y adding a column to indicate whether the reuirement is satisfied1.

Identify a naming conention for your reuirements. A recommended naming conention follows 0examples of this naming conentionare included in the template.1

• "se a prefix to indicate the type of reuirement

• $um!er the high leel reuirement starting with the scenario id and then a num!er 0for example, 679-@.@, 679 [email protected], 679-

F.@, etc.1

• Add detailed reuirements under the high leel reuirements 0for example, #7%-@.@.@, #7%-@[email protected], #7%-F.@.@ etc.1

• Add !usiness rules that apply to the specific reuirement 0for example, 6"3-@.@, 6"3-F.@.@1. %hese can !e related to a

high leel or detailed reuirement.

*usiness 6ules are management policies and practices that guide day-to-day !usiness decisions. A !usiness rule

• Is a definition or a constraint a!out how the !usiness is run

• Is typically a fact a!out the !usiness that is true oer time

• Buides !usiness !ehaior

• Is true regardless of the application, project, or phase

• 8ay descri!e constraints, definitions, relationships, data transformation, seuence of processes or policies• Is an operating principle or policy that your software must satisfy

• Buides functional reuirements for your project

• 8ay !e enforced !y an application

7xamples

• (ales system must support returns of unopened, unused, or defectie merchandise for up to @G days from date of purchase.

Eith a alid sales receipt, returns must !e accepted at any store. Eithout a alid sales receipt, returns must !e accepted onlyat the store where purchased, and then only if the customer/s sales record is located in the system and the customer proidesa alid photo-id. Any store manager can oerride these rules and accept a return.

a#e &4 of %& 'ersion <()(>




• #epartment managers are allowed to update and iew salary and appraisal information for those team mem!ers who report to

them !ut not for team mem!ers who do not report to them.

• 5endor and contract data, including contracts, inoices, and legal correspondence, will !e retained for years.

• +nly purchase order locations with uantity or retail open !alances will !e reported. A purchase order location is considered

to hae an open uantity !alance if any item for that location has a greater order uantity than receipt uantity. A purchase

order location is considered to hae an open retail !alance if @1 the location has an open uantity !alance and F1 any item hasa greater current order retail amount, 0ordered uantity current retail amount1, than receied amount, 0receipt uantity retail amount at time of receipt1.

• $et (ales J Bross (ales less sales adjustments 0returns, return oids, or sales corrections1

• 8erit )ool amounts will !e the calculated !y taking the actual salary of team mem!ers eligi!le for merit times the merit

percentage shown in the 8erit )ool )ercentage ta!le. %he sum of these amounts for all team mem!ers under a superisorwill !e that superisor/s 8erit )ool.

$ote If there are !usiness rules that apply to the whole project they can !e listed as a constraint in the Constraints and Assumptionssection.

." %on<functional Requirements& Include any existing non-functional reuirements from the client or other stakeholder perspectie.Consider the items under each section 0not all will apply to your project1 and include information that is appropriate for your project.7nhancement projects should focus on documenting changes that may impact existing non-functional reuirements 0ex. :%he newfunctionality will reuire capacity for an additional @ users;1. %echnical design considerations 0which detail how the design will meet allreuirements1 should !e included in the #esign document. $ote *e sure to consider all tiers of any multi-tiered architecture and !e sureto consider all enironments including de, test, and stage enironments. Additional guidance can !e referenced in the $on-&unctional6euirements Ko! Aid .

'@ailability )'D+& If there are aaila!ility reuirements for the application !ased on the criticality of this application state them hereand partner with other %%( teams to make suita!le design choices 0i.e. failoer nodes, load !alancing architectures, !atch windowsi2e, etc1. Consider the following in this section

• Criticality of the application to the business process area

• Service level agreements regarding availability• Global application use and time zone impacts

• Frequency of transactions executed: daily, weely, monthly, continuously

Recoverability (REC): !artner with your business representative to assess the applications criticality and if there are disaster recovery

requirements for the application state them here" !artner with the ##S $usiness Continuation %anagement team to determine the best means of

assessing the &ecovery #ime 'b(ectives, &ecovery )nablers, &ecovery *rchitecture, and !latform &ecovery Strategy based on this application+s

&ecovery #ier"

a#e &6 of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_Non-Functional_Requirements



http://insidetgt.target.com/portal-target/Target/TechZone/techzone_resources?paf_dm=full&paf_gear_id=5800017&navpath=20103059_20103121_20103124&jsppath=/portal-target/templates/html/tz_resource_template.jsp&group=techzone_resources&title=/portal-target/templates/html/tz_resource_template.jsp&subDocTypeFilter=BCM-TTS&resourceContentId=PRD01-028603&_requestid=11454081

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_Non-Functional_Requirements



http://insidetgt.target.com/portal-target/Target/TechZone/techzone_resources?paf_dm=full&paf_gear_id=5800017&navpath=20103059_20103121_20103124&jsppath=/portal-target/templates/html/tz_resource_template.jsp&group=techzone_resources&title=/portal-target/templates/html/tz_resource_template.jsp&subDocTypeFilter=BCM-TTS&resourceContentId=PRD01-028603&_requestid=11454081




Supportability )SP+ Include reuirements for ongoing support and incidentpro!lem resolution for the application. Consider theteams inoled and any customer responsi!ilities for maintenance of the application. Also consider reuirements for administrationsupport 0i.e. user account maintenance, data maintenance, etc.1 and technical support of the application.

Performance )P#R+& If there are performance reuirements for the application under arious circumstances, state them here and

explain their rationale to help the deelopers understand the intent and make suita!le design choices. (pecify the timing relationshipsfor real time systems. ou may need to state performance reuirements for indiidual functional reuirements or features. Considerthe following in this section

• pper-.ower limits of acceptable performance

• )nd user time expectations /local and global users0

• 1umber of (obs-transactions expected per unit of time

• )xpected performance as compared to other applications

• 2ndustry goals-standards to be met

• Service level agreements regarding response time

• Frequency of transactions executed: daily, weely, monthly, continuously

• Global user base and wide area networ limitations

CapacityAScalability )C'P+& Identify any known present and future production capacity reuirements, such as num!er of users, datasi2e, or other units. Include any known capacity issues that may reuire changes or additions to production enironments. Considerthe following in this section

• #otal number of users

• 1umber of simultaneous /concurrent0 users

• Frequency of executions of system functions

• 3ata storage and other sizing requirements

• Since many applications are multi4tiered, consider all platforms

!nter<'pplication !nterfaces )!'!+& #escri!e the characteristics of each interface !etween the software application and other

applications. Consider the following• 3ata latency

• 5olume of data

• 6ournaling and-or auditing

• *vailability and performance

• *lerts and monitoring

Security )S#C 1 Insert the $on-&unctional (ecurity 6euirements as identified !ased on the results of your (ecurity 6euirements9uestionnaire. &or more information, contact (ecurity.ConsultingL%arget.com.

a#e &9 of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/Insert

http://var/www/apps/conversion/tmp/scratch_5/Insert




/ata !nte-rity )!%+& #escri!e the reuirements for maintaining data integrity within this application. &or assistance in defining dataintegrity reuirements, you may contact #ata.IntegrityLtarget.com. Consider the following

• %o what extent does the completeness and accuracy of data need to !e ensured as it is transferred within and !etween

applications, systems and platforms

• %o what leel will data integrity issues impact the new system and its clients

0onitorin- )0O%+& #escri!e the monitoring reuirements for this system. Include reuirements for the application and its processes, hardware, software, and network components. Consider the criticality of the application to the corporation, the !usinessimplications if certain system components are unaaila!le, and the recoery time o!jectie for the critical functions. (ee the7nterprise (ystems 8onitoring we! site for additional information on monitoring capa!ilities and reuirements.

/ata Retention )R#+& #escri!e the data retention reuirements !ased on a reiew of %arget/s Corporate 6ecords 6etention )olicy..%arget/s 6ecord 6etention )olicy is aaila!le on-line and proides information a!out how long each type of record are to !e kept0retention period1 and what is to happen to the record at the end of that period 0destruction1. Consider reuirements for data retention,data purge, and data archie.

#n@ironment )#%+& Any system components consumed !y the application should !e identified through the 6I) process to ensurethat the solution is in alignment with the %arget standard. #ocument non-6I) enironment considerations or constraints defined !yclients. Consider hardware, software or network reuirements such as

• Special hardware requirements imposed by the client or the existing environment

• &emote or local printing requirements

• Special peripheral devices

• Special ports required

• Software tools and utilities needed for this application

• 7nown middleware requirements

• Special email, web browser or other communications functions

-ote+ System components should "e identified through the R*! process to ensure that the solution is in alignment 9ith theTarget standard$

If you are implementing a third party package, insert a physical enironment diagram showing reuired endor operating enironmentor constraints. Add text as necessary to explain the operating enironment to clarify the diagram.

rainin- an, /ocumentation )R%+ 3ist the user documentation components 0such as user manuals, on-line help, and tutorials1that will !e deliered along with the application. Identify any known user documentation deliery formats or standards. Also identify

a#e %( of %& 'ersion <()(>








training reuirements, including indiiduals, timelines, and materials reuired. Consider training for support teams as well as clientteams.

1"." !nformation Sources descri!es and defines the logical data groups that will !e used !y the application. %hese are !usiness-

defined or user-defined stores of data referred to as :sources of information.;

o As you are collecting information sources for your project, contact Information Architecture to reiew the 7nterprise #ata

8odel 07#81 and determine how it may !e used to model your project/s data. Information sources identified for your projectshould !e defined in conjunction with %%( enterprise-wide data and process models.

o If your project is in the supply chain area, contact Information Architecture to reiew the 6etail (upply Chain )rocess

8odel and determine how it may !e used to help identify the data needs for your effort.

• 1".1 !nternal !nformation Sources descri!es and defines the logical data groups that are internal to the application.

:Internal; refers to related information sources of !usiness data that are entirely under the control of the application.

• 1".2 #$ternal !nformation Sources descri!es and defines the logical data groups that are external to the application.:7xternal; refers to related information sources that are used !y the application for reference purposes only. %hese datasources are entirely outside the application !oundary and are always maintained !y another application.

If you are implementing a third party package, indicate any data reuirements that reflect configuration decisions that will !e made inimplementing the package 0for example, use of certain fields or extensions to the endor data model1. #o not duplicate information on theendor/s data model.

11." 'ppro@al Si-nature Pa-e

Beneral Comments

All #eliera!le Approals will !e retained for a period of @ months from the )roject/s Implementation #ate using the Approal (ignature6etention )rocess.

%he )roject 8anagement )lan specifies whose Approal is reuired for each #eliera!le as it may ary for each.

At #eliera!le CreationCompletion

a#e %$ of %& 'ersion <()(>

http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_7._Information_Sources


http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_11._Requirements_Specification_Appr


http://var/www/apps/conversion/tmp/scratch_5/HYPERLINK%23_11._Requirements_Specification_Appr




Complete the top and !ottom portions of this Approal (ignature )age. Eithin the ta!le, type in the $ame and %itle of each reuired Approer as defined in the )roject 8anagement )lan. Add additional rows to the ta!le to accommodate one row per Approer as needed.7nsure that the content of the document Header and &ooter are accurate.

"o .btain Appro2al:

Re2ie the methods of si#nature capture from the list beloT these may be used interchan#eably for each appro2al needed:

a) All appro2ers si#n the same appro2al pa#e from the deli2erable) B"his method may taIe some time as the routin# occurs)

b) Appro2ers si#n indi2idual copies of the appro2al pa#e) B"his may be a faster process in some cases)c) Appro2ers use an e;mail response to si#nify their appro2al)d) Appro2ers respond to e;mail 2otin#)

Complete the deli2erable and submit to the appro2ers)

Appro2ers read the document and are directed to submit their appro2al usin# the pre;planned method)

or electronic approvals ensure that the Clarity *D !ro3ect -ameD elivera"le -ameD and ocument Version -um"er are includedin the su"3ect line of the email ) "he reply recei2ed from the appro2er should be either appro2al 2ia 2otin# buttons or a statement similar to L+ appro2e of this documentM)

Jhen Appro2al is Complete:

&or Hard Copy approals "he hard;copy appro2alBs pa#e may be detached from the deli2erable and retained in a physical file)

&or 7lectronic Approals rojects usin# the "S8 roject ortal that choose to utiliDe an lectronic Appro2al Si#nature ile store theirartifacts in the !ro3ect elivera"les area ith the document type of )pproval Signatures) rojects utiliDin# a hard copy file store thelocation of that file in the External References area of the "S8 roject ortal)

rojects that are not usin# the "S8 roject ortal store their electronic artifacts in ClarityQs 8ocument 7ana#er) rojects utiliDin# a hardcopy file store the location of that file in the roject Confi#uration +tems Report hich is then stored in ClarityQs 8ocument 7ana#er)

Template Change History

a#e %& of %& 'ersion <()(>

Version ate !repared "y Change escription,)( @une &((6 Requirements 7ana#ement

"eam7odifications made to template based on feedbacIfrom pilots

%)( @une &((6 S1 Chan#es to the Appro2al Si#nature pa#e and

instructions)

& ( eb &((6 Requirements 7ana#ement 7odifications related to scenario based requirements

Documents

Requirment Spec