Software Requirements Specification

Template
COMP3033 Software Engineering
14 January 2015
The following annotated template is for use with the Software Requirements
Specification (SRS) requirement of COMP3033. The course facilitator must
approve any modifications to the overall structure of this document.
Template Usage:
Text contained within angle brackets (<, >) shall be replaced by your
project-specific information and/or details. For example, <Project Name>
will be replaced with either
Smart Home or Sensor Network.
Italicized text is included to briefly annotate the purpose of each section
within this template. This text should not appear in the final version of
your submitted SRS.

This cover page is not a part of the final template and should be removed
before your SRS is submitted.
Acknowledgements:
Sections of this document are based upon the IEEE Guide to Software
Requirements Specification (ANSI/IEEE Std. 830-1984). The SRS templates of
Dr. Orest Pilskalns (WSU, Vancover) and Jack Hagemeister (WSU, Pullman)
have also be used as guides in developing this template for the WSU-TC
Spring 2005 CptS 322 course.

COMP3033SoftwareRequirementsSpecificationTemplate

POLYTECHNIC UNIVERSITY OF THE PHILIPPINES

COLLEGE OF COMPUTER AND INFORMATION
SCIENCES SECOND SEMESTER, A.Y. 2014-2015

<Project Name>
Software Requirements
Specification

<Version>
<Date>
<Team Name>
<Names of Team Members>

Prepared for
COMP3033 Software Engineering

Client/Facilitator: Mr. Peachyco Morada

<ProjectName>

Revision History
Date
<date>

Description
<Version 1>

Author
Comments
<Your Name> <First Revision>

Document Approval
The following Software Requirements Specification has been accepted and
approved by the following:
Signature
Printed Name
Title
Date
<Your Name>

Project Manager

Peachyco Morada

Client

SoftwareRequirementsSpecification Page2of
10

<ProjectName>

Table of Contents
REVISION HISTORY 2
DOCUMENT APPROVAL
1.INTRODUCTION

1.1PURPOSE 5
1.2SCOPE
5
1.3DEFINITIONS,ACRONYMS,ANDABBREVIATIONS
1.4REFERENCES
5
1.5OVERVIEW 5
2.GENERALDESCRIPTION

2.1PRODUCTPERSPECTIVE
6
2.2PRODUCTFUNCTIONS
6
2.3USERCHARACTERISTICS
6
2.4GENERALCONSTRAINTS
6
2.5ASSUMPTIONSANDDEPENDENCIES

3.SPECIFICREQUIREMENTS 6
3.1EXTERNALINTERFACEREQUIREMENTS
7
3.1.1UserInterfaces
7
3.1.2HardwareInterfaces 7
3.1.3SoftwareInterfaces
7
3.1.4CommunicationsInterfaces
7
3.2FUNCTIONALREQUIREMENTS
7
3.2.1<FunctionalRequirementorFeature#1>7
3.2.2<FunctionalRequirementorFeature#2>7
3.3USECASES
7
3.3.1UseCase#1 7
3.3.2UseCase#2 7
3.4CLASSES/OBJECTS 7
3.4.1<Class/Object#1> 7
3.4.2<Class/Object#2> 7
3.5NONFUNCTIONALREQUIREMENTS 8
3.5.1Performance 8
3.5.2Reliability
8
3.5.3Availability 8
3.5.4Security
8
3.5.5Maintainability
8
3.5.6Portability
8
3.6INVERSEREQUIREMENTS
8
3.7DESIGNCONSTRAINTS
8
3.8LOGICALDATABASEREQUIREMENTS 8
3.9OTHERREQUIREMENTS
8
4.ANALYSISMODELS 8
4.1SEQUENCEDIAGRAMS
9
4.3DATAFLOWDIAGRAMS(DFD)
9
4.2STATETRANSITIONDIAGRAMS(STD)

5.CHANGEMANAGEMENTPROCESS
A.APPENDICES

A.1APPENDIX1

SoftwareRequirementsSpecification Page3of
10

<ProjectName>
A.2APPENDIX2 9

SoftwareRequirementsSpecification Page4of
10

<ProjectName>

