Software Requirements Specifications Document

CS3911

Software Requirements Specification (SRS) Template

Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project.

he document in this file is an annotated outline for specifying software requirements! adapted from the I""" #uide to Software Requirements Specifications $Std %&'()**&+. ailor this to your needs! remo,ing explanatory comments as you go along. -here you decide to omit a section! you might .eep the header! but insert a comment saying why you omit the data.

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page ) of 2*

Software Requirements Specifications Document

CS3911 (Team Number) (Team Name) Software Requirements Specification Document

Version (n)

Date (mm!dd!"""")

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 2 of 2*

Software Requirements Specifications Document

Table of Contents
1# $ntroduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations. 1.4 References 1.5 vervie! % 5 5 5 5 " * " 3 4 4 4 % % % % $ $ $ 1( 1( 1+ 11 12 12 13 13 )1 14 )1 )1 )6 )6 )6 1" )3 )3 )3 )4

&# T'e ()erall Description 2.1 Product Perspective 2.).) System Interfaces 2.).2 Interfaces 2.).& 5ardware Interfaces 2.).1 Software Interfaces 2.).6 7ommunications Interfaces 2.).3 8emory 7onstraints 2.).4 9perations 2.).% Site :daptation Requirements 2.2 Product #unctions 2.3 %ser &'aracteristics 2.4 &onstraints 2.5 Assumptions and Dependencies 2." Apportionin) of Re*uirements. 3# Specific Requirements 3.1 +,ternal -nterfaces 3.2 #unctions 3.3 Performance Re*uirements 3.4 .o)ical Database Re*uirements 3.5 Desi)n &onstraints &.6.) Standards 7ompliance 3." Soft!are System Attributes &.3.) Reliability &.3.2 :,ailability &.3.& Security &.3.1 8aintainability &.3.6 Portability 3./ r)ani0in) t'e Specific Re*uirements &.4.) System 8ode &.4.2 ;ser 7lass &.4.& 9bjects &.4.1 <eature

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page & of 2*

Software Requirements Specifications Document

&.4.6 Stimulus &. 4.3 Response &.4.4 <unctional 5ierarchy 3.1 Additional &omments ,#C'an-e .ana-ement /rocess %#Document 1ppro)als *#Supportin- $nformation )4 )4 )4 1/ 10 10 10

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 1 of 2*

Software Requirements Specifications Document

1# $ntroduction
2'e follo!in) subsections of t'e Soft!are Re*uirements Specifications 3SRS4 document s'ould provide an overvie! of t'e entire SRS. 2'e t'in) to 5eep in mind as you !rite t'is document is t'at you are tellin) !'at t'e system must do 6 so t'at desi)ners can ultimately build it. Do not use t'is document for desi)n777

1#1 /urpose
-dentify t'e purpose of t'is SRS and its intended audience. -n t'is subsection, describe t'e purpose of t'e particular SRS and specify t'e intended audience for t'e SRS.

1#& Scope
-n t'is subsection8 314 -dentify t'e soft!are product3s4 to be produced by name 324 +,plain !'at t'e soft!are product3s4 !ill, and, if necessary, !ill not do 334 Describe t'e application of t'e soft!are bein) specified, includin) relevant benefits, ob9ectives, and )oals 344 :e consistent !it' similar statements in 'i)'er;level specifications if t'ey e,ist 2'is s'ould be an e,ecutive;level summary. Do not enumerate t'e !'ole re*uirements list 'ere.

1#3 Definitions2 1cron"ms2 and 1bbre)iations#

Provide t'e definitions of all terms, acronyms, and abbreviations re*uired to properly interpret t'e SRS. 2'is information may be provided by reference to one or more appendices in t'e SRS or by reference to documents. 2'is information may be provided by reference to an Appendi,.

1#, References
-n t'is subsection8 314 Provide a complete list of all documents referenced else!'ere in t'e SRS 324 -dentify eac' document by title, report number 3if applicable4, date, and publis'in) or)ani0ation 334 Specify t'e sources from !'ic' t'e references can be obtained. 2'is information can be provided by reference to an appendi, or to anot'er document. -f your application uses specific protocols or R#&<s, t'en reference t'em 'ere so desi)ners 5no! !'ere to find t'em.

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 6 of 2*

Software Requirements Specifications Document

1#% ()er)iew
-n t'is subsection8 314 Describe !'at t'e rest of t'e SRS contains 324 +,plain 'o! t'e SRS is or)ani0ed Don<t re'as' t'e table of contents 'ere. Point people to t'e parts of t'e document t'ey are most concerned !it'. &ustomers=potential users care about section 2, developers care about section 3.

&# T'e ()erall Description

Describe t'e )eneral factors t'at affect t'e product and its re*uirements. 2'is section does not state specific re*uirements. -nstead, it provides a bac5)round for t'ose re*uirements, !'ic' are defined in section 3, and ma5es t'em easier to understand. -n a sense, t'is section tells t'e re*uirements in plain +n)lis' for t'e consumption of t'e customer. Section3 !ill contain a specification !ritten for t'e developers.

