Use this Requirements Specification template to document the requirements for your product or service, including priority and approval. The format of the requirements depends on what wors best for your project. This document contains instructions and e"amples which are for the benefit of the person writing the document and should be removed before the document is finalized.
Use this Requirements Specification template to document the requirements for your product or service, including priority and approval. The format of the requirements depends on what wors best for your project. This document contains instructions and e"amples which are for the benefit of the person writing the document and should be removed before the document is finalized.
Use this Requirements Specification template to document the requirements for your product or service, including priority and approval. The format of the requirements depends on what wors best for your project. This document contains instructions and e"amples which are for the benefit of the person writing the document and should be removed before the document is finalized.
Version 1.0 March 25, 201 Use this Requirements Specification template to document the requirements for your product or service, including priority and approval. Tailor the specification to suit your project, organizing the applicable sections in a way that wors best, and use the checlist to record the decisions about what is applicable and what isn!t. The format of the requirements depends on what wors best for your project. This document contains instructions and e"amples which are for the benefit of the person writing the document and should be removed before the document is finalized. To regenerate the T#$, select all %$T&'() and press *+. ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 3 o f 36 [YourProject] Requirements Specification !a"#e of $ontents [YOURPROJECT] REQUIREMENTS SPECIFICATION........................................................................................ 1 VERSION 1.0.......................................................................................................................................................... 1 MARCH 25, 2014................................................................................................................................................... 1 1. EXECUTIVE SUMMARY..................................................................................................................................... 3 1.1 PROJECT OVERVIEW....................................................................................................................................... 3 1.2 PURPOSE AND SCOPE OF THIS SPECIFICATION................................................................................................. 3 2. PRODUCTSERVICE DESCRIPTION................................................................................................................. 3 2.1 PRODUCT CONTEXT........................................................................................................................................ 3 2.2 USER CHARACTERISTICS................................................................................................................................. 3 2.3 ASSUMPTIONS ................................................................................................................................................ 3 2.4 CONSTRAINTS................................................................................................................................................. 3 2.5 DEPENDENCIES............................................................................................................................................... 4 3. REQUIREMENTS................................................................................................................................................ 4 3.1 FUNCTIONAL REQUIREMENTS........................................................................................................................... 5 3.2 USER INTERFACE REQUIREMENTS.................................................................................................................... 5 3.3 USABILITY....................................................................................................................................................... 5 3.4 PERFORMANCE............................................................................................................................................... 6 3.5 MANAEABILITY!MAINTAINABILITY .................................................................................................................... 6 3.6 SYSTEM INTERFACE!INTERATION.................................................................................................................... " A. SYSTEM1!TO!SYSTEM2 INTERFACE.............................................................................................................. " A.1. THE FILENAME FILE IS A FIXED LENTH TEXT FILE........................................................................................... " A.2. THE FILENAME FILE IS AN UNFORMATTED ASCII FILE #TEXT$ONLY%..................................................................." A.3. THE FILENAME FILE CONTAINS A BATCH TOTALS RECORD AND SEVERAL DETAIL RECORDS. ..............................." A.4. THE BATCH TOTALS RECORD CAN BE PLACED AT THE BEINNIN& IN THE MIDDLE& OR AT THE END OF THE FILE.. ." A.5. THE BATCH TOTALS RECORD CONTAINS THE FOLLOWIN'................................................................................. " A.6. THE FILENAME FILE CONTAINS A ROW FOR EACH RECORD MEETIN XXX CRITERIA............................................" A.". EACH ROW IN THE FILENAME FILE CONTAINS THE FOLLOWIN FIELDS& COMMA$DELIMITED AND ENCASED IN DOUBLE$QUOTES WHERE THE DATA INCLUDES COMMAS OR SPACES'.......................................................................... " 3." SECURITY....................................................................................................................................................... ( 3.( DATA MANAEMENT........................................................................................................................................ ( 3.) STANDARDS COMPLIANCE................................................................................................................................ ( 3.1* PORTABILITY................................................................................................................................................. ( 4. USER SCENARIOSUSE CASES....................................................................................................................... # 5. DE$ETED OR DEFERRED REQUIREMENTS................................................................................................... # %. REQUIREMENTS CONFIRMATIONSTA&EHO$DER SI'N!OFF ..................................................................10 APPENDIX........................................................................................................................................................... 11 1. DEFINITIONS& ACRONYMS& AND ABBREVIATIONS................................................................................................ 11 1. DEFINITIONS& ACRONYMS& AND ABBREVIATIONS................................................................................................ 11 2. REFERENCES.................................................................................................................................................. 11 2. REFERENCES.................................................................................................................................................. 11 3. REQUIREMENTS TRACEABILITY MATRIX............................................................................................................ 11 3. REQUIREMENTS TRACEABILITY MATRIX............................................................................................................ 11 4. ORANI+IN THE REQUIREMENTS.................................................................................................................... 14 4. ORANI+IN THE REQUIREMENTS.................................................................................................................... 14 ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age / o f 36 [YourProject] Requirements Specification 3. 8"ecutive Summary 1.1 Project Overview 9escribe this project or product and its intended audience, or provide a lin or reference to the project charter. 1.2 Purpose and Scope of this Specification 9escribe the purpose of this specification and its intended audience. :nclude a description of what is within the scope what is outside of the scope of these specifications. *or e"ample; %n scope This document addresses requirements related to phase / of 7roject (; modification of $lassification 7rocessing to meet legislative mandate (<$. modification of &abor Relations 7rocessing to meet legislative mandate (<$. &ut of Scope The following items in phase 2 of 7roject ( are out of scope; modification of $lassification 7rocessing to meet legislative mandate =>?. modification of &abor Relations 7rocessing to meet legislative mandate =>?. %7hase 2 will be considered in the development of the requirements for 7hase /, but the 7hase 2 requirements will be documented separately.) /. 7roduct,Service 9escription :n this section, describe the general factors that affect the product and its requirements. This section should contain bacground information, not state specific requirements %provide the reasons why certain specific requirements are later specified). 2.1 Product Contet @ow does this product relate to other productsA :s it independent and self'containedA 9oes it interface with a variety of related systemsA 9escribe these relationships or use a diagram to show the major components of the larger system, interconnections, and e"ternal interfaces. 2.2 !ser Characteristics $reate general customer profiles for each type of user who will be using the product. 7rofiles should include; Student,faculty,staff,other e"perience technical e"pertise other general characteristics that may influence the product 2." #ssumptions &ist any assumptions that affect the requirements, for e"ample, equipment availability, user e"pertise, etc. *or e"ample, a specific operating system is assumed to be availableB if the operating system is not available, the Requirements Specification would then have to change accordingly. 2.$ Constraints 9escribe any items that will constrain the design options, including parallel operation with an old system ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 2 o f 36 [YourProject] Requirements Specification audit functions %audit trail, log files, etc.) access, management and security criticality of the application system resource constraints %e.g., limits on dis space or other hardware limitations) other design constraints %e.g., design or other standards, such as programming language or framewor) 2.% &ependencies &ist dependencies that affect the requirements. 8"amples; This new product will require a daily download of data from =, 4odule = needs to be completed before this module can be built. 2. Requirements 9escribe all system requirements in enough detail for designers to design a system satisfying the requirements and testers to verify that the system satisfies requirements. #rganize these requirements in a way that wors best for your project. See 6 6 , #rganizing the Requirements for different ways to organize these requirements. 9escribe every input into the system, every output from the system, and every function performed by the system in response to an input or in support of an output. %Specify what functions are to be performed on what data to produce what results at what location for whom.) 8ach requirement should be numbered %or uniquely identifiable) and prioritized. See the sample requirements in *unctional Requirements, and System :nterface,:ntegration, as well as these e"ample priority definitions; Priorit' (efinitions The following definitions are intended as a guideline to prioritize requirements. 7riority 3 C The requirement is a Dmust haveE as outlined by policy,law 7riority / C The requirement is needed for improved processing, and the fulfillment of the requirement will create immediate benefits 7riority 2 C The requirement is a Dnice to haveE which may include new functionality :t may be helpful to phrase the requirement in terms of its priority, e.g., FThe value of the employee status sent to 9:S must "e either ( or :F or F:t )ou#* "e nice if the application warned the user that the e"piration date was 2 business days awayF. (nother approach would be to group requirements by priority category. ( good requirement is; $orrect Unambiguous %all statements have e"actly one interpretation) $omplete %where T<9s are absolutely necessary, document why the information is unnown, who is responsible for resolution, and the deadline) $onsistent Raned for importance and,or stability Gerifiable %avoid soft descriptions lie Dwors wellE, Dis user friendlyEB use concrete terms and specify measurable quantities) 4odifiable %evolve the Requirements Specification only via a formal change process, preserving a complete audit trail of changes) 9oes not specify any particular design ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 6 o f 36 [YourProject] Requirements Specification Traceable %cross'reference with source documents and spawned documents). ".1 'unctiona( Requirements :n the e"ample below, the requirement numbering has a scheme ' <R-&R-1HH %<R for <usiness Requirement, &R for &abor Relations). *or small projects simply <R'HH would suffice. Ieep in mind that if no prefi" is used, the traceability matri" may be difficult to create %e.g., no differentiation between !1/! as a business requirement vs. a test case) The following table is an e"ample format for requirements. $hoose whatever format wors best for your project. *or 8"ample; Req+ Requirement $omments Priorit' (ate R,)* SM- Re,ie)e* . /ppro,e* <R-&R-15 The system should associate a supervisor indicator with each job class. <usiness 7rocess J D4aintenance 2 K,32,16 <ob 9ylan, 4ic Lagger <R-&R-10 The system should handle any number of fees %e"isting and new) associated with unions. <usiness 7rocess J D$hanging 9ues in the SystemE (n e"ample of a new fee is an initiation fee. / K,32,16 <ob 9ylan, 4ic Lagger <R-&R-31 The system should capture and maintain job class status %i.e., active or inactive) <usiness 7rocess J D4aintenanceE Some job classes are old and are no longer used. @owever, they still need to be maintained for legal, contract and historical purposes. / K,32,16 <ob 9ylan, 4ic Lagger <R-&R-3. The system should assign the Supervisor $ode based on the value in the Lob $lass table and additional criteria as specified by the clients. (pril /115 C Mew requirement. :t is one of three new requirements from <R-&R-12. / <R-&R-30 The system should provide the &abor Relations office with the ability to override the system'derived <argaining Unit code and the Union $ode for to'be'determined employee types, including hourly appointments. (pril /115 C Mew requirement. :t is one of three new requirements from <R-&R-16. 5,33,/115 C 7riority changed from / to 2. / 2 ".2 !ser )nterface Requirements :n addition to functions required, describe the characteristics of each interface between the product and its users %e.g., required screen formats,organization, report layouts, menu structures, error and other messages, or function eys). "." !sa*i(it+ :nclude any specific usability requirements, for e"ample, ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 5 o f 36 [YourProject] Requirements Specification &earnability The user documentation and help should be complete The help should be conte"t sensitive and e"plain how to achieve common tass The system should be easy to learn %See http;,,www.usabilitynet.org,) ".$ Performance Specify static and dynamic numerical requirements placed on the system or on human interaction with the system; Static numerical requirements may include the number of terminals to be supported, the number of simultaneous users to be supported, and the amount and type of information to be handled. 9ynamic numerical requirements may include the number of transactions and tass and the amount of data to be processed within certain time period for both normal and pea worload conditions. (ll of these requirements should be stated in measurable form. *or e"ample, F+5N of the transactions shall be processed in less than 3 secondF rather than Dan operator shall not have to wait for the transaction to completeE. 0..1 $apacit' :nclude measurable capacity requirements %e.g., the number of simultaneous users to be supported, the ma"imum simultaneous user load, per'user memory requirements, e"pected application throughput) 0..2 /,ai#a"i#it' :nclude specific and measurable requirements for; @ours of operation &evel of availability required $overage for geographic areas :mpact of downtime on users and business operations :mpact of scheduled and unscheduled maintenance on uptime and maintenance communications procedures reliability %e.g., acceptable mean time between failures %4T<*), or the ma"imum permitted number of failures per hour). 0..0 1atenc' :nclude e"plicit latency requirements, e.g., the ma"imum acceptable time %or average time) for a service request. ".% ,ana-ea*i(it+.,aintaina*i(it+ 0.5.1 Monitorin2 :nclude any requirements for product or service health monitoring, failure conditions, error detection, logging, and correction. 0.5.2 Maintenance Specify attributes of the system that relate to ease of maintenance. These requirements may relate to modularity, comple"ity, or interface design. Requirements should not be placed here simply because they are thought to be good design practices. ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age . o f 36 [YourProject] Requirements Specification 0.5.0 &perations Specify any normal and special operations required by the user, including; periods of interactive operations and periods of unattended operations data processing support functions bacup and recovery operations safety considerations and requirements disaster recovery and business resumption "./ S+stem )nterface.)nte-ration Specify the use of other required products %e.g., a database or operating system), and interfaces with other systems %e.g., UO@ires pacage interfaces with 7ub$ooie and #9S, @877S system interfaces with <udget system). *or each interface, define the interface in terms of message format and content. *or well'documented interfaces, simply provide a reference to the documentation. #utline each interface between the product and the hardware or networ components of the system. This includes configuration characteristics %e.g., number of ports, instruction sets), what devices are to be supported, and protocols %e.g., signal handshae protocols). 0.3.1 4et)or5 an* 6ar*)are %nterfaces Specify the logical characteristics of each interface between the product and the hardware or networ components of the system. This includes configuration characteristics %e.g., number of ports, instruction sets), what devices are to be supported, and protocols %e.g., signal handshae protocols). 0.3.2 S'stems %nterfaces 8"ample systems interface requirements; A. System1-to-System2 Interface The Pe"ternal partyQ will create and send a fi"ed length te"t file as an email attachment to System/mailRu.washington.edu to be imported into the System/ system for payroll calculation. This file must be received on 89:T day by 6;11 74 in order to be processed in the 89:T night run. The requirements below document the file specifications, data transfer process, and specific schedule. This file is referred to as F*ileMameF in this document. 'i(e Structure and 'ormat (.3. The *ileMame file is a fi"ed length te"t file. (./. The *ileMame file is an unformatted (S$:: file %te"t'only). (.2. The *ileMame file contains a batch totals record and several detail records. 'i(e &escription0 1atch 2ota(s Record (.6. The batch totals record can be placed at the beginning, in the middle, or at the end of the file. (.5. The batch totals record contains the following; 3. Record Type %value; =() /. 7rocess Type %value; () 2. <atch Mumber %2 digit number assigned by 7ayroll 9ept) 6. #rigin $ode %(:S) 5. Total number of detail records .. Total deduction amount 'i(e &escription0 &etai( Records (... The *ileMame file contains a row for each record meeting """ criteria. (.K. 8ach row in the *ileMame file contains the following fields, comma'delimited and encased in double' quotes where the data includes commas or spaces; 8mployee :d ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age K o f 36 [YourProject] Requirements Specification Record Type 7rocess 9ate %4499>>) =>S Mumber 8lement $ode (mount (mount Sign >ear *lag Total (mount Total (mt Sign ".3 Securit+ 0.7.1 Protection Specify the factors that will protect the system from malicious or accidental access, modification, disclosure, destruction, or misuse. *or e"ample; encryption activity logging, historical data sets restrictions on intermodule communications data integrity checs 0.7.2 /uthori8ation an* /uthentication Specify the (uthorization and (uthentication factors. $onsider using standard tools such as 7ub$ooie. ".4 &ata ,ana-ement Specify the requirements for any information that is to be placed into a database, including types of information used by various functions frequency of use data access rules data entities and relationships integrity constraints data retention valid range, accuracy, and,or tolerance units of measure data formats default or initial values ".5 Standards Comp(iance Specify the requirements derived from e"isting standards, policies, regulations, or laws %e.g., report format, data naming, accounting procedures, audit tracing). *or e"ample, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum regulatory or financial standards. (n audit trace requirement may, for e"ample, state that all changes to a payroll database must be recorded in a trace file with before and after values. ".16 Porta*i(it+ :f portability is a requirement, specify attributes of the system that relate to the ease of porting the system to other host machines and,or operating systems. *or e"ample, ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 0 o f 36 [YourProject] Requirements Specification 7ercentage of components with host'dependent codeB 7ercentage of code that is host dependentB Use of a proven portable languageB Use of a particular compiler or language subsetB Use of a particular operating systemB The need for environment'independence ' the product must operate the same regardless of operating systems, networs, development or production environments. 6. User Scenarios,Use $ases 7rovide a summary of the major functions that the product will perform. #rganize the functions to be understandable to the customer or a first time reader. :nclude use cases and business scenarios, or provide a lin to a separate document %or documents). ( business scenario; 9escribes a significant business need :dentifies, documents, and rans the problem that is driving the scenario 9escribes the business and technical environment that will resolve the problem States the desired objectives Shows the D(ctorsE and where they fit in the business model :s specific, and measurable, and uses clear metrics for success 5. 9eleted or 9eferred Requirements :dentify any requirements that have been deleted after approval or that may be delayed until future versions of the system. *or e"ample; Req+ 9usiness Requirement Status $omments Pri (ate R,)* SM- Re,ie)e* ./ppro,e* <R-&R-13 The system should validate the relationship between <argaining Unit,&ocation and Lob $lass. (pril /115; 9eleted. This requirement has been replaced by <R-&R-12. and <R-$$-22. <usiness 7rocess J D(ssigning a <argaining Unit to an (ppointmentE 3 K,32,16 <ob 9ylan, 4ic Lagger <R-&R-1/ The system should validate that the supervisor indicator is correct according to job class. 9eferred to 7hase /<; 2,/+,/115 (pril /115; 9eferred to 7hase /<. <usiness 7rocess J D(ssigning a <argaining Unit to an (ppointmentE 2 K,32,16 <ob 9ylan, 4ic Lagger <R-&R-12 The system should derive the bargaining unit code, union code, and supervisor indicator from the job class code and location. (pril /115; 9eleted Replaced by <R-&R-3. and <R-&R-3K. <usiness 7rocess J D(ssigning a <argaining Unit to an (ppointmentEB This will eliminate the need, typically, for the user to enter the bargaining unit code, union code and supervisor indicator. 3 K,32,16 <ob 9ylan, 4ic Lagger ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age + o f 36 [YourProject] Requirements Specification .. Requirements $onfirmation,Staeholder sign'off :nclude documentation of the approval or confirmation of the requirements here. *or e"ample; Meetin2 (ate /tten*ees :name an* ro#e; $omments K,32,1K <ob 9ylan, &abor Relations S48 4ic Lagger, &abor Relations S48 Ringo Starr, Technical 7roject 4anager 9ebbie @arry, Technical (nalyst Lanis Loplin, Technical (nalyst *red 4eyer, 7roject 4anager $onfirmed <R-&R-13 C <R-&R-35 16,35,15 <ob 9ylan, &abor Relations S48 4ic Lagger, &abor Relations S48 Ringo Starr, Technical 7roject 4anager 9eferred , 9eleted; <R-&R-13 ' <R-&R-16, <R-&R-1K, <R-&R-3/, <R-&R-36, <R-&R-35, <R-&R-1., <R-&R-3K ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 31 o f 36 [YourProject] Requirements Specification (778M9:= The appendi"es are not always considered part of the actual Requirements Specification and are not always necessary. They may include Sample input,output formats, descriptions of cost analysis studies, or results of user surveysB Supporting or bacground information that can help the readers of the Requirements SpecificationB ( description of the problems to be solved by the systemB Special pacaging instructions for the code and the media to meet security, e"port, initial loading, or other requirements. Ohen appendi"es are included, the Requirements Specification should e"plicitly state whether or not the appendi"es are to be considered part of the requirements. 1. (efinitions, /cron'ms, an* /""re,iations 9efine all terms, acronyms, and abbreviations used in this document. 2. References &ist all the documents and other materials referenced in this document. 0. Requirements !racea"i#it' Matri< The following trace matri" e"amples show one possible use of naming standards for deliverables %*unctional(rea'9ocType'MM). The number has no other meaning than to eep the documents unique. *or e"ample, the <argaining Unit (ssignment 7rocess *low would be <U('7*'13. *or e"ample %3); 9usiness Requirement /rea (e#i,era"#es Status <R-&R-13 The system should validate the relationship between <argaining Unit,&ocation and Lob $lass.'''$omments; <usiness 7rocess J F(ssigning a <argaining Unit to an (ppointmentF %7riority 3) <U( <U('$9'13 (ssign <U $onceptual 9esign (ccepted <U('7*'13 9erive <argaining Unit'7rocess *low 9iagram (ccepted <U('7*'13 9erive <argaining Unit'7rocess *low 9iagram (ccepted <R-&R-1+ The system should provide the capability for the &abor Relations #ffice to maintain the job class,union relationship.'''$omments; <usiness 7rocess J F4aintenanceF %7riority 3) <U( <U('$9'13 (ssign <U $onceptual 9esign (ccepted <U('7*'1/ <U (ssignment Rules 4aint 7rocess *low 9iagram Ready*orReview *or e"ample %/); 9i8Req%( Pri Major /rea (e,!st%tems (e#i,%( (e#i, 4ame Status <R-&R-13 3 <U( <U('$9'13 (ssign <U $onceptual 9esign (ccepted <R-&R-13 3 <U( <U('9S'1/ <argaining Unit (ssignment 9< 4odification 9escription (ccepted <R-&R-13 3 <U( <U('7*'13 9erive <argaining Unit'7rocess *low 9iagram (ccepted ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 33 o f 36 [YourProject] Requirements Specification 9i8Req%( Pri Major /rea (e,!st%tems (e#i,%( (e#i, 4ame Status <R-&R-13 3 <U( <U('U$9'13 <U (ssign &R Use$ase 9iagram Ready*orReview <R-&R-13 3 <U( <U('U$T'113 <U (ssignment by 7$ Use$ase ' (dd (ppointment and 9erive U<U Reviewed <R-&R-13 3 <U( <U('U$T'11/ <U (ssignment by 7$ Use$ase ' (dd (ppointment %U<U Mot *ound) Reviewed <R-&R-13 3 <U( <U('U$T'11. <U (ssignment by 7$ Use$ase ' 4odify (ppointment %Removed U<U) Reviewed <R-&R-1+ 3 <U( <U('$9'13 (ssign <U $onceptual 9esign (ccepted <R-&R-1+ 3 <U( <U('9S'1/ <argaining Unit (ssignment 9< 4odification 9escription (ccepted <R-&R-1+ 3 <U( <U('7*'1/ <U (ssignment Rules 4aint 7rocess *low 9iagram(ccepted <R-&R-1+ 3 <U( <U('U$9'12 <U (ssign Rules 4aint Use$ase 9iagram Reviewed <R-&R-1+ 3 <U( <U('U$T'165 <U (ssignment Rules 4aint; Successfully (dd Mew (ssignment Rule Reviewed <R-&R-1+ 3 <U( <U('U$T'153 <U (ssignment Rules 4aintUse$ase; 4odify Rule Reviewed <R-&R-1+ 3 <U( <U('U$T'152 <U (ssignment Rules 4aintUse$ase ' Review (ssignment Rules Reviewed <R-&R-1+ 3 <U( <U('U$T'15K <U (ssignment Rules 4aintUse$ase; :nactivate &ast Rule for a <U Reviewed <R-&R-1+ 3 <U( <U('U:'1/ <U (ssignRules 4aint U: 4ocups Ready*orReview <R-&R-1+ 3 <U( <U('T$'1/3 <U (ssignment Rules 4aint Test$ase; (dd Mew Rule %(ssociated Lob $lass 9oes Mot 8"ist) ' Success Ready*orReview <R-&R-1+ 3 <U( <U('T$'1/K <U (ssignment Rules 4aint Test$ase; 4odify Rule ' Success Ready*orReview <R-&R-1+ 3 <U( <U('T$'125 <U (ssignment Rules 4aint Test$ase; (dd Mew Rule %(ssociated Lob $lass 9oes Mot 8"ist) ' 8rror $ondition Ready*orReview <R-&R-1+ 3 <U( <U('T$'16+ <U (ssignment Rules 4aint Test$ase; 4odify Rule ' 8rror $ondition Ready*orReview *or e"ample %2); 9i8Req%( $(01 $(02 $(00 $(0 =%01 =%02 =$!01 =$!02 =$!00 !$01 !$02 !$00 !$0 <R-&R-13 X X X X X <R-&R-1+ X X X X X X ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 3/ o f 36 [YourProject] Requirements Specification 9i8Req%( $(01 $(02 $(00 $(0 =%01 =%02 =$!01 =$!02 =$!00 !$01 !$02 !$00 !$0 <R-&R-31 X X X X <R-&R-33 X ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 32 o f 36 [YourProject] Requirements Specification . &r2ani8in2 the Requirements This section is for information only as an aid in preparing the requirements document. 9etailed requirements tend to be e"tensive. Sive careful consideration to your organization scheme. Some e"amples of organization schemes are described below; 9' S'stem Mo*e Some systems behave quite differently depending on the mode of operation. *or e"ample, a control system may have different sets of functions depending on its mode; training, normal, or emergency. 9' =ser $#ass Some systems provide different sets of functions to different classes of users. *or e"ample, an elevator control system presents different capabilities to passengers, maintenance worers, and fire fighters. 9' &"jects #bjects are real'world entities that have a counterpart within the system. *or e"ample, in a patient monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. (ssociated with each object is a set of attributes %of that object) and functions %performed by that object). These functions are also called services, methods, or processes. Mote that sets of objects may share attributes and services. These are grouped together as classes. 9' >eature ( feature is an e"ternally desired service by the system that may require a sequence of inputs to affect the desired result. *or e"ample, in a telephone system, features include local call, call forwarding, and conference call. 8ach feature is generally described in a sequence of stimulus'response pairs, and may include validity checs on inputs, e"act sequencing of operations, responses to abnormal situations, including error handling and recovery, effects of parameters, relationships of inputs to outputs, including input,output sequences and formulas for input to output. 9' Stimu#us Some systems can be best organized by describing their functions in terms of stimuli. *or e"ample, the functions of an automatic aircraft landing system may be organized into sections for loss of power, wind shear, sudden change in roll, vertical velocity e"cessive, etc. 9' Response Some systems can be best organized by describing all the functions in support of the generation of a response. *or e"ample, the functions of a personnel system may be organized into sections corresponding to all functions associated with generating paychecs, all functions associated with generating a current list of employees, etc. 9' >unctiona# 6ierarch' Ohen none of the above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by common inputs, common outputs, or common internal data access. 9ata flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data. /**itiona# $omments Ohenever a new Requirements Specification is contemplated, more than one of the organizational techniques given above may be appropriate. :n such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification. There are many notations, methods, and automated support tools available to aid in the documentation of requirements. *or the most part, their usefulness is a function of organization. *or e"ample, when organizing by mode, finite state machines or state charts may prove helpfulB when organizing by object, object'oriented analysis may prove helpfulB when organizing by feature, stimulus'response sequences may prove helpfulB and when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful. ,var,www,apps,conversion,tmp,scratch-.,//0122.31.doc 4arch /5, /136 7age 36 o f 36