Software Requirements Specification

Software Requirements Specification

A Software requirements specification (SRS), a requirements specification for
a software system, is a complete description of the behavior of a system to be
developed and may include a set of use cases that describe interactions the
users will have with the software. In addition it also contains non-functional
requirements. on-functional requirements impose constraints on the desi!n
or implementation (such as performance en!ineerin! requirements, quality
standards, or desi!n constraints) .
"he software requirements specification document enlists all necessary
requirements that are required for the pro#ect development.$%& "o derive the
requirements we need to have clear and thorou!h understandin! of the
products to be developed. "his is prepared after detailed communications
with the pro#ect team and customer.
"he SRS may be one of a contract deliverable 'ata Item 'escriptions$(& or
have other forms of or!ani)ationally-mandated content. An e*ample
or!ani)ation of an SRS is as follows+ $,&$-&
%. Introduction
%.% .urpose
%.( 'efinitions
%., System overview
%.- References
(. /verall description
(.% .roduct perspective
(.%.% System Interfaces
(.%.( 0ser Interfaces
(.%., 1ardware interfaces
(.%.- Software interfaces
(.%.2 3ommunication Interfaces
(.%.4 5emory 3onstraints
(.%.6 /perations
(.( .roduct functions
(., 0ser characteristics
(.- 3onstraints, assumptions and
%78(98%- 2+(, A5
if
Software Requirements Specification
(.2 dependencies
,. Specific requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.( ;unctional requirements
,., .erformance requirements
,.- 'esi!n constraints
,.2 <o!ical database requirement
,.4 Software System attributes
Reliability
Availability
Security
5aintainability
.ortability
Example
Table of Contents
%78(98%- 2+(, A5
iif
Software Requirements Specification
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations.
1.4 References
1.5 Overvie
2. The Overall Description
2.1 Product Perspective
(.%.% System Interfaces
(.%.( Interfaces
(.%., 1ardware Interfaces
(.%.- Software Interfaces
(.%.2 3ommunications Interfaces
(.%.4 5emory 3onstraints
(.%.6 /perations
(.%.= Site Adaptation Requirements
2.2 Product !unctions
2.3 "ser #$aracteristics
2.4 #onstraints
2.5 Assumptions and Dependencies
2.% Apportionin& of Re'uirements.
3. Specific e!uirements
3.1 ()terna* +nterfaces
3.2 !unctions
3.3 Performance Re'uirements
3.4 ,o&ica* Database Re'uirements
3.5 Desi&n #onstraints
,.2.% Standards 3ompliance
3.% Softare System Attributes
,.4.% Reliability
,.4.( Availability
,.4., Security
%78(98%- 2+(, A5
iiif
Software Requirements Specification
,.4.- 5aintainability
,.4.2 .ortability
3.- Or&ani.in& t$e Specific Re'uirements
,.6.% System 5ode
,.6.( 0ser 3lass
,.6., /b#ects
,.6.- ;eature
,.6.2 Stimulus
,. 6.4 Response
,.6.6 ;unctional 1ierarchy
3./ Additiona* #omments
". Chan#e $ana#ement %rocess
&. Document 'pprovals
(. Supportin# Information
%78(98%- 2+(, A5
ivf
Software Requirements Specification
1. Introduction
0$e fo**oin& subsections of t$e Softare Re'uirements Specifications 1SRS2
document s$ou*d provide an overvie of t$e entire SRS.
1.1 %urpose
+dentify t$e purpose of t$is SRS and its intended audience. +n t$is
subsection, describe t$e purpose of t$e particu*ar SRS and specify t$e
intended audience for t$e SRS.
1.2 Scope
+n t$is subsection3
112 +dentify t$e softare product1s2 to be produced by name
122 ()p*ain $at t$e softare product1s2 i**, and, if necessary, i** not do
132 Describe t$e app*ication of t$e softare bein& specified, inc*udin& re*evant
benefits, ob4ectives, and &oa*s
142 5e consistent it$ simi*ar statements in $i&$er6*eve* specifications if t$ey
e)ist
1.3 Definitions) 'cron*ms) and 'bbreviations.
Provide t$e definitions of a** terms, acronyms, and abbreviations re'uired to
proper*y interpret t$e SRS. 0$is information may be provided by reference
to one or more appendices in t$e SRS or by reference to documents. 0$is
information may be provided by reference to an Appendi).
1." eferences
+n t$is subsection3
112 Provide a comp*ete *ist of a** documents referenced e*se$ere in t$e
SRS
122 +dentify eac$ document by tit*e, report number 1if app*icab*e2, date,
and pub*is$in& or&ani.ation
132 Specify t$e sources from $ic$ t$e references can be obtained.
0$is information can be provided by reference to an appendi) or to anot$er
document.
%78(98%- 2+(, A5
%f
Software Requirements Specification
1.& Overvie+
+n t$is subsection3
112 Describe $at t$e rest of t$e SRS contains
122 ()p*ain $o t$e SRS is or&ani.ed
2. The Overall Description
Describe t$e &enera* factors t$at affect t$e product and its re'uirements.
0$is section does not state specific re'uirements. +nstead, it provides a
bac7&round for t$ose re'uirements, $ic$ are defined in section 3, and
ma7es t$em easier to understand.
2.1 %roduct %erspective
Put t$e product into perspective it$ ot$er re*ated products. +f t$e product
is independent and tota**y se*f6contained, it s$ou*d be so stated $ere. +f t$e
SRS defines a product t$at is a component of a *ar&er system, as fre'uent*y
occurs, t$en t$is subsection re*ates t$e re'uirements of t$e *ar&er system to
functiona*ity of t$e softare and identifies interfaces beteen t$at system
and t$e softare.
A b*oc7 dia&ram s$oin& t$e ma4or components of t$e *ar&er system,
interconnections, and e)terna* interfaces can be $e*pfu*.
0$e fo**oin& subsections describe $o t$e softare operates inside various
constraints.
2.1.1 S*stem Interfaces
,ist eac$ system interface and identify t$e functiona*ity of t$e softare to
accomp*is$ t$e system re'uirement and t$e interface description to matc$
t$e system.
2.1.2 Interfaces
%78(98%- 2+(, A5
(f
Software Requirements Specification
Specify3
112 0$e *o&ica* c$aracteristics of eac$ interface beteen t$e softare product
and its users
122 A** t$e aspects of optimi.in& t$e interface it$ t$e person $o must use t$e
system
2.1.3 ,ard+are Interfaces
Specify t$e *o&ica* c$aracteristics of eac$ interface beteen t$e softare
product and t$e $ardare components of t$e system. 0$is inc*udes
confi&uration c$aracteristics. +t a*so covers suc$ matters as $at devices
are to be supported, $o t$ey are to be supported and protoco*s.
2.1." Soft+are Interfaces
Specify t$e use of ot$er re'uired softare products and interfaces it$ ot$er
app*ication systems. !or eac$ re'uired softare product, inc*ude3
112 8ame
122 9nemonic
132 Specification number
142 :ersion number
152 Source
!or eac$ interface, provide3
112 Discussion of t$e purpose of t$e interfacin& softare as re*ated to t$is
softare product
122 Definition of t$e interface in terms of messa&e content and format

2.1.& Communications Interfaces
Specify t$e various interfaces to communications suc$ as *oca* netor7
protoco*s, etc.
2.1.( $emor* Constraints
%78(98%- 2+(, A5
,f
Software Requirements Specification
Specify any app*icab*e c$aracteristics and *imits on primary and secondary
memory.
2.1.- Operations
Specify t$e norma* and specia* operations re'uired by t$e user suc$ as3
112 0$e various modes of operations in t$e user or&ani.ation
122 Periods of interactive operations and periods of unattended operations
132 Data processin& support functions
142 5ac7up and recovery operations
18ote3 0$is is sometimes specified as part of t$e "ser +nterfaces section.2
2.1.. Site 'daptation e!uirements
+n t$is section3
112 Define t$e re'uirements for any data or initia*i.ation se'uences t$at are
specific to a &iven site, mission, or operationa* mode
122 Specify t$e site or mission6re*ated features t$at s$ou*d be modified to adapt
t$e softare to a particu*ar insta**ation
2.2 %roduct /unctions
Provide a summary of t$e ma4or functions t$at t$e softare i** perform.
Sometimes t$e function summary t$at is necessary for t$is part can be ta7en
direct*y from t$e section of t$e $i&$er6*eve* specification 1if one e)ists2 t$at
a**ocates particu*ar functions to t$e softare product.
!or c*arity3
112 0$e functions s$ou*d be or&ani.ed in a ay t$at ma7es t$e *ist of functions
understandab*e to t$e customer or to anyone e*se readin& t$e document for t$e
first time.
122 0e)tua* or &rap$ic met$ods can be used to s$o t$e different functions and
t$eir re*ations$ips. Suc$ a dia&ram is not intended to s$o a desi&n of a
product but simp*y s$os t$e *o&ica* re*ations$ips amon& variab*es.
2.3 0ser Characteristics
%78(98%- 2+(, A5
-f
Software Requirements Specification
Describe t$ose &enera* c$aracteristics of t$e intended users of t$e product
inc*udin& educationa* *eve*, e)perience, and tec$nica* e)pertise. Do not
state specific re'uirements but rat$er provide t$e reasons $y certain
specific re'uirements are *ater specified in section 3.
2." Constraints
Provide a &enera* description of any ot$er items t$at i** *imit t$e
deve*oper;s options. 0$ese can inc*ude3
112 Re&u*atory po*icies
122 <ardare *imitations 1for e)amp*e, si&na* timin& re'uirements2
132 +nterface to ot$er app*ications
142 Para**e* operation
152 Audit functions
1%2 #ontro* functions
1-2 <i&$er6order *an&ua&e re'uirements
(=) Si&na* $ands$a7e protoco*s 1for e)amp*e, =O86=O!!, A#>68A#>2
(9) Re*iabi*ity re'uirements
11?2 #ritica*ity of t$e app*ication
1112 Safety and security considerations
2.& 'ssumptions and Dependencies
,ist eac$ of t$e factors t$at affect t$e re'uirements stated in t$e SRS. 0$ese
factors are not desi&n constraints on t$e softare 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)amp*e,
an assumption mi&$t be t$at a specific operatin& system ou*d be avai*ab*e
on t$e $ardare desi&nated for t$e softare product. +f, in fact, t$e
operatin& system ere not avai*ab*e, t$e SRS ou*d t$en $ave to c$an&e
accordin&*y.
2.( 'pportionin# of e!uirements.
+dentify re'uirements t$at may be de*ayed unti* future versions of t$e system.
%78(98%- 2+(, A5
2f
Software Requirements Specification
3. Specific e!uirements
0$is section contains a** t$e softare re'uirements at a *eve* of detai*
sufficient to enab*e 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.
0$rou&$out t$is section, every stated re'uirement s$ou*d be e)terna**y
perceivab*e by users, operators, or ot$er e)terna* systems. 0$ese
re'uirements s$ou*d inc*ude at a minimum a description of every input
1stimu*us2 into t$e system, every output 1response2 from t$e system and a**
functions performed by t$e system in response to an input or in support of
an output. 0$e fo**oin& princip*es app*y3
112 Specific re'uirements s$ou*d be stated it$ a** t$e c$aracteristics of a &ood
SRS
correct
unambi&uous
comp*ete
consistent
ran7ed for importance and@or stabi*ity
verifiab*e
modifiab*e
traceab*e
122 Specific re'uirements s$ou*d be cross6referenced to ear*ier documents t$at
re*ate
132 A** re'uirements s$ou*d be uni'ue*y identifiab*e
142 #arefu* attention s$ou*d be &iven to or&ani.in& t$e re'uirements to ma)imi.e
readabi*ity
5efore e)aminin& specific ays of or&ani.in& t$e re'uirements it is $e*pfu*
to understand t$e various items t$at comprise re'uirements as described in
t$e fo**oin& subc*asses.
3.1 External Interfaces
%78(98%- 2+(, A5
4f
Software Requirements Specification
0$is contains a detai*ed description of a** inputs into and outputs from t$e
softare system. +t comp*ements t$e interface descriptions in section 2 but
does not repeat information t$ere.
+t contains bot$ content and format as fo**os3
8ame of item
Description of purpose
Source of input or destination of output
:a*id ran&e, accuracy and@or to*erance
"nits of measure
0imin&
Re*ations$ips to ot$er inputs@outputs
Screen formats@or&ani.ation
Aindo formats@or&ani.ation
Data formats
#ommand formats
(nd messa&es
3.2 /unctions
!unctiona* re'uirements define t$e fundamenta* actions t$at must ta7e p*ace
in t$e softare in acceptin& and processin& t$e inputs and in processin& and
&eneratin& t$e outputs. 0$ese are &enera**y *isted as Bs$a**C statements
startin& it$ D0$e system s$a**E
0$ese inc*ude3
:a*idity c$ec7s on t$e inputs
()act se'uence of operations
Responses to abnorma* situation, inc*udin&
Overf*o
#ommunication faci*ities
(rror $and*in& and recovery
(ffect of parameters
Re*ations$ip of outputs to inputs, inc*udin&
+nput@Output se'uences
%78(98%- 2+(, A5
6f
Software Requirements Specification
!ormu*as for input to output conversion
+t may be appropriate to partition t$e functiona* re'uirements into sub6
functions or sub6processes. 0$is does not imp*y t$at t$e softare desi&n i**
a*so be partitioned t$at ay.
3.3 %erformance e!uirements
0$is subsection specifies bot$ t$e static and t$e dynamic numerica*
re'uirements p*aced on t$e softare or on $uman interaction it$ t$e
softare, as a $o*e. Static numerica* re'uirements may inc*ude3
1a2 0$e number of termina*s to be supported
1b2 0$e number of simu*taneous users to be supported
1c2 Amount and type of information to be $and*ed
Static numerica* re'uirements are sometimes identified under a separate
section entit*ed capacity.
Dynamic numerica* re'uirements may inc*ude, for e)amp*e, t$e numbers of
transactions and tas7s and t$e amount of data to be processed it$in certain
time periods for bot$ norma* and pea7 or7*oad conditions.
A** of t$ese re'uirements s$ou*d be stated in measurab*e terms.
!or e)amp*e,
F5G of t$e transactions s$a** be processed in *ess t$an 1 second
rat$er t$an,
An operator s$a** not $ave to ait for t$e transaction to comp*ete.
18ote3 8umerica* *imits app*ied to one specific function are norma**y
specified as part of t$e processin& subpara&rap$ description of t$at
function.2
3." 1o#ical Database e!uirements
%78(98%- 2+(, A5
=f
Software Requirements Specification
0$is section specifies t$e *o&ica* re'uirements for any information t$at is to
be p*aced into a database. 0$is may inc*ude3
0ypes of information used by various functions
!re'uency of use
Accessin& capabi*ities
Data entities and t$eir re*ations$ips
+nte&rity constraints
Data retention re'uirements
3.& Desi#n Constraints
Specify desi&n constraints t$at can be imposed by ot$er standards, $ardare
*imitations, etc.
3.&.1 Standards Compliance
Specify t$e re'uirements derived from e)istin& standards or re&u*ations.
0$ey mi&$t inc*ude3
112 Report format
122 Data namin&
132 Accountin& procedures
142 Audit 0racin&
!or e)amp*e, t$is cou*d specify t$e re'uirement for softare to trace
processin& activity. Suc$ traces are needed for some app*ications to meet
minimum re&u*atory or financia* standards. An audit trace re'uirement
may, for e)amp*e, state t$at a** c$an&es to a payro** database must be
recorded in a trace fi*e it$ before and after va*ues.
3.( Soft+are S*stem 'ttributes
0$ere are a number of attributes of softare 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 ob4ective*y verified. 0$e fo**oin& items provide a partia* *ist of
e)amp*es.
3.(.1 eliabilit*
%78(98%- 2+(, A5
9f
Software Requirements Specification
Specify t$e factors re'uired to estab*is$ t$e re'uired re*iabi*ity of t$e
softare system at time of de*ivery.
3.(.2 'vailabilit*
Specify t$e factors re'uired to &uarantee a defined avai*abi*ity *eve* for t$e
entire system suc$ as c$ec7point, recovery, and restart.
3.(.3 Securit*
Specify t$e factors t$at ou*d protect t$e softare from accidenta* or
ma*icious access, use, modification, destruction, or disc*osure. Specific
re'uirements in t$is area cou*d inc*ude t$e need to3
"ti*i.e certain crypto&rap$ic tec$ni'ues
>eep specific *o& or $istory data sets
Assi&n certain functions to different modu*es
Restrict communications beteen some areas of t$e pro&ram
#$ec7 data inte&rity for critica* variab*es
3.(." $aintainabilit*
Specify attributes of softare t$at re*ate to t$e ease of maintenance of t$e
softare itse*f. 0$ere may be some re'uirement for certain modu*arity,
interfaces, comp*e)ity, etc. Re'uirements s$ou*d not be p*aced $ere 4ust
because t$ey are t$ou&$t to be &ood desi&n practices.
3.(.& %ortabilit*
Specify attributes of softare t$at re*ate to t$e ease of portin& t$e softare
to ot$er $ost mac$ines and@or operatin& systems. 0$is may inc*ude3
Percenta&e of components it$ $ost6dependent code
Percenta&e of code t$at is $ost dependent
"se of a proven portab*e *an&ua&e
"se of a particu*ar compi*er or *an&ua&e subset
"se of a particu*ar operatin& system
%78(98%- 2+(, A5
%7f
Software Requirements Specification
Once t$e re*evant c$aracteristics are se*ected, a subsection s$ou*d be
ritten for eac$, e)p*ainin& t$e rationa*e for inc*udin& t$is c$aracteristic
and $o it i** be tested and measured. A c$art *i7e t$is mi&$t be used to
identify t$e 7ey c$aracteristics 1ratin& t$em <i&$ or 9edium2, t$en
identifyin& $ic$ are preferred $en tradin& off desi&n or imp*ementation
decisions 1it$ t$e +D of t$e preferred one indicated in t$e c$art to t$e
ri&$t2.
ID Characteristic ,2$2
1
1 2 3 " & ( - . 3 14 11 12
% 3orrectness
( :fficiency
, ;le*ibility
- Inte!rity8Security
2 Interoperability
4 5aintainability
6 .ortability
= Reliability
9 Reusability
%7 "estability
%% 0sability
%( Availability
Definitions of t$e 'ua*ity c$aracteristics not defined in t$e para&rap$s
above fo**o.
H #orrectness 6 e)tent to $ic$ pro&ram satisfies specifications, fu*fi**s
userIs mission ob4ectives
H (fficiency 6 amount of computin& resources and code re'uired to
perform function
H !*e)ibi*ity 6 effort needed to modify operationa* pro&ram
H +nteroperabi*ity 6 effort needed to coup*e one system it$ anot$er
H Re*iabi*ity 6 e)tent to $ic$ pro&ram performs it$ re'uired precision
H Reusabi*ity 6 e)tent to $ic$ it can be reused in anot$er app*ication
H 0estabi*ity 6 effort needed to test to ensure performs as intended
H "sabi*ity 6 effort re'uired to *earn, operate, prepare input, and
interpret output
%78(98%- 2+(, A5
%%f
Software Requirements Specification
3.- Or#ani5in# the Specific e!uirements
!or anyt$in& but trivia* systems t$e detai*ed re'uirements tend to be
e)tensive. !or t$is reason, it is recommended t$at carefu* consideration be
&iven to or&ani.in& t$ese in a manner optima* for understandin&. 0$ere is
no one optima* or&ani.ation for a** systems. Different c*asses of systems
*end t$emse*ves to different or&ani.ations of re'uirements in section 3. Some
of t$ese or&ani.ations are described in t$e fo**oin& subc*asses.
3.-.1 S*stem $ode
Some systems be$ave 'uite different*y dependin& on t$e mode of operation.
A$en or&ani.in& by mode t$ere are to possib*e out*ines. 0$e c$oice
depends on $et$er interfaces and performance are dependent on mode.
3.-.2 0ser Class
Some systems provide different sets of functions to different c*asses of users.
3.-.3 Ob6ects
Ob4ects are rea*6or*d entities t$at $ave a counterpart it$in t$e system.
Associated it$ eac$ ob4ect is a set of attributes and functions. 0$ese
functions are a*so ca**ed services, met$ods, or processes. 8ote t$at sets of
ob4ects may s$are attributes and services. 0$ese are &rouped to&et$er as
c*asses.
%78(98%- 2+(, A5
%(f
Software Requirements Specification
3.-." /eature
A feature is an e)terna**y desired service by t$e system t$at may re'uire a
se'uence of inputs to effect t$e desired resu*t. (ac$ feature is &enera**y
described in as se'uence eof stimu*us6response pairs.
3.-.& Stimulus
Some systems can be best or&ani.ed by describin& t$eir functions in terms of
stimu*i.
3. -.( esponse
Some systems can be best or&ani.ed by describin& t$eir functions in support
of t$e &eneration of a response.
3.-.- /unctional ,ierarch*
A$en none of $e above or&ani.ationa* sc$emes prove $e*pfu*, t$e overa**
functiona*ity can be or&ani.ed into a $ierarc$y of functions or&ani.ed by
eit$er common inputs, common outputs, or common interna* data access.
Data f*o dia&rams and data dictionaries can be use dot s$o t$e
re*ations$ips beteen and amon& t$e functions and data.
3.. 'dditional Comments
A$enever a ne SRS is contemp*ated, more t$an one of t$e or&ani.ationa*
tec$ni'ues &iven in 3.- may be appropriate. +n suc$ cases, or&ani.e t$e
specific re'uirements for mu*tip*e $ierarc$ies tai*ored to t$e specific needs
of t$e system under specification.
0$ree are many notations, met$ods, and automated support too*s avai*ab*e
to aid in t$e documentation of re'uirements. !or t$e most part, t$eir
usefu*ness is a function of or&ani.ation. !or e)amp*e, $en or&ani.in& by
mode, finite state mac$ines or state c$arts may prove $e*pfu*J $en
or&ani.in& by ob4ect, ob4ect6oriented ana*ysis may prove $e*pfu*J $en
or&ani.in& by feature, stimu*us6response se'uences may prove $e*pfu*J $en
%78(98%- 2+(, A5
%,f
Software Requirements Specification
or&ani.in& by functiona* $ierarc$y, data f*o dia&rams and data
dictionaries may prove $e*pfu*.
+n any of t$e out*ines be*o, t$ose sections ca**ed B!unctiona* Re'uirement
iC may be described in native *an&ua&e, in pseudocode, in a system
definition *an&ua&e, or in four subsections tit*ed3 +ntroduction, +nputs,
Processin&, Outputs.
". Chan#e $ana#ement %rocess

+dentify t$e c$an&e mana&ement process to be used to identify, *o&, eva*uate,
and update t$e SRS to ref*ect c$an&es in pro4ect scope and re'uirements.
&. Document 'pprovals
+dentify t$e approvers of t$e SRS document. Approver name, si&nature, and
date s$ou*d be used.
(. Supportin# Information
0$e supportin& information ma7es t$e SRS easier to use. +t inc*udes3
0ab*e of #ontents
+nde)
Appendices
0$e Appendices are not a*ays considered part of t$e actua* re'uirements
specification and are not a*ays necessary. 0$ey may inc*ude3
1a2 Samp*e +@O formats, descriptions of cost ana*ysis studies, resu*ts of
user surveys
1b2 Supportin& or bac7&round information t$at can $e*p t$e readers of
t$e SRS
1c2 A description of t$e prob*ems to be so*ved by t$e softare
1d2 Specia* pac7a&in& instructions for t$e code and t$e media to meet
security, e)port, initia* *oadin&, or ot$er re'uirements
%78(98%- 2+(, A5
%-f
Software Requirements Specification
A$en Appendices are inc*uded, t$e SRS s$ou*d e)p*icit*y state $et$er or
not t$e Appendices are to be considered part of t$e re'uirements.

"ables on the followin! pa!es provide alternate ways to structure section , on the
specific requirements.
%78(98%- 2+(, A5
%2f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* $ode7 8ersion 1
,. Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( ;unctional requirements
,.(.% 5ode %
,.(.%.% ;unctional requirement %.%
.....
,.(.%.n ;unctional requirement %.n
,.(.( 5ode (
.....
,.(.m 5ode m
,.(.m.% ;unctional requirement m.%
.....
,.(.m.n ;unctional requirement m.n
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
%4f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* $ode7 8ersion 2
,. Specific Requirements
,.% ;unctional Requirements
,.%.% 5ode %
,.%.%.% :*ternal interfaces
,.%.%.% 0ser interfaces
,.%.%.( 1ardware interfaces
,.%.%., Software interfaces
,.%.%.- 3ommunications interfaces
,.%.%.( ;unctional Requirement
,.%.%.(.% ;unctional requirement %
.....
,.%.%.(.n ;unctional requirement n
,.%.%., .erformance
,.%.( 5ode (
.....
,.%.m 5ode m
,.( 'esi!n constraints
,., Software system attributes
,.- /ther requirements

%78(98%- 2+(, A5
%6f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* 0ser Class
,. Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( ;unctional requirements
,.(.% 0ser class %
,.(.%.% ;unctional requirement %.%
.....
,.(.%.n ;unctional requirement %.n
,.(.( 0ser class (
.....
,.(.m 0ser class m
,.(.m.% ;unctional requirement m.%
.....
,.(.m.n ;unctional requirement m.n
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
%=f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* Ob6ect
, Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( 3lasses8/b#ects
,.(.% 3lass8/b#ect %
,.(.%.% Attributes (direct or inherited)
,.(.%.%.% Attribute %
.....
,.(.%.%.n Attribute n
,.(.%.( ;unctions (services, methods, direct or inherited)
,.(.%.(.% ;unctional requirement %.%
.....
,.(.%.(.m ;unctional requirement %.m
,.(.%., 5essa!es (communications received or sent)
,.(.( 3lass8/b#ect (
.....
,.(.p 3lass8/b#ect p
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
%9f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* /eature
, Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( System features
,.(.% System ;eature %
,.(.%.% Introduction8.urpose of feature
,.(.%.( Stimulus8Response sequence
,.(.%., Associated functional requirements
,.(.%.,.% ;unctional requirement %
.....
,.(.%.,.n ;unctional requirement n
,.(.( System ;eature (
.....
,.(.m System ;eature m
.....
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
(7f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* Stimulus
, Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( ;unctional requirements
,.(.% Stimulus %
,.(.%.% ;unctional requirement %.%
.....
,.(.%.n ;unctional requirement %.n
,.(.( Stimulus (
.....
,.(.m Stimulus m
,.(.m.% ;unctional requirement m.%
.....
,.(.m.n ;unctional requirement m.n
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
(%f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* esponse
, Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( ;unctional requirements
,.(.% Response %
,.(.%.% ;unctional requirement %.%
.....
,.(.%.n ;unctional requirement %.n
,.(.( Response (
.....
,.(.m Response m
,.(.m.% ;unctional requirement m.%
.....
,.(.m.n ;unctional requirement m.n
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
((f
Software Requirements Specification
Outline for SS Section 3
Or#ani5ed b* /unctional ,ierarch*
, Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( ;unctional requirements
,.(.% Information flows
,.(.%.% 'ata flow dia!ram %
,.(.%.%.% 'ata entities
,.(.%.%.( .ertinent processes
,.(.%.%., "opolo!y
,.(.%.( 'ata flow dia!ram (
,.(.%.(.% 'ata entities
,.(.%.(.( .ertinent processes
,.(.%.(., "opolo!y
.....
,.(.%.n 'ata flow dia!ram n
,.(.%.n.% 'ata entities
,.(.%.n.( .ertinent processes
,.(.%.n., "opolo!y
,.(.( .rocess descriptions
,.(.(.% .rocess %
,.(.(.%.% Input data entities
,.(.(.%.( Al!orithm or formula of process
,.(.(.%., Affected data entities
,.(.(.( .rocess (
,.(.(.(.% Input data entities
,.(.(.(.( Al!orithm or formula of process
,.(.(.(., Affected data entities
.>.
,.(.(.m .rocess m
,.(.(.m.% Input data entities
,.(.(.m.( Al!orithm or formula of process
,.(.(.m., Affected data entities
,.(., 'ata construct specifications
,.(.,.% 3onstruct %
,.(.,.%.% Record type
,.(.,.%.( 3onstituent fields
,.(.,.( 3onstruct (
,.(.,.(.% Record type
,.(.,.(.( 3onstituent fields
>..
,.(.,.p 3onstruct p
,.(.,.p.% Record type
%78(98%- 2+(, A5
(,f
Software Requirements Specification
,.(.,.p.( 3onstituent fields
,.(.- 'ata dictionary
,.(.-.% 'ata element %
,.(.-.%.% ame
,.(.-.%.( Representation
,.(.-.%., 0nits8;ormat
,.(.-.%.- .recision8Accuracy
,.(.-.%.2 Ran!e
,.(.-.( 'ata element (
,.(.-.(.% ame
,.(.-.(.( Representation
,.(.-.(., 0nits8;ormat
,.(.-.(.- .recision8Accuracy
,.(.-.(.2 Ran!e
>..
,.(.-.' 'ata element '
,.(.-.'.% ame
,.(.-.'.( Representation
,.(.-.'., 0nits8;ormat
,.(.-.'.- .recision8Accuracy
,.(.-.'.2 Ran!e
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
(-f
Software Requirements Specification
Outline for SS Section 3
Sho+in# $ultiple Or#ani5ations
, Specific Requirements
,.% :*ternal interface requirements
,.%.% 0ser interfaces
,.%.( 1ardware interfaces
,.%., Software interfaces
,.%.- 3ommunications interfaces
,.( ;unctional requirements
,.(.% 0ser class %
,.(.%.% ;eature %.%
,.(.%.%.% Introduction8.urpose of feature
,.(.%.%.( Stimulus8Response sequence
,.(.%.%., Associated functional requirements
,.(.%.( ;eature %.(
,.(.%.(.% Introduction8.urpose of feature
,.(.%.(.( Stimulus8Response sequence
,.(.%.(., Associated functional requirements
>..
,.(.%.m ;eature %.m
,.(.%.m.% Introduction8.urpose of feature
,.(.%.m.( Stimulus8Response sequence
,.(.%.m., Associated functional requirements
,.(.( 0ser class (
.....
,.(.n 0ser class n
.....
,., .erformance Requirements
,.- 'esi!n 3onstraints
,.2 Software system attributes
,.4 /ther requirements
%78(98%- 2+(, A5
(2f