&#1 /roduct /erspecti)e

Put t'e product into perspective !it' ot'er related products. -f t'e product is independent and totally self;contained, it s'ould be so stated 'ere. -f t'e SRS defines a product t'at is a component of a lar)er system, as fre*uently occurs, t'en t'is subsection relates t'e re*uirements of t'e lar)er system to functionality of t'e soft!are and identifies interfaces bet!een t'at system and t'e soft!are. -f you are buildin) a real system,compare its similarity and differences to ot'er systems in t'e mar5etplace. -f you are doin) a researc';oriented pro9ect, !'at related researc' compares to t'e system you are plannin) to build. A bloc5 dia)ram s'o!in) t'e ma9or components of t'e lar)er system, interconnections, and e,ternal interfaces can be 'elpful. 2'is is not a desi)n or arc'itecture picture. -t is more to provide conte,t, especially if your system !ill interact !it' e,ternal actors. 2'e system you are buildin) s'ould be s'o!n as a blac5 bo,. .et t'e desi)n document present t'e internals. 2'e follo!in) subsections describe 'o! t'e soft!are operates inside various constraints. &#1#1 S"stem $nterfaces .ist eac' system interface and identify t'e functionality of t'e soft!are to accomplis' t'e system re*uirement and t'e interface description to matc' t'e system. 2'ese are e,ternal systems t'at you 'ave to interact !it'. #or instance, if you are buildin) a business application t'at interfaces !it' t'e e,istin) employee payroll system, !'at is t'e AP- to t'at system t'at desi)ner<s !ill need to use>

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 3 of 2*

Software Requirements Specifications Document &#1#& $nterfaces Specify8 314 2'e lo)ical c'aracteristics of eac' interface bet!een t'e soft!are product and its users. 324 All t'e aspects of optimi0in) t'e interface !it' t'e person !'o must use t'e system 2'is is a description of 'o! t'e system !ill interact !it' its users. -s t'ere a ?%-, a command line or some ot'er type of interface> Are t'ere special interface re*uirements> -f you are desi)nin) for t'e )eneral student population for instance, !'at is t'e impact of ADA 3American !it' Disabilities Act4 on your interface> &#1#3 3ardware $nterfaces Specify t'e lo)ical c'aracteristics of eac' interface bet!een t'e soft!are product and t'e 'ard!are components of t'e system. 2'is includes confi)uration c'aracteristics. -t also covers suc' matters as !'at devices are to be supported, 'o! t'ey are to be supported and protocols. 2'is is not a description of 'ard!are re*uirements in t'e sense t'at @2'is pro)ram must run on a Aac !it' "4A of RAAB. 2'is section is for detailin) t'e actual 'ard!are devices your application !ill interact !it' and control. #or instance, if you are controllin) C1( type 'ome devices, !'at is t'e interface to t'ose devices> Desi)ners s'ould be able to loo5 at t'is and 5no! !'at 'ard!are t'ey need to !orry about in t'e desi)n. Aany business type applications !ill 'ave no 'ard!are interfaces. -f none, 9ust state @2'e system 'as no 'ard!are interface re*uirementsB -f you 9ust delete sections t'at are not applicable, t'en readers do not 5no! if8 a. t'is does not apply or b. you for)ot to include t'e section in t'e first place. &#1#, Software $nterfaces Specify t'e use of ot'er re*uired soft!are products and interfaces !it' ot'er application systems. #or eac' re*uired soft!are product, include8 314 Dame 324 Anemonic 334 Specification number 344 Eersion number 354 Source #or eac' interface, provide8 314 Discussion of t'e purpose of t'e interfacin) soft!are as related to t'is soft!are product 324 Definition of t'e interface in terms of messa)e content and format Fere !e document t'e AP-s, versions of soft!are t'at !e do not 'ave to !rite, but t'at our system 'as to use. #or instance if your customer uses SG. Server / and you are re*uired to use t'at, t'en you need to specify i.e. 2.1.4.1 Aicrosoft SG. Server /. 2'e system must use SG. Server as its database component. &ommunication !it' t'e D: is t'rou)' D:& connections. 2'e system must provide SG. data table definintions to be provided to t'e company D:A for setup.
/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 4 of 2*

Software Requirements Specifications Document

