Software Requirements Specifi cation (SRS)

Software Requirements Specification

for
<Name of Project>
<authors>
<date>
Version

Release
Date

Responsible Party

0.1

Major Changes

Initial Document Release for Comment

Table of Contents
Builtthetableofcontentshere.Insertitwhenyoufinishyourdocument.

1. Introduction
ThefollowingsubsectionsoftheSRSshouldprovideanoverviewoftheentireSRS.

1.1 Purpose
IdentifythepurposeofthisSRSanditsintendedaudience.

1.2 Scope.
Inthissubsection:
(1)Identifythesoftwareproduct(s)tobeproducedbyname

(2)Explainwhatthesoftwareproduct(s)will,and,ifnecessary,willnotdo
(3)Describetheapplicationofthesoftwarebeingspecified.Asaportionofthis,itshould:
(a)Describetherelevantbenefits,objectives,andgoalsaspreciselyaspossible
(b)Beconsistentwithsimilarstatementsinhigherlevelspecificationsiftheyexist.

1.3 Definitions, Acronyms, and Abbreviations

Providethedefinitionsofallterms,acronyms,andabbreviationsrequiredtoproperlyinterpretthe
SRS.Thisinformationmaybeprovidedbyreferencetoanappendixorotherdocument(s).

1.4 References
Inthissubsection:
(1)ProvideacompletelistofalldocumentsreferencedelsewhereintheSRS.
(2)Identifyeachdocumentbytitle,reportnumber(ifapplicable),date,andpublishingorganization.
(3)Specifythesourcesfromwhichthereferencescanbeobtained.

1.5 Overview
DescribetherestoftheSRSandhowitisorganized.

2. The General Description

Describethegeneralfactorsthataffecttheproductanditsrequirements.Thissectionusuallyconsists
of the five subsections that follow. This section does not state specific requirements; each of its
subsectionsmakesthoserequirementseasiertounderstand;theydonotspecifydesignorexpressspecific
requirements.Suchdetailisprovidedinsection3.

2.1 Product Perspective

ThissubsectionoftheSRSrelatestheproducttootherproductsorprojects.
(1)Iftheproductisindependentandtotallyselfcontained,itshouldbestatedhere.
(2)IftheSRSdefinesaproductthatisacomponentofalargersystemorproject:
(a) Describe the functions of each component of the larger system or project, and identify
interfaces

(b)Identifytheprincipalexternalinterfacesofthissoftwareproduct(notadetaileddescription)
(c)Describethecomputerhardwareandperipheralequipmenttobeused(overviewonly)
Ablockdiagramshowingthemajorcomponentsofthelargersystemorproject,interconnections,and
externalinterfacescanbeveryhelpful.

2.2 Product Functions

Provideasummaryofthefunctionsthatthesoftwarewillperform.Sometimesthefunctionsummary
thatisnecessaryforthispartcanbetakendirectlyfromthesectionofthehigherlevelspecification(if
oneexists)thatallocatesparticularfunctionstothesoftwareproduct.Thefunctionsshouldbeorganized
inawaythatmakesthelistoffunctionsunderstandabletothecustomerortoanyoneelsereadingthe
documentforthefirsttime.Blockdiagramsshowingthedifferentfunctionsandtheirrelationshipscanbe
helpful.Suchadiagramisnotarequirementonthedesignofaproductitself;itissimplyaneffective
explanatorytool.

2.3 User Characteristics

Describethosegeneralcharacteristicsoftheeventualusersoftheproductthatwillaffectthespecific
requirements.
Manypeopleinteractwithasystemduringtheoperationandmaintenancephaseofthesoftwarelife
cycle. Some of these people are users, operators, and maintenance and systems personnel. Certain
characteristics of these people, such as educational level, experience, andtechnical expertise impose
importantconstraintsonthesystem'soperatingenvironment.

2.4 General Constraints

Provideageneraldescriptionofanyotheritemsthatwilllimitthedeveloper'soptionsfordesigningthe
system.Thesecaninclude:
(1)Regulatorypolicies
(2)Hardwarelimitations;forexample,signaltimingrequirements
(3)Interfacetootherapplications
(4)Paralleloperation
(5)Auditfunctions
(6)Controlfunctions
(7)Higherorderlanguagerequirements

(8)Signalhandshakeprotocols;forexample,XONXOFF,ACKNACK.
(9)Criticalityoftheapplication
(10)Safetyandsecurityconsiderations

2.5 Assumptions and Dependencies

ListanddescribeeachofthefactorsthataffecttherequirementsstatedintheSRS.Thesefactorsarenot
designconstraintsonthesoftwarebutanychangestothemcanaffecttherequirementsintheSRS. For
example,anassumptionmightbethataspecificoperatingsystemwillbeavailableonthehardware
designatedforthesoftwareproduct.If,infact,theoperatingsystemisnotavailable,theSRSwouldthen
havetochange.

