Download - Srs - Explained

8/11/2019 Srs - Explained

1/29

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 mightinsert wording about your project.

he document in this file is an annotated outline for specifying softwarerequirements! adapted from the I""" #uide to Software RequirementsSpecifications $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 acomment saying why you omit the data.

/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page ) of 2*'*/'&/)3 f


2/29


CS3911

(Team Number)

(Team Name)

Software Requirements Specification

Document

Version (n) Date (mm!dd!"""")

/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page 2 of 2*'*/'&/)3 f


3/29


Table of Contents

1# $ntroduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

1.5 vervie!

%# T&e ' erall Description

2.1 Product Perspective2.).) System Interfaces2.).2 Interfaces2.).& 4ardware Interfaces2.).3 Software Interfaces2.).1 5ommunications Interfaces2.).6 7emory 5onstraints2.).8 9perations2.).% 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 interfaces

3.2 "unctions

3.3 Performance Re(uirements

3.4 +o'ical Database Re(uirements

3.5 Desi'n $onstraints&.1.) Standards 5ompliance

3.& Soft!are System Attributes&.6.) Reliability&.6.2 :,ailability&.6.& Security&.6.3 7aintainability&.6.1 Portability

3. r'ani-in' t%e Specific Re(uirements&.8.) System 7ode

/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page & of 2*'*/'&/)3 f


4/29


&.8.2 ser 5lass&.8.& 9bjects&.8.3


5/29


1# $ntroduction

/%e follo!in' subsections of t%e Soft!are Re(uirements Specifications 0SRS document

s%ould provide an overvie! of t%e entire SRS. /%e t%in' to eep in mind as you !ritet%is document is t%at you are tellin' !%at t%e system must do so t%at desi'ners canultimately build it. Do not use t%is document for desi'n

1#1 ,urpose

dentify t%e purpose of t%is SRS and its intended audience. n t%is subsection, describet%e purpose of t%e particular SRS and specify t%e intended audience for t%e SRS.

1#% Scope

n t%is subsection601 dentify t%e soft!are product0s to be produced by name02 )*plain !%at t%e soft!are product0s !ill, and, if necessary, !ill not do03 Describe t%e application of t%e soft!are bein' specified, includin' relevant benefits,

ob7ectives, and 'oals04 8e consistent !it% similar statements in %i'%er9level specifications if t%ey e*ist