A 5ey point to remember is t'at you do D 2 !ant to specify soft!are 'ere t'at you t'in5 !ould be )ood to use. 2'is is only for customer-specified systems t'at you have to interact !it'. &'oosin) SG. Server / as a D: !it'out a customer re*uirement is a Desi)n c'oice, not a re*uirement. 2'is is a subtle but important point to !ritin) )ood re*uirements and not over;constrainin) t'e desi)n. &#1#% Communications $nterfaces Specify t'e various interfaces to communications suc' as local net!or5 protocols, etc. 2'ese are protocols you !ill need to directly interact !it'. -f you 'appen to use !eb services transparently to your application t'en do not list it 'ere. -f you are usin) a custom protocol to communicate bet!een systems, t'en document t'at protocol 'ere so desi)ners 5no! !'at to desi)n. -f it is a standard protocol, you can reference an e,istin) document or R#&. &#1#* .emor" Constraints Specify any applicable c'aracteristics and limits on primary and secondary memory. Don<t 9ust ma5e up somet'in) 'ere. -f all t'e customer<s mac'ines 'ave only 121H of RAA, t'en your tar)et desi)n 'as )ot to come in under 121H so t'ere is an actual re*uirement. Iou could also cite mar5et researc' 'ere for s'rin5;!rap type applications @#ocus )roups 'ave determined t'at our tar)et mar5et 'as bet!een 25";512A of RAA, t'erefore t'e desi)n footprint s'ould not e,ceed 25"A.B -f t'ere are no memory constraints, so state. &#1#4 (perations Specify t'e normal and special operations re*uired by t'e user suc' as8 314 2'e various modes of operations in t'e user or)ani0ation 324 Periods of interactive operations and periods of unattended operations 334 Data processin) support functions 344 :ac5up and recovery operations 3Dote8 2'is is sometimes specified as part of t'e %ser -nterfaces section.4 -f you separate t'is from t'e %- stuff earlier, t'en cover business process type stuff t'at !ould impact t'e desi)n. #or instance, if t'e company brin)s all t'eir systems do!n at midni)'t for data bac5up t'at mi)'t impact t'e desi)n. 2'ese are all t'e !or5 tas5s t'at impact t'e desi)n of an application, but !'ic' mi)'t not be located in soft!are. &#1#0 Site 1daptation Requirements -n t'is section8 314 Define t'e re*uirements for any data or initiali0ation se*uences t'at are specific to a )iven site, mission, or operational mode

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page % of 2*

Software Requirements Specifications Document 324 Specify t'e site or mission;related features t'at s'ould be modified to adapt t'e soft!are to a particular installation -f any modifications to t'e customer<s !or5 area !ould be re*uired by your system, t'en document t'at 'ere. #or instance, @A 1((H! bac5up )enerator and 1(((( :2% air conditionin) system must be installed at t'e user site prior to soft!are installationB. 2'is could also be soft!are;specific li5e, @De! data tables created for t'is system must be installed on t'e company<s e,istin) D: server and populated prior to system activation.B Any e*uipment t'e customer !ould need to buy or any soft!are setup t'at needs to be done so t'at your system !ill install and operate correctly s'ould be documented 'ere.

&#& /roduct 5unctions

Provide a summary of t'e ma9or functions t'at t'e soft!are !ill perform. Sometimes t'e function summary t'at is necessary for t'is part can be ta5en directly from t'e section of t'e 'i)'er;level specification 3if one e,ists4 t'at allocates particular functions to t'e soft!are product. #or clarity8 314 2'e functions s'ould be or)ani0ed in a !ay t'at ma5es t'e list of functions understandable to t'e customer or to anyone else readin) t'e document for t'e first time. 324 2e,tual or )rap'ic met'ods can be used to s'o! t'e different functions and t'eir relations'ips. Suc' a dia)ram is not intended to s'o! a desi)n of a product but simply s'o!s t'e lo)ical relations'ips amon) variables. AF, #inally t'e real meat of section 2. 2'is describes t'e functionality of t'e system in t'e lan)ua)e of t'e customer. J'at specifically does t'e system t'at !ill be desi)ned 'ave to do> Dra!in)s are )ood, but remember t'is is a description of !'at t'e system needs to do, not 'o! you are )oin) to build it. 32'at comes in t'e desi)n document4.

&#3 6ser C'aracteristics

Describe t'ose )eneral c'aracteristics of t'e intended users of t'e product includin) educational level, e,perience, and tec'nical e,pertise. Do not state specific re*uirements but rat'er provide t'e reasons !'y certain specific re*uirements are later specified in section 3. J'at is it about your potential user base t'at !ill impact t'e desi)n> 2'eir e,perience and comfort !it' tec'nolo)y !ill drive %- desi)n. t'er c'aracteristics mi)'t actually influence internal desi)n of t'e system.

&#, Constraints
Provide a )eneral description of any ot'er items t'at !ill limit t'e developerKs options. 2'ese can include8
/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page * of 2*

Software Requirements Specifications Document

314 Re)ulatory policies 324 Fard!are limitations 3for e,ample, si)nal timin) re*uirements4 334 -nterface to ot'er applications 344 Parallel operation 354 Audit functions 3"4 &ontrol functions 3/4 Fi)'er;order lan)ua)e re*uirements $%+ Si)nal 'ands'a5e protocols 3for e,ample, C D;C ##, A&H;DA&H4 $*+ Reliability re*uirements 31(4 &riticality of t'e application 3114 Safety and security considerations 2'is section captures non;functional re*uirements in t'e customers lan)ua)e. A more formal presentation of t'ese !ill occur in section 3.