3. Specific Requirements
ThissectionoftheSRSshouldcontainallthedetailsthesoftwaredeveloperneedstocreateadesign.
ThisistypicallythelargestandmostimportantpartoftheSRS.
(1) The details within it should be defined as individual specific requirements, following the
guidelinesforsoundrequirements(verifiable,unambiguous,etc.)
(2)Specificrequirementsshouldbeorganizedinalogicalandreadablefashion.
(3) Eachrequirementshouldbestatedsuchthatitsachievementcanbeobjectivelyverifiedbya
prescribedmethod.
(4) Sources of a requirement should be identified where that is useful in understanding the
requirement.
(5)Onewaytoclassifythespecificrequirementsisasfollows:
(a)FunctionalRequirements
(b)PerformanceRequirements
(c)DesignConstraints
(d)Attributes
(e)ExternalInterfaceRequirements
TheorganizationofthissectionoftheSRSshouldbechosenwiththegoalofproperlyspecifyingthe
requirementsinthemostreadablemanner.

3.1. Functional Requirements

ThissubsectionoftheSRSshouldspecifywhatistobedonebytheproduct,towhatlevelorspecific
requirement,whatinputsshouldbetransformedtowhatoutputs(nothowthisisdone),whatspecific
operationsarerequired. Wheretherationaleforarequirementisnotobvious,provideanexplanation.
Whereissuesneedtoberesolved,citethose.
For each function, specify requirements on inputs, processing, and outputs. These are usually
organizedwiththesefoursubparagraphs:
(1)Purposeofthefunction:Providerationaletoclarifytheintentofthefunction.
(2) Inputs: sources, valid ranges of values, any timing concerns, operator requirements, special
interfaces
(3)Operationstobeperformed:validitychecks,responsestoabnormalconditions,typesofprocessing
required
(4) Outputs:destinations,validrangesofvalues,timingconcerns,handlingofillegalvalues,error
messages,interfacesrequired

3.2. External Interface Requirements

Thisshouldspecify:
(1) The characteristics that the software must support for each human interface to the software
product.Forexample,iftheuserofthesystemoperatesthroughadisplayterminal,thefollowingshould
bespecified:
(a)Requiredscreenformats
(b)Pagelayoutandcontentofanyreportsormenus
(c)Relativetimingofinputsandoutputs
(d)Availabilityofsomeformofprogrammablefunctionkeys.
(2) Alltheaspectsofoptimizingtheinterfacewiththepersonwhomustusethesystem. Thismay
simplycomprisealistofdo'sanddon'tsonhowthesystemwillappeartotheuser
Specifythelogicalcharacteristicsofeachinterfacebetweenthesoftwareproductandthehardware
componentsofthesystem.Includesuchmattersaswhatdevicesaretobesupported,howtheyaretobe
supported,andprotocols.
Specifytheuseofotherrequiredsoftwareproducts(forexample,adatamanagementsystem,an
operatingsystem,oramathematicalpackage),andinterfaceswithotherapplicationsystems.
Foreachrequiredsoftwareproduct,thefollowingshouldbeprovided:

(1)Name
(2)Mnemonic
(3)SpecificationNumber
(4)Versionnumber
(5)Source
Foreachinterface:
(1)Discussthepurposeoftheinterfacingsoftwareasrelatedtothissoftwareproduct.
(2)Definetheinterfaceintermsofmessagecontentandformat.Itisnotnecessarytodetailanywell
documentedinterface,butareferencetothedocumentdefiningtheinterfaceisrequired.
Specifythevariousinterfacestocommunicationssuchaslocalnetworkprotocols,etc.

3.3. Performance Requirements

Thissubsectionshouldspecifyboththestaticandthedynamicnumericalrequirementsplacedonthe
softwareoronhumaninteractionwiththesoftware,asawhole.
(1)Staticnumericalrequirementsmayinclude:
(a)Thenumberofterminalstobesupported
(b)Thenumberofsimultaneoususerstobesupported
(c)Numberoffilesandrecordstobehandled
(d)Sizesoftablesandfiles
Staticnumericalrequirementsaresometimesidentifiedunderaseparatesectionentitledcapacity.
(2)Dynamicnumericalrequirementsmayinclude,forexample,thenumbersoftransactionsandtasks
andtheamountofdatatobeprocessedwithincertaintimeperiodsforbothnormalandpeakworkload
conditions.
Alloftheserequirementsshouldbestatedinmeasurableterms,forexample,95%ofthetransactions
shallbeprocessedinlessthan1s,ratherthan,operatorshallnothavetowaitforthetransactionto
complete.
Note: Numerical limits applied to one specific function are normally specified as part of the
processingsubparagraphdescriptionofthatfunction.

