Professional Documents
Culture Documents
Software Requirement Specification Format
Software Requirement Specification Format
<ProjectName>
<YourName>
<RollNo.>
Submittedto:Ms.HarnitSaini
MCADepartment
TableofContents
Introduction
TheintroductiontotheSoftwareRequirementSpecification(SRS)documentshouldprovidean
overviewofthecompleteSRSdocument.Whilewritingthisdocumentpleaserememberthatthis
documentshouldcontainalloftheinformationneededbyasoftwareengineertoadequately
design and implement the software product described by the requirements listed in this
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:
(a) Describe all relevant benefits, objectives, and goals as precisely as possible. For
example,tosaythatonegoalistoprovideeffectivereportingcapabilitiesisnotasgood
assayingparameterdriven,userdefinablereportswitha2hturnaroundandonline
entryofuserparameters.
(b) Be consistent with similar statements in higherlevel specifications (for example, the
System Requirement Specification) , if they exist.What is the scope of this software
product.
1.3Definitions,Acronyms,andAbbreviations
This subsection should provide the definitions of all terms, acronyms, and abbreviations
requiredtoproperlyinterprettheSRS.Thisinformationmaybeprovidedbyreferencetooneor
moreappendixesintheSRSorbyreferencetootherdocuments.
1.4References
Thissubsectionshould:
(1) ProvideacompletelistofalldocumentsreferencedelsewhereintheSRS,orinaseparate,
specifieddocument.
(2) Identify each document by title, report number if applicable date, and publishing
organization.
(3) Specifythesourcesfromwhichthereferencescanbeobtained.
Thisinformationmaybeprovidedbyreferencetoanappendixortoanotherdocument.
1.5Overview
Thissubsectionshould:
(1)DescribewhattherestoftheSRScontains
(2)ExplainhowtheSRSisorganized.
2.GeneralDescription
This section of the SRS should describe the general factors that affect 'the product andits
requirements.Itshouldbemadeclearthatthissectiondoesnotstatespecificrequirements;it
onlymakesthoserequirementseasiertounderstand.
2.1ProductPerspective
ThissubsectionoftheSRSputstheproductintoperspectivewithotherrelatedproductsor
projects.(SeetheIEEEGuidetoSRSformoredetails).
2.2ProductFunctions
ThissubsectionoftheSRSshouldprovideasummaryofthefunctionsthatthesoftwarewill
perform.
2.3UserCharacteristics
ThissubsectionoftheSRSshoulddescribethosegeneralcharacteristicsoftheeventualusersof
theproductthatwillaffectthespecificrequirements. (SeetheIEEEGuidetoSRSformore
details).
2.4GeneralConstraints
ThissubsectionoftheSRSshouldprovideageneraldescriptionofanyotheritemsthatwill
limitthedevelopersoptionsfordesigningthesystem.(SeetheIEEEGuidetoSRSforapartial
listofpossiblegeneralconstraints).
2.5AssumptionsandDependencies
ThissubsectionoftheSRSshouldlisteachofthefactorsthataffecttherequirementsstatedin
theSRS.Thesefactorsarenotdesignconstraintsonthesoftwarebutare,rather,anychangesto
themthatcanaffecttherequirementsintheSRS.Forexample,anassumptionmightbethata
specificoperatingsystemwillbeavailableonthehardwaredesignatedforthesoftwareproduct.
If,infact,theoperatingsystemisnotavailable,theSRSwouldthenhavetochangeaccordingly.
3.SpecificRequirements
ThiswillbethelargestandmostimportantsectionoftheSRS.Thecustomerrequirementswill
beembodiedwithinSection2,butthissectionwillgivetheDrequirementsthatareusedto
guidetheprojectssoftwaredesign,implementation,andtesting.
Eachrequirementinthissectionshouldbe:
Correct
Traceable(bothforwardandbackwardtoprior/futureartifacts)
Unambiguous
Verifiable(i.e.,testable)
Prioritized(withrespecttoimportanceand/orstability)
Complete
Consistent
Uniquelyidentifiable(usuallyvianumberinglike3.4.5.6)
Attentionshouldbepaidtothecarefulyorganizetherequirementspresentedinthissectionso
thattheymayeasilyaccessedandunderstood.Furthermore,thisSRSisnotthesoftwaredesign
document,thereforeoneshouldavoidthetendencytooverconstrain(andthereforedesign)the
softwareprojectwithinthisSRS.
3.1DesignConstraints
Specifydesignconstrainsimposedbyotherstandards,companypolicies,hardwarelimitation,
etc.thatwillimpactthissoftwareproject.
3.2LogicalDatabaseRequirements
Will a database be used? If so, what logical requirements exist for data formats, storage
capabilities,dataretention,dataintegrity,etc.