&#% 1ssumptions and Dependencies

.ist eac' of t'e factors t'at affect t'e re*uirements stated in t'e SRS. 2'ese factors are not desi)n constraints on t'e soft!are but are, rat'er, any c'an)es to t'em t'at can affect t'e re*uirements in t'e SRS. #or e,ample, an assumption mi)'t be t'at a specific operatin) system !ould be available on t'e 'ard!are desi)nated for t'e soft!are product. -f, in fact, t'e operatin) system !ere not available, t'e SRS !ould t'en 'ave to c'an)e accordin)ly. 2'is section is catc';all for everyt'in) else t'at mi)'t influence t'e desi)n of t'e system and t'at did not fit in any of t'e cate)ories above.

&#* 1pportionin- of Requirements#

-dentify re*uirements t'at may be delayed until future versions of t'e system. After you loo5 at t'e pro9ect plan and 'ours available, you may reali0e t'at you 9ust cannot )et everyt'in) done. 2'is section divides t'e re*uirements into different sections for development and delivery. Remember to c'ec5 !it' t'e customer 6 t'ey s'ould prioriti0e t'e re*uirements and decide !'at does and does not )et done. 2'is can also be useful if you are usin) an iterative life cycle model to specify !'ic' re*uirements !ill map to !'ic' interation.

3# Specific Requirements
2'is section contains all t'e soft!are re*uirements at a level of detail sufficient to enable desi)ners to desi)n a system to satisfy t'ose re*uirements, and testers to test t'at t'e system satisfies t'ose re*uirements. 2'rou)'out t'is section, every stated re*uirement s'ould be e,ternally perceivable by users, operators, or ot'er e,ternal systems. 2'ese re*uirements s'ould include at a minimum a description of every input 3stimulus4 into t'e system, every output 3response4 from t'e system and all functions performed by t'e system in response to an input or in support of an output. 2'e follo!in) principles apply8

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )' of 2*

Software Requirements Specifications Document 314 Specific re*uirements s'ould be stated !it' all t'e c'aracteristics of a )ood SRS correct unambi)uous complete consistent ran5ed for importance and=or stability verifiable modifiable traceable 324 Specific re*uirements s'ould be cross;referenced to earlier documents t'at relate 334 All re*uirements s'ould be uni*uely identifiable 3usually via numberin) li5e 3.1.2.34 344 &areful attention s'ould be )iven to or)ani0in) t'e re*uirements to ma,imi0e readability 3Several alternative or)ani0ations are )iven at end of document4 :efore e,aminin) specific !ays of or)ani0in) t'e re*uirements it is 'elpful to understand t'e various items t'at comprise re*uirements as described in t'e follo!in) subclasses. 2'is section reiterates section 2, but is for developers not t'e customer. 2'e customer buys in !it' section 2, t'e desi)ners use section 3 to desi)n and build t'e actual application. Remember t'is is not desi)n. Do not re*uire specific soft!are pac5a)es, etc unless t'e customer specifically re*uires t'em. Avoid over;constrainin) your desi)n. %se proper terminolo)y8 2'e system s'allL A re*uired, must 'ave feature 2'e system s'ouldL A desired feature, but may be deferred til later 2'e system mayL An optional, nice;to;'ave feature t'at may never ma5e it to implementation. +ac' re*uirement s'ould be uni*uely identified for traceability. %sually, t'ey are numbered 3.1, 3.1.1, 3.1.2.1 etc. +ac' re*uirement s'ould also be testable. Avoid imprecise statements li5e, @2'e system s'all be easy to useB Jell no 5iddin), !'at does t'at mean> Avoid @mot'er'ood and apple pieB type statements, @2'e system s'all be developed usin) )ood soft!are en)ineerin) practiceB Avoid e,amples, 2'is is a specification, a desi)ner s'ould be able to read t'is spec and build t'e system !it'out bot'erin) t'e customer a)ain. Don<t say t'in)s li5e, @2'e system s'all accept confi)uration information suc' as name and address.B 2'e desi)ner doesn<t 5no! if t'at is t'e only t!o data elements or if t'ere are 2((. .ist every piece of information t'at is re*uired so t'e desi)ners can build t'e ri)'t %- and data tables.

3#1 78ternal $nterfaces

2'is contains a detailed description of all inputs into and outputs from t'e soft!are system. -t complements t'e interface descriptions in section 2 but does not repeat

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )) of 2*

Software Requirements Specifications Document information t'ere. Remember section 2 presents information oriented to t'e customer=user !'ile section 3 is oriented to t'e developer. -t contains bot' content and format as follo!s8 Dame of item Description of purpose Source of input or destination of output Ealid ran)e, accuracy and=or tolerance %nits of measure 2imin) Relations'ips to ot'er inputs=outputs Screen formats=or)ani0ation Jindo! formats=or)ani0ation Data formats &ommand formats +nd messa)es

