Vous êtes sur la page 1sur 27

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.

The document in this file is an annotated outline for specifying software requirements, adapted from the IEEE uide to !oftware "equirements !pecifications #!td $%&'())%*. Tailor 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.

Agency Name

Project Name Software Requirements Specification Document

ersion! (n)

Date! (mm"dd"yyyy)

Document #istory and Distribution

1. Revision History
Revision # Revision Date Description of Change Author

2. Distribution
Recipient Name Recipient Organization Distribution Method

Table of $ontents
%& 'ntroduction 1.1Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations. 1.4 References 1.5 vervie! % 1 1 1 1 1 % 2 . . . . % % % % 3 4 4 4 5 5 & & 5 . $ $ $ $ $ 10 (& (& (& (( (( (( ((

(& T)e *+erall Description 2.1 Product Perspective ..(.( !ystem Interfaces ..(.. Interfaces ..(.% /ardware Interfaces ..(.0 !oftware Interfaces ..(.1 2ommunications Interfaces ..(.3 4emory 2onstraints ..(.5 6perations ..(.$ !ite 7daptation "equirements 2.2 Product "unctions 2.3 #ser $%aracteristics 2.4 $onstraints 2.5 Assumptions and Dependencies 2.& Apportionin' of Re(uirements. ,& 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 %.1.( !tandards 2ompliance 3.& Soft!are System Attributes %.3.( "eliability %.3.. 7+ailability %.3.% !ecurity %.3.0 4aintainability %.3.1 Portability 3.- r'ani/in' t%e Specific Re(uirements %.5.( !ystem 4ode %.5.. 8ser 2lass %.5.% 6bjects %.5.0 9eature %.5.1 !timulus %. 5.3 "esponse %.5.5 9unctional /ierarchy

3.. Additional $omments .&$)ange /anagement Process -&Document Appro+als 0&Supporting 'nformation

11 %% %( %(

%& 'ntroduction
1%e follo!in' subsections of t%e Soft!are Re(uirements Specifications 2SRS3 document s%ould provide an overvie! of t%e entire SRS.

%&% Purpose
+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.

%&( Scope
+n t%is subsection4 213 +dentify t%e soft!are product2s3 to be produced by name 223 )*plain !%at t%e soft!are product2s3 !ill, and, if necessary, !ill not do 233 Describe t%e application of t%e soft!are bein' specified, includin' relevant benefits, ob5ectives, and 'oals 243 6e consistent !it% similar statements in %i'%er7level specifications if t%ey e*ist

%&, Definitions1 Acronyms1 and Abbre+iations&


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

%&. References
+n t%is subsection4 213 Provide a complete list of all documents referenced else!%ere in t%e SRS 223 +dentify eac% document by title, report number 2if applicable3, date, and publis%in' or'ani/ation 233 Specify t%e sources from !%ic% t%e references can be obtained. 1%is information can be provided by reference to an appendi* or to anot%er document.

%&- *+er+iew
+n t%is subsection4 213 Describe !%at t%e rest of t%e SRS contains 223 )*plain %o! t%e SRS is or'ani/ed

(& T)e *+erall Description

Describe t%e 'eneral factors t%at affect t%e product and its re(uirements. 1%is section does not state specific re(uirements. +nstead, it provides a bac8'round for t%ose re(uirements, !%ic% are defined in section 3, and ma8es t%em easier to understand.

(&% Product Perspecti+e


Put t%e product into perspective !it% ot%er related products. +f t%e product is independent and totally self7contained, 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. A bloc8 dia'ram s%o!in' t%e ma5or components of t%e lar'er system, interconnections, and e*ternal interfaces can be %elpful. 1%e follo!in' subsections describe %o! t%e soft!are operates inside various constraints. (&%&% System '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. (&%&( 'nterfaces Specify4 213 1%e lo'ical c%aracteristics of eac% interface bet!een t%e soft!are product and its users 223 All t%e aspects of optimi/in' t%e interface !it% t%e person !%o must use t%e system (&%&, #ardware '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. 1%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.

(&%&. 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, include4 213 9ame 223 :nemonic 233 Specification number 243 ;ersion number 253 Source "or eac% interface, provide4 213 Discussion of t%e purpose of t%e interfacin' soft!are as related to t%is soft!are product 223 Definition of t%e interface in terms of messa'e content and format (&%&- $ommunications 'nterfaces Specify t%e various interfaces to communications suc% as local net!or8 protocols, etc. (&%&0 /emory $onstraints Specify any applicable c%aracteristics and limits on primary and secondary memory. (&%&2 *perations Specify t%e normal and special operations re(uired by t%e user suc% as4 213 1%e various modes of operations in t%e user or'ani/ation 223 Periods of interactive operations and periods of unattended operations 233 Data processin' support functions 243 6ac8up and recovery operations 29ote4 1%is is sometimes specified as part of t%e #ser +nterfaces section.3 (&%&3 Site Adaptation Requirements +n t%is section4 213 Define t%e re(uirements for any data or initiali/ation se(uences t%at are specific to a 'iven site, mission, or operational mode 223 Specify t%e site or mission7related features t%at s%ould be modified to adapt t%e soft!are to a particular installation

(&( Product 4unctions


Provide a summary of t%e ma5or functions t%at t%e soft!are !ill perform. Sometimes t%e function summary t%at is necessary for t%is part can be ta8en directly from t%e section of t%e %i'%er7level specification 2if one e*ists3 t%at allocates particular functions to t%e soft!are product.

"or clarity4 213 1%e functions s%ould be or'ani/ed in a !ay t%at ma8es t%e list of functions understandable to t%e customer or to anyone else readin' t%e document for t%e first time. 223 1e*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.

(&, 5ser $)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.

(&. $onstraints
Provide a 'eneral description of any ot%er items t%at !ill limit t%e developer<s options. 1%ese can include4 213 Re'ulatory policies 223 =ard!are limitations 2for e*ample, si'nal timin' re(uirements3 233 +nterface to ot%er applications 243 Parallel operation 253 Audit functions 2&3 $ontrol functions 2-3 =i'%er7order lan'ua'e re(uirements #$* Si'nal %ands%a8e protocols 2for e*ample, > 97> "", A$?79A$?3 #)* Reliability re(uirements 2103 $riticality of t%e application 2113 Safety and security considerations

(&- Assumptions and Dependencies


,ist eac% of t%e factors t%at affect t%e re(uirements stated in t%e SRS. 1%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.

(&0 Apportioning of Requirements&


+dentify re(uirements t%at may be delayed until future versions of t%e system.

,& Specific Requirements


1%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. 1%rou'%out t%is section, every stated re(uirement s%ould be e*ternally perceivable by users, operators, or ot%er e*ternal systems. 1%ese re(uirements s%ould include at a minimum a description of every input 2stimulus3 into t%e system, every output 2response3 from t%e system and all functions performed by t%e system in response to an input or in support of an output. 1%e follo!in' principles apply4 213 Specific re(uirements s%ould be stated !it% all t%e c%aracteristics of a 'ood SRS correct unambi'uous complete consistent ran8ed for importance and@or stability verifiable modifiable traceable 223 Specific re(uirements s%ould be cross7referenced to earlier documents t%at relate 233 All re(uirements s%ould be uni(uely identifiable 243 $areful attention s%ould be 'iven to or'ani/in' t%e re(uirements to ma*imi/e readability 6efore e*aminin' specific !ays of or'ani/in' 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.

,&% 67ternal 'nterfaces


1%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 information t%ere. +t contains bot% content and format as follo!s4 9ame of item Description of purpose Source of input or destination of output

;alid ran'e, accuracy and@or tolerance #nits of measure 1imin' Relations%ips to ot%er inputs@outputs Screen formats@or'ani/ation Aindo! formats@or'ani/ation Data formats $ommand formats )nd messa'es

,&( 4unctions
"unctional re(uirements define t%e fundamental actions t%at must ta8e place in t%e soft!are in acceptin' and processin' t%e inputs and in processin' and 'eneratin' t%e outputs. 1%ese are 'enerally listed as Bs%allC statements startin' !it% D1%e system s%allE 1%ese include4 ;alidity c%ec8s 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 sub7functions or sub7 processes. 1%is does not imply t%at t%e soft!are desi'n !ill also be partitioned t%at !ay.

,&, Performance Requirements


1%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 include4 2a3 1%e number of terminals to be supported 2b3 1%e number of simultaneous users to be supported 2c3 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 tas8s and t%e amount of data to be processed !it%in certain time periods for bot% normal and pea8 !or8load conditions. All of t%ese re(uirements s%ould be stated in measurable terms. "or e*ample, F5G 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. 29ote4 9umerical limits applied to one specific function are normally specified as part of t%e processin' subpara'rap% description of t%at function.3

,&. 8ogical Database Requirements


1%is section specifies t%e lo'ical re(uirements for any information t%at is to be placed into a database. 1%is may include4 1ypes 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

,&- Design $onstraints


Specify desi'n constraints t%at can be imposed by ot%er standards, %ard!are limitations, etc. ,&-&% Standards $ompliance Specify t%e re(uirements derived from e*istin' standards or re'ulations. 1%ey mi'%t include4 213 Report format 223 Data namin'

233 Accountin' procedures 243 Audit 1racin' "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.

,&0 Software System Attributes


1%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 ob5ectively verified. 1%e follo!in' items provide a partial list of e*amples. ,&0&% Reliability Specify t%e factors re(uired to establis% t%e re(uired reliability of t%e soft!are system at time of delivery. ,&0&( A+ailability Specify t%e factors re(uired to 'uarantee a defined availability level for t%e entire system suc% as c%ec8point, recovery, and restart. ,&0&, Security 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 to4 #tili/e certain crypto'rap%ic tec%ni(ues ?eep specific lo' or %istory data sets Assi'n certain functions to different modules Restrict communications bet!een some areas of t%e pro'ram $%ec8 data inte'rity for critical variables ,&0&. /aintainability Specify attributes of soft!are t%at relate to t%e ease of maintenance of t%e soft!are itself. 1%ere may be some re(uirement for certain modularity, interfaces, comple*ity, etc. Re(uirements s%ould not be placed %ere 5ust because t%ey are t%ou'%t to be 'ood desi'n practices. ,&0&- Portability

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. 1%is may include4 Percenta'e of components !it% %ost7dependent 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 li8e t%is mi'%t be used to identify t%e 8ey c%aracteristics 2ratin' t%em =i'% or :edium3, t%en identifyin' !%ic% are preferred !%en tradin' off desi'n or implementation decisions 2!it% t%e +D of t%e preferred one indicated in t%e c%art to t%e ri'%t3. 'D ( . % 0 1 3 5 $ ) (& (( (. $)aracteristic 2orrectness Efficiency 9lexibility Integrity:!ecurity Interoperability 4aintainability Portability "eliability "eusability Testability 8sability 7+ailability #"/"8 % ( , . 0 2 3 9 %: %% %(

Definitions of t%e (uality c%aracteristics not defined in t%e para'rap%s above follo!. H $orrectness 7 e*tent to !%ic% pro'ram satisfies specifications, fulfills userIs mission ob5ectives H )fficiency 7 amount of computin' resources and code re(uired to perform function H "le*ibility 7 effort needed to modify operational pro'ram H +nteroperability 7 effort needed to couple one system !it% anot%er H Reliability 7 e*tent to !%ic% pro'ram performs !it% re(uired precision H Reusability 7 e*tent to !%ic% it can be reused in anot%er application H 1estability 7 effort needed to test to ensure performs as intended H #sability 7 effort re(uired to learn, operate, prepare input, and interpret output

,&2 *rgani;ing 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'ani/in' t%ese in a manner optimal for understandin'. 1%ere is no one optimal or'ani/ation for all systems. Different classes of systems lend t%emselves to different or'ani/ations of re(uirements in section 3. Some of t%ese or'ani/ations are described in t%e follo!in' subclasses. ,&2&% System /ode Some systems be%ave (uite differently dependin' on t%e mode of operation. A%en or'ani/in' by mode t%ere are t!o possible outlines. 1%e c%oice depends on !%et%er interfaces and performance are dependent on mode. ,&2&( 5ser $lass Some systems provide different sets of functions to different classes of users. ,&2&, *bjects b5ects are real7!orld entities t%at %ave a counterpart !it%in t%e system. Associated !it% eac% ob5ect is a set of attributes and functions. 1%ese functions are also called services, met%ods, or processes. 9ote t%at sets of ob5ects may s%are attributes and services. 1%ese are 'rouped to'et%er as classes.

,&2&. 4eature 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 stimulus7response pairs. ,&2&- Stimulus Some systems can be best or'ani/ed by describin' t%eir functions in terms of stimuli. ,& 2&0 Response Some systems can be best or'ani/ed by describin' t%eir functions in support of t%e 'eneration of a response. ,&2&2 4unctional #ierarc)y A%en none of %e above or'ani/ational sc%emes prove %elpful, t%e overall functionality can be or'ani/ed into a %ierarc%y of functions or'ani/ed 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 Additional $omments


A%enever a ne! SRS is contemplated, more t%an one of t%e or'ani/ational tec%ni(ues 'iven in 3.- may be appropriate. +n suc% cases, or'ani/e t%e specific re(uirements for multiple %ierarc%ies tailored to t%e specific needs of t%e system under specification. 1%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'ani/ation. "or e*ample, !%en or'ani/in' by mode, finite state mac%ines or state c%arts may prove %elpfulJ !%en or'ani/in' by ob5ect, ob5ect7oriented analysis may prove %elpfulJ !%en or'ani/in' by feature, stimulus7response se(uences may prove %elpfulJ !%en or'ani/in' 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 B"unctional Re(uirement iC may be described in native lan'ua'e, in pseudocode, in a system definition lan'ua'e, or in four subsections titled4 +ntroduction, +nputs, Processin', utputs.

.& $)ange /anagement Process

+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 pro5ect scope and re(uirements.

-& Document Appro+als


+dentify t%e approvers of t%e SRS document. Approver name, si'nature, and date s%ould be used.

0& Supporting 'nformation


1%e supportin' information ma8es t%e SRS easier to use. +t includes4 1able of $ontents +nde* Appendices

1%e Appendices are not al!ays considered part of t%e actual re(uirements specification and are not al!ays necessary. 1%ey may include4 2a3 Sample +@ formats, descriptions of cost analysis studies, results of user surveys 2b3 Supportin' or bac8'round information t%at can %elp t%e readers of t%e SRS 2c3 A description of t%e problems to be solved by t%e soft!are 2d3 Special pac8a'in' instructions for t%e code and t%e media to meet security, e*port, initial loadin', or ot%er re(uirements A%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. Tables on the following pages pro+ide alternate ways to structure section % on the specific requirements.

*utline for SRS Section , *rgani;ed by /ode! ersion % %. !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. 9unctional requirements %...( 4ode ( %...(.( 9unctional requirement (.( ..... %...(. n 9unctional requirement (.n %.... 4ode . ..... %...m 4ode m %...m.( 9unctional requirement m.( ..... %...m.n 9unctional requirement m.n %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

*utline for SRS Section , *rgani;ed by /ode! ersion ( %. !pecific "equirements %.( 9unctional "equirements %.(.( 4ode ( %.(.(.( External interfaces %.(.(.( 8ser interfaces %.(.(.. /ardware interfaces %.(.(.% !oftware interfaces %.(.(.0 2ommunications interfaces %.(.(.. 9unctional "equirement %.(.(...( 9unctional requirement ( ..... %.(.(... n 9unctional requirement n %.(.(.% Performance %.(.. 4ode . ..... %.(.m 4ode m %.. ;esign constraints %.% !oftware system attributes %.0 6ther requirements

*utline for SRS Section , *rgani;ed by 5ser $lass %. !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. 9unctional requirements %...( 8ser class ( %...(.( 9unctional requirement (.( ..... %...(. n 9unctional requirement (.n %.... 8ser class . ..... %...m 8ser class m %...m.( 9unctional requirement m.( ..... %...m.n 9unctional requirement m.n %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

*utline for SRS Section , *rgani;ed by *bject % !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. 2lasses:6bjects %...( 2lass:6bject ( %...(.( 7ttributes #direct or inherited* %...(.(.( 7ttribute ( ..... %...(.(. n 7ttribute n %...(.. 9unctions #ser+ices, methods, direct or inherited* %...(...( 9unctional requirement (.( ..... %...(... m 9unctional requirement (.m %...(.% 4essages #communications recei+ed or sent* %.... 2lass:6bject . ..... %...p 2lass:6bject p %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

*utline for SRS Section , *rgani;ed by 4eature

% !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. !ystem features %...( !ystem 9eature ( %...(.( Introduction:Purpose of feature %...(.. !timulus:"esponse sequence %...(.% 7ssociated functional requirements %...(.%.( 9unctional requirement ( ..... %...(.%. n 9unctional requirement n %.... !ystem 9eature . ..... %...m !ystem 9eature m ..... %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

*utline for SRS Section , *rgani;ed by Stimulus % !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. 9unctional requirements %...( !timulus ( %...(.( 9unctional requirement (.( ..... %...(. n 9unctional requirement (.n %.... !timulus . ..... %...m !timulus m %... m.( 9unctional requirement m.( ..... %... m.n 9unctional requirement m.n %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

*utline for SRS Section , *rgani;ed by Response % !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. 9unctional requirements %...( "esponse ( %...(.( 9unctional requirement (.( ..... %...(. n 9unctional requirement (.n %.... "esponse . ..... %...m "esponse m %... m.( 9unctional requirement m.( ..... %... m.n 9unctional requirement m.n %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

*utline for SRS Section , *rgani;ed by 4unctional #ierarc)y % !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. 9unctional requirements %...( Information flows %...(.( ;ata flow diagram ( %...(.(.( ;ata entities %...(.(.. Pertinent processes %...(.(.% Topology %...(.. ;ata flow diagram . %...(...( ;ata entities %...(.... Pertinent processes %...(...% Topology ..... %...(.n ;ata flow diagram n %...(.n.( ;ata entities %...(.n.. Pertinent processes %...(.n.% Topology %.... Process descriptions %.....( Process ( %.....(.( Input data entities %.....(.. 7lgorithm or formula of process %.....(.% 7ffected data entities %...... Process . %.......( Input data entities %........ 7lgorithm or formula of process %.......% 7ffected data entities .<. %.....m Process m %.....m.( Input data entities %.....m.. 7lgorithm or formula of process %..... m.% 7ffected data entities %...% ;ata construct specifications %...%.( 2onstruct ( %...%.(.( "ecord type %...%.(.. 2onstituent fields %...%.. 2onstruct . %...%...( "ecord type %...%.... 2onstituent fields <.. %...%. p 2onstruct p %...%. p.( "ecord type

%...%. p.. 2onstituent fields %...0 ;ata dictionary %...0.( ;ata element ( %...0.(.( =ame %...0.(.. "epresentation %...0.(.% 8nits:9ormat %...0.(.0 Precision:7ccuracy %...0.(.1 "ange %...0.. ;ata element . %...0...( =ame %...0.... "epresentation %...0...% 8nits:9ormat %...0...0 Precision:7ccuracy %...0...1 "ange <.. %...0.( ;ata element ( %...0. (.( =ame %...0. (.. "epresentation %...0. (.% 8nits:9ormat %...0. (.0 Precision:7ccuracy %...0. (.1 "ange %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

*utline for SRS Section , S)owing /ultiple *rgani;ations % !pecific "equirements %.( External interface requirements %.(.( 8ser interfaces %.(.. /ardware interfaces %.(.% !oftware interfaces %.(.0 2ommunications interfaces %.. 9unctional requirements %...( 8ser class ( %...(.( 9eature (.( %...(.(.( Introduction:Purpose of feature %...(.(.. !timulus:"esponse sequence %...(.(.% 7ssociated functional requirements %...(.. 9eature (.. %...(...( Introduction:Purpose of feature %...(.... !timulus:"esponse sequence %...(...% 7ssociated functional requirements <.. %...(.m 9eature (.m %...(.m.( Introduction:Purpose of feature %...(.m.. !timulus:"esponse sequence %...(. m.% 7ssociated functional requirements %.... 8ser class . ..... %...n 8ser class n ..... %.% Performance "equirements %.0 ;esign 2onstraints %.1 !oftware system attributes %.3 6ther requirements

Vous aimerez peut-être aussi