1.Introduction
TheintroductiontotheSoftwareRequirementSpecification(SRS)documentshouldprovidean
overviewofthecompleteSRSdocument.Whilewritingthisdocumentpleaserememberthatthis
documentshouldcontainalloftheinformationneededbyasoftwareengineertoadequately
designandimplementthesoftwareproductdescribedbytherequirementslistedinthis
document.(Note:thefollowingsubsectionannotatesarelargelytakenfromtheIEEEGuideto
SRS).

1.1Purpose
WhatisthepurposeofthisSRSandthe(intended)audienceforwhichitiswritten?

1.2Scope
Thissubsectionshould:
(1) Identifythesoftwareproduct(s)tobeproducedbyname;forexample,HostDBMS,Report
Generator,etc.
(2) Explainwhatthesoftwareproduct(s)will,and,ifnecessary,willnotdo
(3) Describetheapplicationofthesoftwarebeingspecified.Asaportionofthis,itshould:
(1) Describeallrelevantbenefits,objectives,andgoalsaspreciselyaspossible.For
example,tosaythatonegoalistoprovideeffectivereportingcapabilitiesisnotas
goodassayingparameterdriven,userdefinablereportswitha2hturnaroundandon
lineentryofuserparameters.
(2) Beconsistentwithsimilarstatementsinhigherlevelspecifications(forexample,
theSystemRequirementSpecification),iftheyexist.Whatisthescopeofthis
softwareproduct?

1.3Definitions,Acronyms,andAbbreviations
Thissubsectionshouldprovidethedefinitionsofallterms,acronyms,andabbreviations
requiredtoproperlyinterprettheSRS.Thisinformationmaybeprovidedbyreferencetooneor
moreappendixesintheSRSorbyreferencetootherdocuments.

1.4References
Thissubsectionshould:
(1) Provide a complete list of all documents referenced elsewhere in the SRS, or in a
separate,specifieddocument.
(2) Identify each document by title, report number if applicable date, and
publishingorganization.
(3) Specifythesourcesfromwhichthereferencescanbeobtained.
Thisinformationmaybeprovidedbyreferencetoanappendixortoanotherdocument.

1.5Overview
Thissubsectionshould:
(1)DescribewhattherestoftheSRScontains

SoftwareRequirementsSpecification Page5of
10

<ProjectName>
(2)ExplainhowtheSRSisorganized.

2.GeneralDescription
ThissectionoftheSRSshoulddescribethegeneralfactorsthataffect'theproductandits
requirements.Itshouldbemadeclearthatthissectiondoesnotstatespecificrequirements;it
onlymakesthoserequirementseasiertounderstand.

2.1ProductPerspective
ThissubsectionoftheSRSputstheproductintoperspectivewithotherrelatedproducts
orprojects.(SeetheIEEEGuidetoSRSformoredetails).

2.2ProductFunctions
ThissubsectionoftheSRSshouldprovideasummaryofthefunctionsthatthesoftware
willperform.

2.3UserCharacteristics
ThissubsectionoftheSRSshoulddescribethosegeneralcharacteristicsoftheeventualusers
oftheproductthatwillaffectthespecificrequirements.(SeetheIEEEGuidetoSRSformore
details).

2.4GeneralConstraints
ThissubsectionoftheSRSshouldprovideageneraldescriptionofanyotheritemsthatwill
limitthedevelopersoptionsfordesigningthesystem.(SeetheIEEEGuidetoSRSfora
partiallistofpossiblegeneralconstraints).

2.5AssumptionsandDependencies
ThissubsectionoftheSRSshouldlisteachofthefactorsthataffecttherequirementsstatedin
theSRS.Thesefactorsarenotdesignconstraintsonthesoftwarebutare,rather,anychanges
tothemthatcanaffecttherequirementsintheSRS.Forexample,anassumptionmightbethata
specificoperatingsystemwillbeavailableonthehardwaredesignatedforthesoftware
product.If,infact,theoperatingsystemisnotavailable,theSRSwouldthenhavetochange
accordingly.

3.SpecificRequirements
ThiswillbethelargestandmostimportantsectionoftheSRS.Thecustomerrequirementswill
beembodiedwithinSection2,butthissectionwillgivetheDrequirementsthatareusedto
guidetheprojectssoftwaredesign,implementation,andtesting.
Eachrequirementinthissectionshouldbe:
1
Correct
2
Traceable(bothforwardandbackwardtoprior/futureartifacts)
3
Unambiguous
4
Verifiable(i.e.,testable)
5
Prioritized(withrespecttoimportanceand/orstability)
SoftwareRequirementsSpecification Page6of