3#& 5unctions
#unctional re*uirements define t'e fundamental actions t'at must ta5e place in t'e soft!are in acceptin) and processin) t'e inputs and in processin) and )eneratin) t'e outputs. 2'ese are )enerally listed as @s'allB statements startin) !it' M2'e system s'allL 2'ese include8 Ealidity c'ec5s on t'e inputs +,act se*uence of operations Responses to abnormal situation, includin) verflo! &ommunication facilities +rror 'andlin) and recovery +ffect of parameters Relations'ip of outputs to inputs, includin) -nput= utput se*uences #ormulas for input to output conversion

-t may be appropriate to partition t'e functional re*uirements into sub;functions or sub; processes. 2'is does not imply t'at t'e soft!are desi)n !ill also be partitioned t'at !ay.

3#3 /erformance Requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )2 of 2*

Software Requirements Specifications Document

2'is subsection specifies bot' t'e static and t'e dynamic numerical re*uirements placed on t'e soft!are or on 'uman interaction !it' t'e soft!are, as a !'ole. Static numerical re*uirements may include8 3a4 2'e number of terminals to be supported 3b4 2'e number of simultaneous users to be supported 3c4 Amount and type of information to be 'andled Static numerical re*uirements are sometimes identified under a separate section entitled capacity. Dynamic numerical re*uirements may include, for e,ample, t'e numbers of transactions and tas5s and t'e amount of data to be processed !it'in certain time periods for bot' normal and pea5 !or5load conditions. All of t'ese re*uirements s'ould be stated in measurable terms. #or e,ample, $5N of t'e transactions s'all be processed in less t'an 1 second rat'er t'an, An operator s'all not 'ave to !ait for t'e transaction to complete. 3Dote8 Dumerical limits applied to one specific function are normally specified as part of t'e processin) subpara)rap' description of t'at function.4

3#, 9o-ical Database Requirements

2'is section specifies t'e lo)ical re*uirements for any information t'at is to be placed into a database. 2'is may include8 2ypes of information used by various functions #re*uency of use Accessin) capabilities Data entities and t'eir relations'ips -nte)rity constraints Data retention re*uirements

-f t'e customer provided you !it' data models, t'ose can be presented 'ere. +R dia)rams 3or static class dia)rams4 can be useful 'ere to s'o! comple, data relations'ips. Remember a dia)ram is !ort' a t'ousand !ords of confusin) te,t.

3#% Desi-n Constraints

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )& of 2*

Software Requirements Specifications Document

Specify desi)n constraints t'at can be imposed by ot'er standards, 'ard!are limitations, etc. 3#%#1 Standards Compliance Specify t'e re*uirements derived from e,istin) standards or re)ulations. 2'ey mi)'t include8 314 Report format 324 Data namin) 334 Accountin) procedures 344 Audit 2racin) #or e,ample, t'is could specify t'e re*uirement for soft!are to trace processin) activity. Suc' traces are needed for some applications to meet minimum re)ulatory or financial standards. An audit trace re*uirement may, for e,ample, state t'at all c'an)es to a payroll database must be recorded in a trace file !it' before and after values.

3#* Software S"stem 1ttributes

2'ere are a number of attributes of soft!are t'at can serve as re*uirements. -t is important t'at re*uired attributes by specified so t'at t'eir ac'ievement can be ob9ectively verified. 2'e follo!in) items provide a partial list of e,amples. 2'ese are also 5no!n as non;functional re*uirements or *uality attributes. 2'ese are c'aracteristics t'e system must possess, but t'at pervade 3or cross;cut4 t'e desi)n. 2'ese re*uirements 'ave to be testable 9ust li5e t'e functional re*uirements. -ts easy to start p'ilosop'i0in) 'ere, but 5eep it specific. 3#*#1 Reliabilit" Specify t'e factors re*uired to establis' t'e re*uired reliability of t'e soft!are system at time of delivery. -f you 'ave A2:# re*uirements, e,press t'em 'ere. 2'is doesn<t refer to 9ust 'avin) a pro)ram t'at does not cras'. 2'is 'as a specific en)ineerin) meanin). 3#*#& 1)ailabilit" Specify t'e factors re*uired to )uarantee a defined availability level for t'e entire system suc' as c'ec5point, recovery, and restart. 2'is is some!'at related to reliability. Some systems run only infre*uently on;demand 3li5e AS Jord4. Some systems 'ave to run 24=/ 3li5e an e;commerce !eb site4. 2'e re*uired availability !ill )reatly impact t'e desi)n. J'at are t'e re*uirements for system recovery from a failure> @2'e system s'all allo! users to restart t'e application after failure !it' t'e loss of at most 12 c'aracters of inputB.

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )1 of 2*