/%is s%ould be an e*ecutive9level summary. Do not enumerate t%e !%ole re(uirementslist %ere.

1#3 Definitions0 .cron"ms0 and .bbre iations#

Provide t%e definitions of all terms, acronyms, and abbreviations re(uired to properlyinterpret t%e SRS. /%is information may be provided by reference to one or moreappendices in t%e SRS or by reference to documents. /%is information may be providedby reference to an Appendi*.

1# References

n t%is subsection601 Provide a complete list of all documents referenced else!%ere in t%e SRS

02 dentify eac% document by title, report number 0if applicable , date, and publis%in' or'ani-ation03 Specify t%e sources from !%ic% t%e references can be obtained.

/%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

no! !%ere to find t%em.



6/29


1#- ' er iew

n t%is subsection601 Describe !%at t%e rest of t%e SRS contains02 )*plain %o! t%e SRS is or'ani-ed

Don:t re%as% t%e table of contents %ere. Point people to t%e parts of t%e document t%eyare most concerned !it%. $ustomers;potential users care about section 2, developerscare about section 3.

%# T&e ' erall Description

Describe t%e 'eneral factors t%at affect t%e product and its re(uirements. /%is sectiondoes not state specific re(uirements. nstead, it provides a bac 'round for t%osere(uirements, !%ic% are defined in section 3, and ma es 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%ecustomer. 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 isindependent and totally self9contained, 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 subsectionrelates t%e re(uirements of t%e lar'er system to functionality of t%e soft!are andidentifies 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 mar etplace. f youare doin' a researc%9oriented pro7ect, !%at related researc% compares to t%e system youare plannin' to build.

A bloc dia'ram s%o!in' t%e ma7or components of t%e lar'er system, interconnections,and e*ternal interfaces can be %elpful. /%is is not a desi'n or arc%itecture picture. t ismore to provide conte*t, especially if your system !ill interact !it% e*ternal actors. /%e

system you are buildin' s%ould be s%o!n as a blac bo*. +et t%e desi'n document present t%e internals.

/%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. /%ese are e*ternal systems t%at you %ave to interact !it%. "or instance, if you are buildin' a businessapplication t%at interfaces !it% t%e e*istin' employee payroll system, !%at is t%e AP tot%at system t%at desi'ner:s !ill need to use/%e system %as no %ard!are interface re(uirements@ f you 7ust delete sectionst%at are not applicable, t%en readers do not no! if6 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, include6

01 Came02 ?nemonic03 Specification number 04 ersion number 05 Source

"or eac% interface, provide601 Discussion of t%e purpose of t%e interfacin' soft!are as related to t%is soft!are product

02 Definition of t%e interface in terms of messa'e content and format

Eere !e document t%e AP s, versions of soft!are t%at !e do not %ave to !rite, but t%atour system %as to use. "or instance if your customer uses SF+ Server and you arere(uired to use t%at, t%en you need to specify i.e.2.1.4.1 ?icrosoft SF+ Server . /%e system must use SF+ Server as its databasecomponent. $ommunication !it% t%e D8 is t%rou'% D8$ connections. /%e systemmust provide SF+ data table definintions to be provided to t%e company D8A for setup.



8/29


A ey point to remember is t%at you do C / !ant to specify soft!are %ere t%at you t%in!ould be 'ood to use. /%is is only for customer-specified systems t%at you have tointeract !it%. $%oosin' SF+ Server as a D8 !it%out a customer re(uirement is a

Desi'n c%oice, not a re(uirement. /%is is a subtle but important point to !ritin' 'oodre(uirements and not over9constrainin' t%e desi'n.

%#1#- Communications $nterfaces

Specify t%e various interfaces to communications suc% as local net!or protocols, etc./%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' acustom protocol to communicate bet!een systems, t%en document t%at protocol %ere sodesi'ners no! !%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 7ust ma e up somet%in' %ere. f all t%e customer:s mac%ines %ave only 12 G of RA?, t%en your tar'et desi'n %as 'ot to come in under 12 G so t%ere is an actualre(uirement. Hou could also cite mar et researc% %ere for s%rin 9!rap type applications>"ocus 'roups %ave determined t%at our tar'et mar et %as bet!een 25&9512? of RA?,t%erefore t%e desi'n footprint s%ould not e*ceed 25&?.@ f t%ere are no memoryconstraints, so state.

%#1#2 'perations

Specify t%e normal and special operations re(uired by t%e user suc% as601 /%e various modes of operations in t%e user or'ani-ation02 Periods of interactive operations and periods of unattended operations03 Data processin' support functions04 8ac up and recovery operations

0Cote6 /%is is sometimes specified as part of t%e #ser nterfaces section. f you separate t%is from t%e # stuff earlier, t%en cover business process type stuff t%at !ouldimpact t%e desi'n. "or instance, if t%e company brin's all t%eir systems do!n atmidni'%t for data bac up t%at mi'%t impact t%e desi'n. /%ese are all t%e !or tas s t%at

impact t%e desi'n of an application, but !%ic% mi'%t not be located in soft!are.

%#1# Site .daptation Requirements

n t%is section601 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

/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page % of 2*'*/'&/)3 f


9/29


02 Specify t%e site or mission9related features t%at s%ould be modified to adapt t%e soft!areto a particular installation

f any modifications to t%e customer:s !or area !ould be re(uired by your system, t%endocument t%at %ere. "or instance, >A 1BBG! bac up 'enerator and 1BBBB 8/# airconditionin' system must be installed at t%e user site prior to soft!are installation@./%is could also be soft!are9specific li e, >Ce! data tables created for t%is system mustbe installed on t%e company:s e*istin' D8 server and populated prior to systemactivation.@ Any e(uipment t%e customer !ould need to buy or any soft!are setup t%atneeds to be done so t%at your system !ill install and operate correctly s%ould bedocumented %ere.

%#% ,roduct 4unctions

Provide a summary of t%e ma7or functions t%at t%e soft!are !ill perform. Sometimes t%e function summary t%at is necessary for t%is part can be ta en directly from t%e section of

t%e %i'%er9level specification 0if one e*ists t%at allocates particular functions to t%e soft!are product.

"or clarity601 /%e functions s%ould be or'ani-ed in a !ay t%at ma es t%e list of functions understandable to

t%e customer or to anyone else readin' t%e document for t%e first time.02 /e*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.

AE, "inally t%e real meat of section 2. /%is describes t%e functionality of t%e system int%e lan'ua'e of t%e customer. I%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 systemneeds to do, not %o! you are 'oin' to build it. 0/%at comes in t%e desi'n document .

%#3 5ser 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(uirementsbut rat%er provide t%e reasons !%y certain specific re(uirements are later specified in

section 3.

I%at is it about your potential user base t%at !ill impact t%e desi'n< /%eir e*perienceand comfort !it% tec%nolo'y !ill drive # desi'n. t%er c%aracteristics mi'%t actuallyinfluence internal desi'n of t%e system.

%# Constraints

Provide a 'eneral description of any ot%er items t%at !ill limit t%e developerJs options./%ese can include6

/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page * of 2*'*/'&/)3 f


10/29


01 Re'ulatory policies02 Eard!are limitations 0for e*ample, si'nal timin' re(uirements03 nterface to ot%er applications04 Parallel operation05 Audit functions0& $ontrol functions0 Ei'%er9order lan'ua'e re(uirements$%+Si'nal %ands%a e protocols 0for e*ample, C9 "", A$G9CA$G$*+ Reliability re(uirements01B $riticality of t%e application011 Safety and security considerations

/%is section captures non9functional re(uirements in t%e customers lan'ua'e. A more formal presentation of t%ese !ill occur in section 3.

%#- .ssumptions and Dependencies

+ist eac% of t%e factors t%at affect t%e re(uirements stated in t%e SRS. /%ese factors arenot 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 specificoperatin' 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 toc%an'e accordin'ly.

/%is section is catc%9all for everyt%in' else t%at mi'%t influence t%e desi'n of t%e systemand t%at did not fit in any of t%e cate'ories above.

%#/ .pportionin* of Requirements#

dentify re(uirements t%at may be delayed until future versions of t%e system. After youloo at t%e pro7ect plan and %ours available, you may reali-e t%at you 7ust cannot 'eteveryt%in' done. /%is section divides t%e re(uirements into different sections fordevelopment and delivery. Remember to c%ec !it% t%e customer t%ey s%ould prioriti-et%e re(uirements and decide !%at does and does not 'et done. /%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

/%is section contains all t%e soft!are re(uirements at a level of detail sufficient to enabledesi'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. /%rou'%out t%is section, every stated re(uirement s%ould be e*ternally perceivable by users, operators, or ot%er e*ternal systems. /%esere(uirements s%ould include at a minimum a description of every input 0stimulus into t%e

system, every output 0response from t%e system and all functions performed by t%e system in response to an input or in support of an output. /%e follo!in' principles apply6

/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page )' of 2*'*/'&/)3 f


11/29


01 Specific re(uirements s%ould be stated !it% all t%e c%aracteristics of a 'ood SRS correct unambi'uous complete consistent ran ed for importance and;or stability verifiable modifiable traceable

02 Specific re(uirements s%ould be cross9referenced to earlier documents t%at relate03 All re(uirements s%ould be uni(uely identifiable 0usually via numberin' li e 3.1.2.304 $areful attention s%ould be 'iven to or'ani-in' t%e re(uirements to ma*imi-e readability

0Several alternative or'ani-ations are 'iven at end of document

8efore 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./%is section reiterates section 2, but is for developers not t%e customer. /%e customerbuys in !it% section 2, t%e desi'ners use section 3 to desi'n and build t%e actualapplication.

Remember t%is is not desi'n. Do not re(uire specific soft!are pac a'es, etc unless t%ecustomer specifically re(uires t%em. Avoid over9constrainin' your desi'n. #se properterminolo'y6/%e system s%allK A re(uired, must %ave feature/%e system s%ouldK A desired feature, but may be deferred til later /%e system mayK An optional, nice9to9%ave feature t%at may never ma e it toimplementation.

)ac% re(uirement s%ould be uni(uely identified for traceability. #sually, t%ey arenumbered 3.1, 3.1.1, 3.1.2.1 etc. )ac% re(uirement s%ould also be testable. Avoidimprecise statements li e, >/%e system s%all be easy to use@ Iell no iddin', !%at doest%at mean< Avoid >mot%er%ood and apple pie@ type statements, >/%e system s%all bedeveloped usin' 'ood soft!are en'ineerin' practice@

Avoid e*amples, /%is is a specification, a desi'ner s%ould be able to read t%is spec andbuild t%e system !it%out bot%erin' t%e customer a'ain. Don:t say t%in's li e, >/%e

system s%all accept confi'uration information suc% as name and address.@ /%e desi'nerdoesn:t no! if t%at is t%e only t!o data elements or if t%ere are 2BB. +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 67ternal $nterfaces

/%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/23&''3)*2.doc Page )) of 2*'*/'&/)3 f


12/29


information t%ere. Remember section 2 presents information oriented to t%ecustomer;user !%ile section 3 is oriented to t%e developer.

t contains bot% content and format as follo!s6

Came of item Description of purpose Source of input or destination of output alid ran'e, accuracy and;or tolerance #nits of measure /imin' Relations%ips to ot%er inputs;outputs Screen formats;or'ani-ation Iindo! formats;or'ani-ation Data formats $ommand formats )nd messa'es

3#% 4unctions

"unctional re(uirements define t%e fundamental actions t%at must ta e place in t%e soft!are in acceptin' and processin' t%e inputs and in processin' and 'eneratin' t%eoutputs. /%ese are 'enerally listed as >s%all@ statements startin' !it% L/%e system

s%allK

/%ese include6

alidity c%ec s 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 sub9functions or sub9 processes. /%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/23&''3)*2.doc Page )2 of 2*'*/'&/)3 f


13/29


/%is subsection specifies bot% t%e static and t%e dynamic numerical re(uirements placedon t%e soft!are or on %uman interaction !it% t%e soft!are, as a !%ole. Static numericalre(uirements may include6

0a /%e number of terminals to be supported 0b /%e number of simultaneous users to be supported 0c Amount and type of information to be %andled

Static numerical re(uirements are sometimes identified under a separate section entitledcapacity.

Dynamic numerical re(uirements may include, for e*ample, t%e numbers of transactionsand tas s and t%e amount of data to be processed !it%in certain time periods for bot%normal and pea !or load conditions.

All of t%ese re(uirements s%ould be stated in measurable terms.

"or e*ample,

M5N 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.

0Cote6 Cumerical limits applied to one specific function are normally specified as partof t%e processin' subpara'rap% description of t%at function.

3# 8o*ical Database Requirements

/%is section specifies t%e lo'ical re(uirements for any information t%at is to be placedinto a database. /%is may include6

/ypes 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. )Rdia'rams 0or static class dia'rams can be useful %ere to s%o! comple* datarelations%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/23&''3)*2.doc Page )& of 2*'*/'&/)3 f


14/29


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. /%ey mi'%tinclude6

01 Report format 02 Data namin' 03 Accountin' procedures04 Audit /racin'

"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 .ttributes

/%ere are a number of attributes of soft!are t%at can serve as re(uirements. t isimportant t%at re(uired attributes by specified so t%at t%eir ac%ievement can beob7ectively verified. /%e follo!in' items provide a partial list of e*amples. /%ese arealso no!n as non9functional re(uirements or (uality attributes.

/%ese are c%aracteristics t%e system must possess, but t%at pervade 0or cross9cut t%edesi'n. /%ese re(uirements %ave to be testable 7ust li e t%e functional re(uirements. tseasy to start p%ilosop%i-in' %ere, but eep it specific.

3#/#1 Reliabilit"

Specify t%e factors re(uired to establis% t%e re(uired reliability of t%e soft!are system attime of delivery. f you %ave ?/8" re(uirements, e*press t%em %ere. /%is doesn:t referto 7ust %avin' a pro'ram t%at does not cras%. /%is %as a specific en'ineerin' meanin'.

3#/#% . ailabilit"

Specify t%e factors re(uired to 'uarantee a defined availability level for t%e entire system suc% as c%ec point, recovery, and restart. /%is is some!%at related to reliability. Some systems run only infre(uently on9demand 0li e ?S Iord . Some systems %ave to run 24; 0li e an e9commerce !eb site . /%e re(uired availability !ill 'reatly impact t%e desi'n.I%at are t%e re(uirements for system recovery from a failure< >/%e system s%all allo!users to restart t%e application after failure !it% t%e loss of at most 12 c%aracters ofinput@.



15/29


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 couldinclude t%e need to6

#tili-e certain crypto'rap%ic tec%ni(ues Geep specific lo' or %istory data sets Assi'n certain functions to different modules Restrict communications bet!een some areas of t%e pro'ram $%ec 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./%ere may be some re(uirement for certain modularity, interfaces, comple*ity, etc.

Re(uirements s%ould not be placed %ere 7ust 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 %ostmac%ines and;or operatin' systems. /%is may include6

Percenta'e of components !it% %ost9dependent 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 andmeasured. A c%art li e t%is mi'%t be used to identify t%e ey c%aracteristics 0ratin' t%em

Ei'% or ?edium , t%en identifyin' !%ic% are preferred !%en tradin' off desi'n orimplementation decisions 0!it% t%e D of t%e preferred one indicated in t%e c%art to t%eri'%t . /%e c%art belo! is optional 0it can be confusin' and is for demonstratin'tradeoff analysis bet!een different non9functional re(uirements. E;?;+ is t%e relative

priority of t%at non9functional re(uirement.

$D C&aracteristic !+!8 1 % 3 - / 2 9 1 11 1%) 5orrectness2 "fficiency&


16/29


8 Portability% Reliability* Reusability)' estability)) sability

)2 :,ailability

Definitions of t%e (uality c%aracteristics not defined in t%e para'rap%s above follo!.

O $orrectness 9 e*tent to !%ic% pro'ram satisfies specifications, fulfills user:smission ob7ectives

O )fficiency 9 amount of computin' resources and code re(uired to perform functionO "le*ibility 9 effort needed to modify operational pro'ramO nteroperability 9 effort needed to couple one system !it% anot%er

O Reliability 9 e*tent to !%ic% pro'ram performs !it% re(uired precisionO Reusability 9 e*tent to !%ic% it can be reused in anot%er applicationO /estability 9 effort needed to test to ensure performs as intended O #sability 9 effort re(uired to learn, operate, prepare input, and interpret output

/E) " ++ I C= 03. is not really a section, it is tal in' about %o! to or'ani-ere(uirements you !rite in section 3.2. At t%e end of t%is template t%ere are a bunc% ofalternative or'ani-ations for section 3.2. $%oose t%e C) best for t%e system you are!ritin' t%e re(uirements for.

3#2 '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%isreason, it is recommended t%at careful consideration be 'iven to or'ani-in' t%ese in amanner optimal for understandin'. /%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.

3#2#1 S"stem +ode

Some systems be%ave (uite differently dependin' on t%e mode of operation. I%enor'ani-in' by mode t%ere are t!o possible outlines. /%e c%oice depends on !%et%erinterfaces and performance are dependent on mode.

3#2#% 5ser Class

Some systems provide different sets of functions to different classes of users.

3#2#3 'b;ects



17/29


b7ects are real9!orld entities t%at %ave a counterpart !it%in t%e system. Associated!it% eac% ob7ect is a set of attributes and functions. /%ese functions are also called

services, met%ods, or processes. Cote t%at sets of ob7ects may s%are attributes and services. /%ese are 'rouped to'et%er as classes.

3#2# 4eature

A feature is an e*ternally desired service by t%e system t%at may re(uire a se(uence ofinputs to effect t%e desired result. )ac% feature is 'enerally described in as se(uence eof

stimulus9response pairs.

3#2#- Stimulus

Some systems can be best or'ani-ed by describin' t%eir functions in terms of stimuli.

3# 2#/ Response

Some systems can be best or'ani-ed by describin' t%eir functions in support of t%e 'eneration of a response.

3#2#2 4unctional ierarc&"

I%en none of %e above or'ani-ational sc%emes prove %elpful, t%e overall functionalitycan 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 datadictionaries can be use dot s%o! t%e relations%ips bet!een and amon' t%e functions and

data.

3# .dditional Comments

I%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 formultiple %ierarc%ies tailored to t%e specific needs of t%e system under specification.

/%ree are many notations, met%ods, and automated support tools available to aid in t%edocumentation of re(uirements. "or t%e most part, t%eir usefulness is a function ofor'ani-ation. "or e*ample, !%en or'ani-in' by mode, finite state mac%ines or statec%arts may prove %elpful !%en or'ani-in' by ob7ect, ob7ect9oriented analysis may prove%elpful !%en or'ani-in' by feature, stimulus9response se(uences may prove %elpful!%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 >"unctional Re(uirement i@ may bedescribed in native lan'ua'e, in pseudocode, in a system definition lan'ua'e, or in four

subsections titled6 ntroduction, nputs, Processin', utputs.



18/29


# 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 pro7ect scope and re(uirements. Eo! are you 'oin' tocontrol c%an'es to t%e re(uirements. $an t%e customer 7ust call up and as for somet%in' ne!< Does your team %ave to reac% consensus< Eo! do c%an'es tore(uirements 'et submitted to t%e team< "ormally in !ritin', email or p%one call

Download - Srs - Explained

Top Related