Change History "his document is located in 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 "emplate 2ersion ,)( effecti2e @une &((6) "he folloin# important chan#es ha2e been made to this document: Version ate !repared "y #$% &&''(((( )uthor
Comments *nitial raft
To use this template+ • • • • • •
•
•
a#e % of %&
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. 'ersion <()(>
Requirements Specification for
#$ *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 to pro2ide direction for the technical project team in the desi#n construction and testin# of a solution) "he intended audience of this 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 better relationships ith these customers by #atherin# information about these customers and #atherin# information about the efficiency 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 <()(>
Requirements Specification for
*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 each customer)
a#e 0 of %&
'ersion <()(>
Requirements Specification for
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 !
1oalsBs
1oal;$
+mpro2e relationship ith Call Center Customers
-us .bj !
Reference
.bjecti2es
.-@;$
1oal;$
.-@;&
1oal;$
1ather information about each customer that calls into the call center +mpro2e efficiency of call center reps to better ser2e the customer
a#e 3 of %&
'ersion <()(>
Requirements Specification for
4$ Constraints and )ssumptions #ocument the glo!al constraints and assumptions that are related to the reuirements in this document. (pecific constraints and assumptions that are related to an indiidual reuirement are documented in the functional or non-functional reuirement ta!le.
Constraints and Assumptions +8 CA;$)(
8escription "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/s o!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.
/ SCN;$ SCN;&
6sers7s8 9ho do scenario 5SR;$ 5SR;& 5SR;&
a#e 4 of %&
Scenario -ame
escription
-e9:
Go# Customer +nformation 'ie eeIly acti2ity
Go# information from customer calls comin# into the call center Re2ie eeIly acti2ity data for call reps assi#ned to their department)
Hes
*n Scope: Hes
Hes
Hes
'ersion <()(>
!riority * 7
Requirements Specification for
;$ 6ser Classes and Characteristics / 5SR;$
6ser.)ctor Call Rep
5SR;&
Customer ser2ice m#r
6sage.Role Ansers calls from customers and enters customer information into system durin# the call) 7ana#es eeIly acti2ity for Call Reps in their department)
Accuracy
>$ Scenario and 6ser &odel #iagram0s1 of actor interactions with tasks and system0s1 appear here.
a#e 6 of %&
'ersion <()(>
Requirements Specification for
?$
Scenario !rocess iagram %his is a diagram of each scenario and the associated high-leel reuirements. %his should not get too detailed and should concentrate on the high-leel to assist in defining the scenario scope. If applica!le, show the oerlaps and interactions !etween the scenarios. SCN;$ Go# Customer +nfo
a#e 9 of %&
SCN;& 'ie JeeIly Acti2ity
'ersion <()(>
Requirements Specification for
@$ Aunctional Requirements %his ta!le should !e used to document !oth high leel and detail functional reuirements and !usiness rules. %he reuirements should !e organi2ed !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 most cases flows would !e mapped to high-leel reuirements
a#e $( of %&
'ersion <()(>
Requirements Specification for
+8!
SC-'# RE($)$
8"($)$ )$ 8"($)$ )&
8"($)$ )%
R5G($)$
RE($)& 8"($)& )$ R5G($)& )$
.bjecti2 eF Referen ce
Req Sourc e
.-@;$
@ane 8oe
.-@;$
@ane 8oe
.-@;$
@ane 8oe
.-@;$
@ane 8oe
.-@;$
@ane 8oe
.-@;$
@ane 8oe
.-@;$
@ane 8oe
.-@;$
@ane 8oe
.-@;$
@ane 8oe
a#e $$ of %&
8escription
,og Customer *nformation Ability to search for e=istin# customer information Ability to search for customer by last name Ability to search for customer by state Ability to display an error messa#e if customer is not found A ildcard search must be a2ailable for all search criteria Ability to add a ne customer Ability to enter customer last name All customers must ha2e a last name and state
Ability to enter customer first name Ability to enter customer phone number Ability to 2erify customer information Ability to 2erify customer last name Ability to 2erify customer first name Ability to 2erify customer phone number Ability to indicate that customer info as 2erified Ability to capture date customer info as last 2erified +f any customer info is chan#ed update the date last 2erified to date chan#e as made
Ability to capture call rep that last 2erified customer info +f any customer info is chan#ed update the call rep that last 2erified ith the call rep that chan#ed the customer info Ability to update customer information Ability to update customer last name Ability to update customer first name Ability to update customer phone number Ability to cancel update Ability to tracI call duration Ability to tracI call be#in time
Ability to tracI call end time Ability to tracI call rep info Ability to tracI call rep +8 Ability to tracI call rep name Ability to tracI call rep location Vie9
.n er
Ability to select department Ability to select any eeI ithin the last $% eeIs Ability to select a call rep Ability to sort eeIly acti2ity Ability to sort by department Ability to sort by eeI Ability to sort by call rep
.n er
+n Scope K
Hes Hes
Hes Hes Hes Hes Hes Hes
Relea se F +terati on & &
& & & & & &
riorit y
Constraint s and Assumptio ns +8 F Notes
unc) Spec lo
7 7
7 7
G;&)&
7 7 7 7
'ersion <()(>
G;&)%
Requirements Specification for
$ -on'Aunctional Requirements 8ocument belo any non;functional requirements that need to be considered for this system de2elopment project) 8efinitions for each area 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 deli2erable associated ith your project) Type
+8 !
A2ailabilit A'G; y $)(
Reco2er ability
RC ;$)(
Supporta bility
S5; $)(
CapacityF Scalabilit y
CA; $)(
a#e $3 of %&
.bje cti2eF Refe renc e
Sourc e
8escription
.ne r
+n Scope K
Releas eF +teratio n
riorit y
@ane 8oe
OA7G: "he application ill need to be a2ailable as needed in the normal course of business operations B96P a2ailability not includin# planned maintenance outa#es hich is the equi2alent of appro=imately % hours of unplanned dontime per eeI
@ohn Smith
Hes
$
*
'ersion <()(>
Constraints and Assumption s +8 F Notes
Requirements Specification for
Type
+n Scope K
Releas eF +teratio n
riorit y
Screens used to tracI customer information must display ithin 0 seconds 90P of the time
Hes
$
*
SCN ;&
Screens used to 2ie eeIly acti2ity must display ithin $0 seconds 90P of the time
Hes
$
*
R; %)(
SCN ;&
+f user selects a ne sort order it must complete ithin $0 seconds 90P of the time
Hes
$
*
Security
SC; $)(
SCN ;&
Access to the 'ie JeeIly Acti2ity must be limited to Customer Ser2ice 7ana#ers)
Hes
$
*
+nter;App +nterface s
+A+; $)(
7onitorin #
7.N ;$)(
8ata +nte#rity
+N"; $)(
erforma nce
+8 !
.bje cti2eF Refe renc e
R; $)(
SCN ;$
R; &)(
a#e $4 of %&
Sourc e
8escription
.ne r
'ersion <()(>
Constraints and Assumption s +8 F Notes
Requirements Specification for
Type
+8 !
8ata Retentio n
R"; $)(
Note: "ar#etQs Record Retention olicy is a2ailable on;line and pro2ides information about ho lon# each type of record is to be Iept Bretention period and hat is to happen to the record at the end of that period Bdestruction) Consider requirements for data retention data pur#e and data archi2e)
n2ironm ent
N'; $)(
Note: System components should be identified throu#h the R+ process to ensure that the solution is in ali#nment ith "ar#et standard solutions)
"rainin#F 8ocume ntation
"RN; $)(
a#e $6 of %&
.bje cti2eF Refe renc e
Sourc e
8escription
.ne r
+n Scope K
Releas eF +teratio n
'ersion <()(>
riorit y
Constraints and Assumption s +8 F Notes
Requirements Specification for
#%$ *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 Sources 3ist and descri!e the logical data groups that are used or referenced !y this application !ut are maintained under control of another application.
##$ 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)
!hysical Signature or ,ocation of Electronic )pproval
TTS &anager B6C or B!C or Business &anager
a#e $9 of %&
'ersion <()(>
ate
Requirements Specification for
%ote& 'n asteris( )*+ i,entifies a si-nature that is require, for S/. ',,itional si-natures may be a,,e,.
a#e &( of %&
'ersion <()(>
Requirements Specification for
#0$ *nstructions and 1uidelines )$ 1eneral 1uidelines for using this template+ •
%his template may !e used for !oth internally deeloped software projects or for t hird party package implementation projects.
•
•
•
•
•
•
a#e &$ of %&
#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 package implementations are included in red text. Any reuirements for customi2ation or deelopment of code for interfaces or other reasons 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 6eferences section. %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 potential endor solutions, ealuating those potential solutions against the reuirements and other !usiness ualifications, and then analy2ing 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 sure to 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 t heRequirements 0ana-ement Process, Requirement s atherin - Plan and Requirement s 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 to explain :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 the reuirements.
'ersion <()(>
Requirements Specification for
•
•
•
a#e && of %&
%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 of identifying 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.
'ersion <()(>
Requirements Specification for
B$ Requirements Hierarchy roject 8efinition
Analysis
8esi#n a#e &% of %&
Business 1oals Specific measurable impro2ements o 8efine the HQs of the project o =: L-etter import allocations ill reduce by ) percent)M o Business 2"3ectives 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 o Scenario *i#h le2el user acti2ities o Should include hich users are in2ol2ed in the acti2ities o =: Llace Split urchase .rderM o Business Rules 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 o Aunctional Requirements 7 High level 8 *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 o Aunctional Requirements 7 etail 8 *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 o -on'Aunctional Requirements Requirements that can not be met by a specific function of the application o +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 o should be) =: L"he system uptime required is 96PM o Aunctional Specification +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 o esign *tems 8ocumented in the 8esi#n 8ocument o
'ersion <()(>
Requirements Specification for
o o o o o
8escribes L*o toM implement the featureFfunction Should be able to rite a pro#rammers spec from this le2el of detail Bif needed =: Column names to add to the import allocation table 8esi#n +nspection typically occurs ith this le2el of detail 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 releant documents related to this reuirements specification. Include title, author, and location 0pathname1 of the reference. Include ersion num!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!out the 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 to each goal and o!jectie.
3." Constraints an, 'ssumptions ? &or the reuirements, ela!orate the glo!al constraints and assumptions, if any. Constraints and 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 realtime information. Constraints or Assumptions that are specific to a reuirement should !e documented in the functional or non-functional reuirement ta!le. a#e &, of %&
'ersion <()(>
Requirements Specification for
%he constraints imposed on the system would result in certain assumptions made. %hese should !e documented and agreement must !e o!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 existing scenarios 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
." ser Classes an, Characteristics )Roles+ identifies the arious users that will use this application. "ser classes may !e differentiated !ased on freuency of use, su!set of application functions used, technical expertise, security or priilege leels, educational leel, or experience. #escri!e the pertinent characteristics of each user class. Certain reuirements may pertain only to certain user classes.
=." Scenario an, ser 0o,el - Include a diagram of the scenarios and the users associated with each scenario. %his is similar to the concept of a "se Case 8odel a#e &0 of %&
'ersion <()(>
Requirements Specification for
>." Scenario Process /ia-ram < Include a diagram of the scenarios and the different pathsflows within a gien scenario. Benerally these will map to the high-leel reuirements. Also, if there is interaction !etween multiple scenarios, show this in the diagrams and how they are related.
?." unctional Requirements - &or each (cenario that is included in the scope of this project, ela!orate on, further clarify and define, or decompose into high leel and detailed functional reuirements. Include !usiness rules that tie to a specific reuirement 0this can !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 need them. &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 is responsi!le for that specific reuirement. %his will aoid the situation where one team thinks another team would !e taking care 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 !e done 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 or release when the reuirement will !e implemented Priority& A priority 0typically High, 8edium, 3ow or a scale of @-@1
a#e &3 of %&
'ersion <()(>
Requirements Specification for
•
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 the reuirement 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 any customi2ation 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 conention are 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 -@.F, 679F.@, 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 only at the store where purchased, and then only if the customer/s sales record is located in the system and the customer proides a alid photo-id. Any store manager can oerride these rules and accept a return. a#e &4 of %& 'ersion <()(> •
Requirements Specification for
•
• •
• •
#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 has a 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 superisor will !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 Assumptions section. ." %on
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, &e covery *rchitecture, and !latform &ecovery Strategy based on this application+s &ecovery #ier"
a#e &6 of %&
'ersion <()(>
Requirements Specification for Supportability )SP+ Include reuirements for ongoing support and incidentpro!lem resolution for the application. Consider the teams inoled and any customer responsi!ilities for maintenance of the application. Also consider reuirements for administration support 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 relationships for real time systems. ou may need to state performance reuirements for indiidual functional reuirements or features. Consider the 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, data si2e, or other units. Include any known capacity issues that may reuire changes or additions to production enironments. Consider the 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 6euirements 9uestionnaire. &or more information, contact (ecurity.ConsultingL%arget.com. a#e &9 of %&
'ersion <()(>
Requirements Specification for
/ata !nte-rity )!%+& #escri!e the reuirements for maintaining data integrity within this application. &or assistance in defining data integrity 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 !usiness implications if certain system components are unaaila!le, and the recoery time o!jectie for the critical functions. (ee the 7nterprise (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 kept 0retention 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 ensure that the solution is in alignment with the %arget standard. #ocument non-6I) enironment considerations or constraints defined !y clients. 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 the Target standard$ If you are implementing a third party package, insert a physical enironment diagram showing reuired endor operating enironment or 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 tutorials1 that will !e deliered along with the application. Identify any known user documentation deliery formats or standards. Also identify a#e %( of %&
'ersion <()(>
Requirements Specification for training reuirements, including indiiduals, timelines, and materials reuired. Consider training for support teams as well as client teams.
1"." !nformation Sources descri!es and defines the logical data groups that will !e used !y the application . %hese are !usinessdefined or user-defined stores of data referred to as :sources of information.; o
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 project should !e defined in conjunction with %%( enterprise-wide data and process models. 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 data sources 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 in implementing the package 0for example, use of certain fields or extensions to the endor data model1. #o not duplicate information on the endor/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 (ignature 6etention )rocess. %he )roject 8anagement )lan specifies whose Approal is reuired for each #eliera!le as it may ary for each. At #eliera!le CreationCompletion