Software Requirements Specifications Document 3#*#3 Securit" Specify t'e factors t'at !ould protect t'e soft!are from accidental or malicious access, use, modification, destruction, or disclosure. Specific re*uirements in t'is area could include t'e need to8 %tili0e certain crypto)rap'ic tec'ni*ues Heep specific lo) or 'istory data sets Assi)n certain functions to different modules Restrict communications bet!een some areas of t'e pro)ram &'ec5 data inte)rity for critical variables 3#*#, .aintainabilit" Specify attributes of soft!are t'at relate to t'e ease of maintenance of t'e soft!are itself. 2'ere may be some re*uirement for certain modularity, interfaces, comple,ity, etc. Re*uirements s'ould not be placed 'ere 9ust because t'ey are t'ou)'t to be )ood desi)n practices. -f someone else !ill maintain t'e system 3#*#% /ortabilit" Specify attributes of soft!are t'at relate to t'e ease of portin) t'e soft!are to ot'er 'ost mac'ines and=or operatin) systems. 2'is may include8 Percenta)e of components !it' 'ost;dependent code Percenta)e of code t'at is 'ost dependent %se of a proven portable lan)ua)e %se of a particular compiler or lan)ua)e subset %se of a particular operatin) system nce t'e relevant c'aracteristics are selected, a subsection s'ould be !ritten for eac', e,plainin) t'e rationale for includin) t'is c'aracteristic and 'o! it !ill be tested and measured. A c'art li5e t'is mi)'t be used to identify t'e 5ey c'aracteristics 3ratin) t'em Fi)' or Aedium4, t'en identifyin) !'ic' are preferred !'en tradin) off desi)n or implementation decisions 3!it' t'e -D of t'e preferred one indicated in t'e c'art to t'e ri)'t4. 2'e c'art belo! is optional 3it can be confusin)4 and is for demonstratin) tradeoff analysis bet!een different non;functional re*uirements. F=A=. is t'e relative priority of t'at non;functional re*uirement. $D ) 2 & 1 6 3 C'aracteristic 7orrectness "fficiency <lexibility Integrity/Security Interoperability 8aintainability 3!.!9 1 & 3 , % * 4 0 9 1+ 11 1&

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )6 of 2*

Software Requirements Specifications Document 4 % * )' )) )2 Portability Reliability Reusability estability ;sability :,ailability

Definitions of t'e *uality c'aracteristics not defined in t'e para)rap's above follo!. O &orrectness ; e,tent to !'ic' pro)ram satisfies specifications, fulfills user<s mission ob9ectives O +fficiency ; amount of computin) resources and code re*uired to perform function O #le,ibility ; effort needed to modify operational pro)ram O -nteroperability ; effort needed to couple one system !it' anot'er O Reliability ; e,tent to !'ic' pro)ram performs !it' re*uired precision O Reusability ; e,tent to !'ic' it can be reused in anot'er application O 2estability ; effort needed to test to ensure performs as intended O %sability ; effort re*uired to learn, operate, prepare input, and interpret output 2F+ # .. J-D? 33./4 is not really a section, it is tal5in) about 'o! to or)ani0e re*uirements you !rite in section 3.2. At t'e end of t'is template t'ere are a bunc' of alternative or)ani0ations for section 3.2. &'oose t'e D+ best for t'e system you are !ritin) t'e re*uirements for.

3#4 (r-ani:in- t'e Specific Requirements

#or anyt'in) but trivial systems t'e detailed re*uirements tend to be e,tensive. #or t'is reason, it is recommended t'at careful consideration be )iven to or)ani0in) t'ese in a manner optimal for understandin). 2'ere is no one optimal or)ani0ation for all systems. Different classes of systems lend t'emselves to different or)ani0ations of re*uirements in section 3. Some of t'ese or)ani0ations are described in t'e follo!in) subclasses. 3#4#1 S"stem .ode Some systems be'ave *uite differently dependin) on t'e mode of operation. J'en or)ani0in) by mode t'ere are t!o possible outlines. 2'e c'oice depends on !'et'er interfaces and performance are dependent on mode. 3#4#& 6ser Class Some systems provide different sets of functions to different classes of users. 3#4#3 (b;ects

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )3 of 2*

Software Requirements Specifications Document b9ects are real;!orld entities t'at 'ave a counterpart !it'in t'e system. Associated !it' eac' ob9ect is a set of attributes and functions. 2'ese functions are also called services, met'ods, or processes. Dote t'at sets of ob9ects may s'are attributes and services. 2'ese are )rouped to)et'er as classes. 3#4#, 5eature A feature is an e,ternally desired service by t'e system t'at may re*uire a se*uence of inputs to effect t'e desired result. +ac' feature is )enerally described in as se*uence eof stimulus;response pairs. 3#4#% Stimulus Some systems can be best or)ani0ed by describin) t'eir functions in terms of stimuli. 3# 4#* Response Some systems can be best or)ani0ed by describin) t'eir functions in support of t'e )eneration of a response. 3#4#4 5unctional 3ierarc'" J'en none of 'e above or)ani0ational sc'emes prove 'elpful, t'e overall functionality can be or)ani0ed into a 'ierarc'y of functions or)ani0ed by eit'er common inputs, common outputs, or common internal data access. Data flo! dia)rams and data dictionaries can be use dot s'o! t'e relations'ips bet!een and amon) t'e functions and data.

