Srs - Explained

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/23&''3)*2.doc Page ) of 2*
'*/'&/)3f
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*
'*/'&/)3f
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 Perspective
2.).) System Interfaces
2.).2 Interfaces
2.).& 4ardware Interfaces
2.).3 Software Interfaces
2.).1 5ommunications Interfaces
2.).6 7emory 5onstraints
2.).8 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 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*
'*/'&/)3f
&.8.2 ;ser 5lass
&.8.& 9bjects
&.8.3 <eature
&.8.1 Stimulus
&.8.6 Response
&.8.8 <unctional 4ierarchy
3.. Additional $omments
)# C&an*e +ana*ement ,rocess
-# Document .ppro(als
/# Supportin* $nformation
'*/'&/)3f
1# $ntroduction
/%e follo!in' subsections of t%e Soft!are Re(uirements Specifications 0SRS1 document
s%ould provide an overvie! of t%e entire SRS. /%e t%in' to 2eep in mind as you !rite
t%is document is t%at you are tellin' !%at t%e system must do 3 so t%at desi'ners can
ultimately build it. Do not use t%is document for desi'n444
1#1 ,urpose
5dentify t%e purpose of t%is SRS and its intended audience. 5n t%is subsection, describe
t%e purpose of t%e particular SRS and specify t%e intended audience for t%e SRS.
1#% Scope
5n t%is subsection6
011 5dentify t%e soft!are product0s1 to be produced by name
021 )*plain !%at t%e soft!are product0s1 !ill, and, if necessary, !ill not do
031 Describe t%e application of t%e soft!are bein' specified, includin' relevant benefits,
ob7ectives, and 'oals
041 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(uirements
list %ere.
1#3 Definitions0 .cron"ms0 and .bbre(iations#
Provide t%e definitions of all terms, acronyms, and abbreviations re(uired to properly
interpret t%e SRS. /%is information may be provided by reference to one or more
appendices in t%e SRS or by reference to documents. /%is information may be provided
by reference to an Appendi*.
1#) References
5n t%is subsection6
011 Provide a complete list of all documents referenced else!%ere in t%e SRS
021 5dentify eac% document by title, report number 0if applicable1, date, and
publis%in' or'ani-ation
031 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. 5f
your application uses specific protocols or R"$:s, t%en reference t%em %ere so desi'ners
2no! !%ere to find t%em.
'*/'&/)3f
1#- '(er(iew
5n t%is subsection6
011 Describe !%at t%e rest of t%e SRS contains
021 )*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%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. /%is section
does not state specific re(uirements. 5nstead, it provides a bac2'round for t%ose
re(uirements, !%ic% are defined in section 3, and ma2es t%em easier to understand. 5n 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. 5f t%e product is
independent and totally self9contained, it s%ould be so stated %ere. 5f 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. 5f you are buildin' a real
system,compare its similarity and differences to ot%er systems in t%e mar2etplace. 5f you
are doin' a researc%9oriented pro7ect, !%at related researc% compares to t%e system you
are plannin' to build.
A bloc2 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. 5t is
more 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 blac2 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 business
application t%at interfaces !it% t%e e*istin' employee payroll system, !%at is t%e AP5 to
t%at system t%at desi'ner:s !ill need to use<
'*/'&/)3f
%#1#% $nterfaces
Specify6
011 /%e lo'ical c%aracteristics of eac% interface bet!een t%e soft!are product and its users.
021 All t%e aspects of optimi-in' t%e interface !it% t%e person !%o must use t%e system
/%is is a description of %o! t%e system !ill interact !it% its users. 5s t%ere a =#5, a
command line or some ot%er type of interface< Are t%ere special interface re(uirements<
5f you are desi'nin' for t%e 'eneral student population for instance, !%at is t%e impact of
ADA 0American !it% Disabilities Act1 on your interface<
%#1#3 1ardware $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. /%is includes confi'uration c%aracteristics. 5t also
covers suc% matters as !%at devices are to be supported, %o! t%ey are to be supported
and protocols. /%is is not a description of %ard!are re(uirements in t%e sense t%at >/%is
pro'ram must run on a ?ac !it% &4? of RA?@. /%is section is for detailin' t%e actual
%ard!are devices your application !ill interact !it% and control. "or instance, if you are
controllin' A1B type %ome devices, !%at is t%e interface to t%ose devices< Desi'ners
s%ould be able to loo2 at t%is and 2no! !%at %ard!are t%ey need to !orry about in t%e
desi'n. ?any business type applications !ill %ave no %ard!are interfaces. 5f none, 7ust
state >/%e system %as no %ard!are interface re(uirements@ 5f you 7ust delete sections
t%at are not applicable, t%en readers do not 2no! 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
011 Came
021 ?nemonic
031 Specification number
041 Dersion number
051 Source
"or eac% interface, provide6
011 Discussion of t%e purpose of t%e interfacin' soft!are as related to t%is soft!are product
021 Definition of t%e interface in terms of messa'e content and format
Eere !e document t%e AP5s, 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 SF+ Server , and you are
re(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 database
component. $ommunication !it% t%e D8 is t%rou'% D8$ connections. /%e system
must provide SF+ data table definintions to be provided to t%e company D8A for setup.
'*/'&/)3f
A 2ey point to remember is t%at you do C/ !ant to specify soft!are %ere t%at you t%in2
!ould be 'ood to use. /%is is only for customer-specified systems t%at you have to
interact !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' 'ood
re(uirements and not over9constrainin' t%e desi'n.

%#1#- Communications $nterfaces
Specify t%e various interfaces to communications suc% as local net!or2 protocols, etc.
/%ese are protocols you !ill need to directly interact !it%. 5f you %appen to use !eb
services transparently to your application t%en do not list it %ere. 5f you are usin' a
custom protocol to communicate bet!een systems, t%en document t%at protocol %ere so
desi'ners 2no! !%at to desi'n. 5f 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 ma2e up somet%in' %ere. 5f 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 actual
re(uirement. Hou could also cite mar2et researc% %ere for s%rin29!rap type applications
>"ocus 'roups %ave determined t%at our tar'et mar2et %as bet!een 25&9512? of RA?,
t%erefore t%e desi'n footprint s%ould not e*ceed 25&?.@ 5f t%ere are no memory
constraints, so state.
%#1#2 'perations
Specify t%e normal and special operations re(uired by t%e user suc% as6
011 /%e various modes of operations in t%e user or'ani-ation
021 Periods of interactive operations and periods of unattended operations
031 Data processin' support functions
041 8ac2up and recovery operations
0Cote6 /%is is sometimes specified as part of t%e #ser 5nterfaces section.1 5f you
separate t%is from t%e #5 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 bac2up t%at mi'%t impact t%e desi'n. /%ese are all t%e !or2 tas2s t%at
impact t%e desi'n of an application, but !%ic% mi'%t not be located in soft!are.
%#1#3 Site .daptation Requirements
5n t%is section6
011 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*
'*/'&/)3f
021 Specify t%e site or mission9related features t%at s%ould be modified to adapt t%e soft!are
to a particular installation
5f any modifications to t%e customer:s !or2 area !ould be re(uired by your system, t%en
document t%at %ere. "or instance, >A 1BBG! bac2up 'enerator and 1BBBB 8/# air
conditionin' system must be installed at t%e user site prior to soft!are installation@.
/%is could also be soft!are9specific li2e, >Ce! data tables created for t%is system must
be installed on t%e company:s e*istin' D8 server and populated prior to system
activation.@ 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 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 ta2en directly from t%e section of
t%e %i'%er9level specification 0if one e*ists1 t%at allocates particular functions to t%e
soft!are product.
"or clarity6
011 /%e functions s%ould be or'ani-ed in a !ay t%at ma2es t%e list of functions understandable to
t%e customer or to anyone else readin' t%e document for t%e first time.
021 /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 in
t%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 system
needs to do, not %o! you are 'oin' to build it. 0/%at comes in t%e desi'n document1.
%#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(uirements
but 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*perience
and comfort !it% tec%nolo'y !ill drive #5 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 developerJs options.
/%ese can include6
/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page * of 2*
'*/'&/)3f
011 Re'ulatory policies
021 Eard!are limitations 0for e*ample, si'nal timin' re(uirements1
031 5nterface to ot%er applications
041 Parallel operation
051 Audit functions
0&1 $ontrol functions
0,1 Ei'%er9order lan'ua'e re(uirements
$%+ Si'nal %ands%a2e protocols 0for e*ample, AC9A"", A$G9CA$G1
$*+ Reliability re(uirements
01B1 $riticality of t%e application
0111 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 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. 5f, in fact, t%e operatin' system !ere not available, t%e SRS !ould t%en %ave to
c%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 system
and t%at did not fit in any of t%e cate'ories above.
%#/ .pportionin* of Requirements#
5dentify re(uirements t%at may be delayed until future versions of t%e system. After you
loo2 at t%e pro7ect plan and %ours available, you may reali-e t%at you 7ust cannot 'et
everyt%in' done. /%is section divides t%e re(uirements into different sections for
development and delivery. Remember to c%ec2 !it% t%e customer 3 t%ey s%ould prioriti-e
t%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 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. /%rou'%out t%is section, every stated re(uirement
s%ould be e*ternally perceivable by users, operators, or ot%er e*ternal systems. /%ese
re(uirements s%ould include at a minimum a description of every input 0stimulus1 into t%e
system, every output 0response1 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*
'*/'&/)3f
011 Specific re(uirements s%ould be stated !it% all t%e c%aracteristics of a 'ood SRS
correct
unambi'uous
complete
consistent
ran2ed for importance and;or stability
verifiable
modifiable
traceable
021 Specific re(uirements s%ould be cross9referenced to earlier documents t%at relate
031 All re(uirements s%ould be uni(uely identifiable 0usually via numberin' li2e 3.1.2.31
041 $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 document1
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 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 pac2a'es, etc unless t%e
customer specifically re(uires t%em. Avoid over9constrainin' your desi'n. #se proper
terminolo'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 ma2e 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 li2e, >/%e system s%all be easy to use@ Iell no 2iddin', !%at does
t%at mean< Avoid >mot%er%ood and apple pie@ type statements, >/%e system s%all be
developed 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 and
build t%e system !it%out bot%erin' t%e customer a'ain. Don:t say t%in's li2e, >/%e
system s%all accept confi'uration information suc% as name and address.@ /%e desi'ner
doesn:t 2no! 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 #5 and data tables.
3#1 67ternal $nterfaces
/%is contains a detailed description of all inputs into and outputs from t%e soft!are
system. 5t 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*
'*/'&/)3f
information t%ere. Remember section 2 presents information oriented to t%e
customer;user !%ile section 3 is oriented to t%e developer.
5t contains bot% content and format as follo!s6
Came of item
Description of purpose
Source of input or destination of output
Dalid 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 ta2e place in t%e
soft!are in acceptin' and processin' t%e inputs and in processin' and 'eneratin' t%e
outputs. /%ese are 'enerally listed as >s%all@ statements startin' !it% L/%e system
s%allK
/%ese include6
Dalidity c%ec2s 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'
5nput;utput se(uences
"ormulas for input to output conversion
5t 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*
'*/'&/)3f
/%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 include6
0a1 /%e number of terminals to be supported
0b1 /%e number of simultaneous users to be supported
0c1 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 tas2s and t%e amount of data to be processed !it%in certain time periods for bot%
normal and pea2 !or2load 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 part
of t%e processin' subpara'rap% description of t%at function.1
3#) 8o*ical Database Requirements
/%is section specifies t%e lo'ical re(uirements for any information t%at is to be placed
into 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
5nte'rity constraints
Data retention re(uirements
5f t%e customer provided you !it% data models, t%ose can be presented %ere. )R
dia'rams 0or static class dia'rams1 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/23&''3)*2.doc Page )& of 2*
'*/'&/)3f
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'%t
include6
011 Report format
021 Data namin'
031 Accountin' procedures
041 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. 5t is
important t%at re(uired attributes by specified so t%at t%eir ac%ievement can be
ob7ectively verified. /%e follo!in' items provide a partial list of e*amples. /%ese are
also 2no!n as non9functional re(uirements or (uality attributes.
/%ese are c%aracteristics t%e system must possess, but t%at pervade 0or cross9cut1 t%e
desi'n. /%ese re(uirements %ave to be testable 7ust li2e t%e functional re(uirements. 5ts
easy to start p%ilosop%i-in' %ere, but 2eep 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. 5f you %ave ?/8" re(uirements, e*press t%em %ere. /%is doesn:t refer
to 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%ec2point, recovery, and restart. /%is is some!%at related to reliability. Some
systems run only infre(uently on9demand 0li2e ?S Iord1. Some systems %ave to run 24;,
0li2e an e9commerce !eb site1. /%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 of
input@.
'*/'&/)3f
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 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
$%ec2 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. 5f 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. /%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 and
measured. A c%art li2e t%is mi'%t be used to identify t%e 2ey c%aracteristics 0ratin' t%em
Ei'% or ?edium1, t%en identifyin' !%ic% are preferred !%en tradin' off desi'n or
implementation decisions 0!it% t%e 5D of t%e preferred one indicated in t%e c%art to t%e
ri'%t1. /%e c%art belo! is optional 0it can be confusin'1 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 1!+!8 1 % 3 ) - / 2 3 9 19 11 1%
) 5orrectness
2 "fficiency
& <lexibility
3 Integrity/Security
1 Interoperability
6 7aintainability
'*/'&/)3f
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:s
mission ob7ectives
O )fficiency 9 amount of computin' resources and code re(uired to perform function
O "le*ibility 9 effort needed to modify operational pro'ram
O 5nteroperability 9 effort needed to couple one system !it% anot%er
O Reliability 9 e*tent to !%ic% pro'ram performs !it% re(uired precision
O Reusability 9 e*tent to !%ic% it can be reused in anot%er application
O /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) "++I5C= 03.,1 is not really a section, it is tal2in' about %o! to or'ani-e
re(uirements you !rite in section 3.2. At t%e end of t%is template t%ere are a bunc% of
alternative 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%is
reason, it is recommended t%at careful consideration be 'iven to or'ani-in' t%ese in a
manner 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%en
or'ani-in' by mode t%ere are t!o possible outlines. /%e c%oice depends on !%et%er
interfaces 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
'*/'&/)3f
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 of
inputs 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 1ierarc&"
I%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#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. 5n 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.
/%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 %elpfulP !%en or'ani-in' by ob7ect, ob7ect9oriented analysis may prove
%elpfulP !%en or'ani-in' by feature, stimulus9response se(uences may prove %elpfulP
!%en or'ani-in' by functional %ierarc%y, data flo! dia'rams and data dictionaries may
prove %elpful.
5n any of t%e outlines belo!, t%ose sections called >"unctional Re(uirement i@ may be
described in native lan'ua'e, in pseudocode, in a system definition lan'ua'e, or in four
subsections titled6 5ntroduction, 5nputs, Processin', utputs.
'*/'&/)3f
)# C&an*e +ana*ement ,rocess

5dentify 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' to
control c%an'es to t%e re(uirements. $an t%e customer 7ust call up and as2 for
somet%in' ne!< Does your team %ave to reac% consensus< Eo! do c%an'es to
re(uirements 'et submitted to t%e team< "ormally in !ritin', email or p%one call<
-# Document .ppro(als
5dentify t%e approvers of t%e SRS document. Approver name, si'nature, and date s%ould
be used.
/# Supportin* $nformation
/%e supportin' information ma2es t%e SRS easier to use. 5t includes6
/able of $ontents
5nde*
Appendices
/%e Appendices are not al!ays considered part of t%e actual re(uirements specification
and are not al!ays necessary. /%ey may include6
0a1 Sample 5; formats, descriptions of cost analysis studies, results of user
surveys
0b1 Supportin' or bac2'round information t%at can %elp t%e readers of t%e SRS
0c1 A description of t%e problems to be solved by t%e soft!are
0d1 Special pac2a'in' instructions for t%e code and t%e media to meet security,
e*port, initial loadin', or ot%er re(uirements
I%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/23&''3)*2.doc Page )% of 2*
'*/'&/)3f
'utline for SRS Section 3
'r*ani:ed b" mode Version 1
&. Specific Requirements
&.) "xternal interface requirements
&.).) ;ser interfaces
&.).2 4ardware interfaces
&.).& Software interfaces
&.).3 5ommunications interfaces
&.2 <unctional requirements
&.2.) 7ode )
&.2.).) <unctional requirement ).)
.....
&.2.).n <unctional requirement ).n
&.2.2 7ode 2
.....
&.2.m 7ode m
&.2.m.) <unctional requirement m.)
.....
&.2.m.n <unctional requirement m.n
&.& Performance Requirements
&.3 Design 5onstraints
&.1 Software system attributes
&.6 9ther requirements
/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page )* of 2*
'*/'&/)3f
'r*ani:ed b" mode Version %
&.) <unctional Requirements
&.).) 7ode )
&.).).) "xternal interfaces
&.).).) ;ser interfaces
&.).).2 4ardware interfaces
&.).).& Software interfaces
&.).).3 5ommunications interfaces
&.).).2 <unctional Requirement
&.).).2.) <unctional requirement )
.....
&.).).2.n <unctional requirement n
&.).).& Performance
&.).2 7ode 2
.....
&.).m 7ode m
&.2 Design constraints
&.& Software system attributes