3.4. Design Constraints

Designconstraintscanbeimposedbyotherstandards,hardwarelimitations,etc.
Specifytherequirementsderivedfromexistingstandardsorregulations.Theymightinclude:
(1)Reportformat
(2)Datanaming
(3)Accountingprocedures
(4) AuditTracing. Forexample,thiscouldspecifytherequirementforsoftwaretotraceprocessing
activity. Such traces are needed for some applications to meet minimum government or financial
standards. Anaudittracerequirementmight,forexample,statethatallchangestoapayrolldatabase
mustberecordedinatracefilewithbeforeandaftervalues.
Identifytherequirementsforthesoftwaretooperateinsidevarioushardwareconstraints

3.5. Quality Characteristics

Thereareanumberofqualitycharacteristicsthatcanapplytosoftware.Picktheonesmostimportant
tothisproductanddevelopasectionforeachone.Definitionsofthequalitycharacteristicsfollow.
Correctnessextenttowhichprogramsatisfiesspecifications,fulfillsusersmissionobjectives
Efficiencyamountofcomputingresourcesandcoderequiredtoperformfunction
Flexibilityeffortneededtomodifyoperationalprogram
Integrity/securityextenttowhichaccesstosoftwareordatabyunauthorizedpeoplecanbe
controlled
Interoperabilityeffortneededtocoupleonesystemwithanother
Maintainabilityeffortrequiredtolocateandfixanerrorduringoperation
Portabilityeffortneededtotransferfromoneh/wors/wenvironmenttoanother
Reliabilityextenttowhichprogramperformswithrequiredprecision
Reusabilityextenttowhichitcanbereusedinanotherapplication
Testabilityeffortneededtotesttoensureperformsasintended
Usabilityeffortrequiredtolearn,operate,prepareinput,interpretoutput

Describetherationaleforincludingthischaracteristicforthisproduct.
Describehowthepresence,absence,orlevelofthischaracteristicwillbemeasured;identifywaysto
testthecharacteristiconcetheproductiscomplete.

3.6. Other Requirements

Certainrequirementsmay,duetothenatureofthesoftware,theuserorganization,etc.,beplacedin
separatecategoriessuchasthosebelow.
Thiscouldspecifytherequirementsforanydatabasethatistobedevelopedaspartoftheproduct.
Thismightinclude:
(1)Typesofinformation
(2)Frequencyofuse
(3)Accessingcapabilities
(4)Dataelementandfiledescriptions
(5)Relationshipofdataelements,recordsandfiles
(6)Staticanddynamicorganization
(7)Retentionrequirementsfordata
Note:Ifanexistingdatabasepackageistobeused,thispackageshouldbenamedunderInterfacesto
Softwareanddetailsofusingitspecifiedthere.
Thiscouldspecifythenormalandspecialoperationsrequiredbytheusersuchas:
(1)Thevariousmodesofoperationsintheuserorganization;forexample,userinitiatedoperations
(2)Periodsofinteractiveoperationsandperiodsofunattendedoperations
(3)Dataprocessingsupportfunctions
(4)Backupandrecoveryoperations
Note:ThisissometimesspecifiedaspartoftheUserInterfacessection.
Thiscould:
(1) Definetherequirementsforanydataorinitializationsequencesthatarespecifictoagivensite,
mission,oroperationalmode,forexample,safetylimits.

(2)Specifyfeaturesthatshouldbemodifiedtoadaptthesoftwaretoaninstallation.

4. Supporting Information
Thesupportinginformation;thatis,theTableofContents,theAppendices,andtheIndex,maketheSRS
easiertouse.TheAppendicesarenotalwaysconsideredpartoftheactualrequirementsspecificationand
arenotalwaysnecessary.Theymightinclude:
(a)SampleI/Oformats,descriptionsofcostanalysisstudies,resultsofusersurveys.
(b)SupportingorbackgroundinformationthatcanhelpthereadersoftheSRS.
(c)Adescriptionoftheproblemstobesolvedbythesoftware.
(d)Thehistory,background,experienceandoperationalcharacteristicsoftheorganizationtobe
supported.
(e)Acrossreferencelist,arrangedbymilestone,ofthoseincompletesoftwarerequirementsthat
aretobecompletedbyspecifiedmilestones.
(f) Specialpackaginginstructionsforthecodeandthemediatomeetsecurity,export,initial
loading,orotherrequirements.
(3)WhenAppendicesareincluded,theSRSshouldexplicitlystatewhetherornottheAppendicesare
tobeconsideredpartoftherequirements.