3#0 1dditional Comments

J'enever a ne! SRS is contemplated, more t'an one of t'e or)ani0ational tec'ni*ues )iven in 3./ may be appropriate. -n suc' cases, or)ani0e t'e specific re*uirements for multiple 'ierarc'ies tailored to t'e specific needs of t'e system under specification. 2'ree are many notations, met'ods, and automated support tools available to aid in t'e documentation of re*uirements. #or t'e most part, t'eir usefulness is a function of or)ani0ation. #or e,ample, !'en or)ani0in) by mode, finite state mac'ines or state c'arts may prove 'elpfulP !'en or)ani0in) by ob9ect, ob9ect;oriented analysis may prove 'elpfulP !'en or)ani0in) by feature, stimulus;response se*uences may prove 'elpfulP !'en or)ani0in) by functional 'ierarc'y, data flo! dia)rams and data dictionaries may prove 'elpful. -n any of t'e outlines belo!, t'ose sections called @#unctional Re*uirement iB may be described in native lan)ua)e, in pseudocode, in a system definition lan)ua)e, or in four subsections titled8 -ntroduction, -nputs, Processin), utputs.
/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )4 of 2*

Software Requirements Specifications Document

,# C'an-e .ana-ement /rocess

-dentify t'e c'an)e mana)ement process to be used to identify, lo), evaluate, and update t'e SRS to reflect c'an)es in pro9ect scope and re*uirements. Fo! are you )oin) to control c'an)es to t'e re*uirements. &an t'e customer 9ust call up and as5 for somet'in) ne!> Does your team 'ave to reac' consensus> Fo! do c'an)es to re*uirements )et submitted to t'e team> #ormally in !ritin), email or p'one call>

%# Document 1ppro)als
-dentify t'e approvers of t'e SRS document. Approver name, si)nature, and date s'ould be used.

*# Supportin- $nformation
2'e supportin) information ma5es t'e SRS easier to use. -t includes8 2able of &ontents -nde, Appendices

2'e Appendices are not al!ays considered part of t'e actual re*uirements specification and are not al!ays necessary. 2'ey may include8 3a4 Sample -= formats, descriptions of cost analysis studies, results of user surveys 3b4 Supportin) or bac5)round information t'at can 'elp t'e readers of t'e SRS 3c4 A description of t'e problems to be solved by t'e soft!are 3d4 Special pac5a)in) instructions for t'e code and t'e media to meet security, e,port, initial loadin), or ot'er re*uirements J'en Appendices are included, t'e SRS s'ould e,plicitly state !'et'er or not t'e Appendices are to be considered part of t'e re*uirements. ables on the following pages pro,ide alternate ways to structure section & on the specific requirements. =ou should pic. the best one of these to organi>e section & requirements.

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )% of 2*

Software Requirements Specifications Document