/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page 2' of 2*
'*/'&/)3f
'r*ani:ed b" user class (i#e# different t"pes of users <=S"stem .dminstrators0 +ana*ers0
Cler>s0 etc#)
&.2.) ;ser class )
.....
&.2.2 ;ser class 2
.....
&.2.m ;ser class m
.....
/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page 2) of 2*
'*/'&/)3f
'r*ani:ed b" ob;ect (?ood if "ou did an ob;ect<oriented anal"sis as part of "our requirements)
& Specific Requirements
&.2 5lasses/9bjects
&.2.) 5lass/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.).& 7essages $communications recei,ed or sent+
&.2.2 5lass/9bject 2
.....
&.2.p 5lass/9bject p
'*/'&/)3f
'r*ani:ed b" feature (?ood w&en t&ere are clearl" delimited feature sets#
&.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
.....
/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page 2& of 2*
'*/'&/)3f
'r*ani:ed b" stimulus (?ood for e(ent dri(en s"stems w&ere t&e e(ents form lo*ical
*roupin*s)
&.2.) Stimulus )
.....
&.2.2 Stimulus 2
.....
&.2.m Stimulus m
.....
'*/'&/)3f
'r*ani:ed b" response (?ood for e(ent dri(en s"stems w&ere t&e responses form lo*ical
*roupin*s)
&.2.) Response )
.....
&.2.2 Response 2
.....
&.2.m Response m
.....
'*/'&/)3f
'r*ani:ed b" functional &ierarc&" (?ood if "ou &a(e done structured anal"sis as part of "our
desi*n#)
&.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.&.) 5onstruct )
&.2.&.).) Record type
&.2.&.).2 5onstituent fields
&.2.&.2 5onstruct 2
&.2.&.2.) Record type
&.2.&.2.2 5onstituent fields
?..
'*/'&/)3f
&.2.&.p 5onstruct p
&.2.&.p.) Record type
&.2.&.p.2 5onstituent fields
&.2.3 Data dictionary
&.2.3.) Data element )
&.2.3.).) @ame
&.2.3.).2 Representation
&.2.3.).& ;nits/<ormat
&.2.3.).3 Precision/:ccuracy
&.2.3.).1 Range
&.2.3.2 Data element 2
&.2.3.2.) @ame
&.2.3.2.2 Representation
&.2.3.2.& ;nits/<ormat
&.2.3.2.3 Precision/:ccuracy
&.2.3.2.1 Range
?..
&.2.3.( Data element (
&.2.3.(.) @ame
&.2.3.(.2 Representation
&.2.3.(.& ;nits/<ormat
&.2.3.(.3 Precision/:ccuracy
&.2.3.(.1 Range
'*/'&/)3f
S&owin* multiple or*ani:ations (Can@t decideA T&en *lob it all to*et&er)
&.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
.....
/,ar/www/apps/con,ersion/tmp/scratch01/23&''3)*2.doc Page 2% of 2*
'*/'&/)3f
'r*ani:ed b" 5se Case (?ood w&en followin* 5+8 de(elopment)
&.) "xternal :ctor Descriptions
&.).) 4uman :ctors
&.).2 4ardware :ctors
&.).& Software System :ctors
&.2 ;se 5ase Descriptions
&.2.) ;se 5ase )
&.2.2 ;se 5ase 2

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

Srs - Explained

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Srs - Explained

Încărcat de

Drepturi de autor:

Formate disponibile

Software Requirements Specifications Document

S-ar putea să vă placă și