10

<ProjectName>
1
2
3

Complete
Consistent
Uniquelyidentifiable(usuallyvianumberinglike3.4.5.6)

Attentionshouldbepaidtothecarefullyorganizetherequirementspresentedinthissectionso
thattheymayeasilyaccessedandunderstood.Furthermore,thisSRSisnotthesoftwaredesign
document,thereforeoneshouldavoidthetendencytooverconstrain(andthereforedesign)the
softwareprojectwithinthisSRS.

3.1ExternalInterfaceRequirements
3.1.1 UserInterfaces
3.1.2 HardwareInterfaces
3.1.3 SoftwareInterfaces
3.1.4 CommunicationsInterfaces

3.2FunctionalRequirements
Thissectiondescribesspecificfeaturesofthesoftwareproject.Ifdesired,somerequirements
maybespecifiedintheusecaseformatandlistedintheUseCasesSection.
3.2.1<FunctionalRequirementorFeature#1>
3.2.1.1 Introduction
3.2.1.2 Inputs
3.2.1.3 Processing
3.2.1.4 Outputs
3.2.1.5 ErrorHandling
3.2.2<FunctionalRequirementorFeature#2>

3.3UseCases
3.3.1 UseCase#1
3.3.2 UseCase#2

3.4Classes/Objects
3.4.1<Class/Object#1>
3.4.1.1 Attributes
3.4.1.2 Functions
<Referencetofunctionalrequirementsand/orusecases>
3.4.2<Class/Object#2>

SoftwareRequirementsSpecification Page7of 10

<ProjectName>

3.5NonFunctionalRequirements
Nonfunctionalrequirementsmayexistforthefollowingattributes.Oftentheserequirements
mustbeachievedatasystemwidelevelratherthanataunitlevel.Statetherequirementsinthe
followingsectionsinmeasurableterms(e.g.,95%oftransactionshallbeprocessedinlessthan
asecond,systemdowntimemaynotexceed1minuteperday,>30dayMTBFvalue,etc.).
3.5.1 Performance
3.5.2 Reliability
3.5.3 Availability
3.5.4 Security
3.5.5 Maintainability
3.5.6 Portability

3.6InverseRequirements
Stateany*useful*inverserequirements.

3.7DesignConstraints
Specifydesignconstrainsimposedbyotherstandards,companypolicies,hardware
limitation,etc.thatwillimpactthissoftwareproject.

3.8LogicalDatabaseRequirements
Willadatabasebeused?Ifso,whatlogicalrequirementsexistfordataformats,storage
capabilities,dataretention,dataintegrity,etc.

3.9OtherRequirements
Catchallsectionforanyadditionalrequirements.

4.AnalysisModels
Listallanalysismodelsusedindevelopingspecificrequirementspreviouslygiveninthis
SRS.Eachmodelshouldincludeanintroductionandanarrativedescription.Furthermore,
eachmodelshouldbetraceabletheSRSsrequirements.

SoftwareRequirementsSpecification Page8of
10

<ProjectName>

4.1SequenceDiagrams
4.3DataFlowDiagrams(DFD)
4.2StateTransitionDiagrams(STD)

5.ChangeManagementProcess
IdentifyanddescribetheprocessthatwillbeusedtoupdatetheSRS,asneeded,whenproject
scopeorrequirementschange.Whocansubmitchangesandbywhatmeans,andhowwillthese
changesbeapproved.

A.Appendices
Appendicesmaybeusedtoprovideadditional(andhopefullyhelpful)information.Ifpresent,
theSRSshouldexplicitlystatewhethertheinformationcontainedwithinanappendixistobe
consideredasapartoftheSRSsoverallsetofrequirements.
ExampleAppendicescouldinclude(initial)conceptualdocumentsforthesoftware
project,marketingmaterials,minutesofmeetingswiththecustomer(s),etc.

A.1Appendix1
A.2Appendix2

SoftwareRequirementsSpecification Page9of
10