(utline for SRS Section 3 (r-ani:ed b" mode Version 1 &. Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 <unctional requirements &.2.) 8ode ) &.2.).) <unctional requirement ).) ..... &.2.). n <unctional requirement ).n &.2.2 8ode 2 ..... &.2.m 8ode m &.2.m.) <unctional requirement m.) ..... &.2.m.n <unctional requirement m.n &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page )* of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" mode Version & &. Specific Requirements &.) <unctional Requirements &.).) 8ode ) &.).).) "xternal interfaces &.).).) ;ser interfaces &.).).2 5ardware interfaces &.).).& Software interfaces &.).).1 7ommunications interfaces &.).).2 <unctional Requirement &.).).2.) <unctional requirement ) ..... &.).).2. n <unctional requirement n &.).).& Performance &.).2 8ode 2 ..... &.).m 8ode m &.2 Design constraints &.& Software system attributes &.1 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 2' of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" user class (i#e# different t"pes of users <=S"stem 1dminstrators2 .ana-ers2 Cler>s2 etc#) &. Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 <unctional requirements &.2.) ;ser class ) &.2.).) <unctional requirement ).) ..... &.2.). n <unctional requirement ).n &.2.2 ;ser class 2 ..... &.2.m ;ser class m &.2.m.) <unctional requirement m.) ..... &.2.m.n <unctional requirement m.n &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 2) of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" ob;ect (?ood if "ou did an ob;ect<oriented anal"sis as part of "our requirements) & Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 7lasses/9bjects &.2.) 7lass/9bject ) &.2.).) :ttributes $direct or inherited+ &.2.).).) :ttribute ) ..... &.2.).). n :ttribute n &.2.).2 <unctions $ser,ices! methods! direct or inherited+ &.2.).2.) <unctional requirement ).) ..... &.2.).2. m <unctional requirement ).m &.2.).& 8essages $communications recei,ed or sent+ &.2.2 7lass/9bject 2 ..... &.2.p 7lass/9bject p &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 22 of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" feature (?ood w'en t'ere are clearl" delimited feature sets#

& Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 System features &.2.) System <eature ) &.2.).) Introduction/Purpose of feature &.2.).2 Stimulus/Response sequence &.2.).& :ssociated functional requirements &.2.).&.) <unctional requirement ) ..... &.2.).&. n <unctional requirement n &.2.2 System <eature 2 ..... &.2.m System <eature m ..... &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 2& of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" stimulus (?ood for e)ent dri)en s"stems w'ere t'e e)ents form lo-ical -roupin-s) & Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 <unctional requirements &.2.) Stimulus ) &.2.).) <unctional requirement ).) ..... &.2.). n <unctional requirement ).n &.2.2 Stimulus 2 ..... &.2.m Stimulus m &.2. m.) <unctional requirement m.) ..... &.2. m.n <unctional requirement m.n &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 21 of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" response (?ood for e)ent dri)en s"stems w'ere t'e responses form lo-ical -roupin-s) & Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 <unctional requirements &.2.) Response ) &.2.).) <unctional requirement ).) ..... &.2.). n <unctional requirement ).n &.2.2 Response 2 ..... &.2.m Response m &.2. m.) <unctional requirement m.) ..... &.2. m.n <unctional requirement m.n &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 26 of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" functional 'ierarc'" (?ood if "ou 'a)e done structured anal"sis as part of "our desi-n#) & Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 <unctional requirements &.2.) Information flows &.2.).) Data flow diagram ) &.2.).).) Data entities &.2.).).2 Pertinent processes &.2.).).& opology &.2.).2 Data flow diagram 2 &.2.).2.) Data entities &.2.).2.2 Pertinent processes &.2.).2.& opology ..... &.2.).n Data flow diagram n &.2.).n.) Data entities &.2.).n.2 Pertinent processes &.2.).n.& opology &.2.2 Process descriptions &.2.2.) Process ) &.2.2.).) Input data entities &.2.2.).2 :lgorithm or formula of process &.2.2.).& :ffected data entities &.2.2.2 Process 2 &.2.2.2.) Input data entities &.2.2.2.2 :lgorithm or formula of process &.2.2.2.& :ffected data entities .?. &.2.2.m Process m &.2.2.m.) Input data entities &.2.2.m.2 :lgorithm or formula of process &.2.2. m.& :ffected data entities &.2.& Data construct specifications &.2.&.) 7onstruct ) &.2.&.).) Record type &.2.&.).2 7onstituent fields &.2.&.2 7onstruct 2 &.2.&.2.) Record type &.2.&.2.2 7onstituent fields ?..
/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 23 of 2*

Software Requirements Specifications Document &.2.&. p 7onstruct p &.2.&. p.) Record type &.2.&. p.2 7onstituent fields &.2.1 Data dictionary &.2.1.) Data element ) &.2.1.).) @ame &.2.1.).2 Representation &.2.1.).& ;nits/<ormat &.2.1.).1 Precision/:ccuracy &.2.1.).6 Range &.2.1.2 Data element 2 &.2.1.2.) @ame &.2.1.2.2 Representation &.2.1.2.& ;nits/<ormat &.2.1.2.1 Precision/:ccuracy &.2.1.2.6 Range ?.. &.2.1.* Data element * &.2.1. *.) @ame &.2.1. *.2 Representation &.2.1. *.& ;nits/<ormat &.2.1. *.1 Precision/:ccuracy &.2.1. *.6 Range &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 24 of 2*

Software Requirements Specifications Document (utline for SRS Section 3 S'owin- multiple or-ani:ations (Can@t decideA T'en -lob it all to-et'er) & Specific Requirements &.) "xternal interface requirements &.).) ;ser interfaces &.).2 5ardware interfaces &.).& Software interfaces &.).1 7ommunications interfaces &.2 <unctional requirements &.2.) ;ser class ) &.2.).) <eature ).) &.2.).).) Introduction/Purpose of feature &.2.).).2 Stimulus/Response sequence &.2.).).& :ssociated functional requirements &.2.).2 <eature ).2 &.2.).2.) Introduction/Purpose of feature &.2.).2.2 Stimulus/Response sequence &.2.).2.& :ssociated functional requirements ?.. &.2.).m <eature ).m &.2.).m.) Introduction/Purpose of feature &.2.).m.2 Stimulus/Response sequence &.2.). m.& :ssociated functional requirements &.2.2 ;ser class 2 ..... &.2.n ;ser class n ..... &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 2% of 2*

Software Requirements Specifications Document (utline for SRS Section 3 (r-ani:ed b" 6se Case (?ood w'en followin- 6.9 de)elopment) &. Specific Requirements &.) "xternal :ctor Descriptions &.).) 5uman :ctors &.).2 5ardware :ctors &.).& Software System :ctors &.2 ;se 7ase Descriptions &.2.) ;se 7ase ) &.2.2 ;se 7ase 2 &.2.n ;se 7ase n &.& Performance Requirements &.1 Design 7onstraints &.6 Software system attributes &.3 9ther requirements

/,ar/www/apps/con,ersion/tmp/scratch01/2)))12&1*.doc '2/)&/)1
f

Page 2* of 2*