The document discusses the Software Requirements Specification (SRS) which is a communication tool between stakeholders and software designers. The SRS aims to describe the scope of work, provide a reference for software designers, provide a framework for testing, include customer requirements, and allow for ongoing refinement. An example organization of an SRS is provided which includes sections on introduction, system overview, user interfaces, requirements, and more. Characteristics of a good SRS are also listed, such as being correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, and traceable.

1. The Software Requirements Specification
The Software RequirementsSpecification(SRS) isacommunicationtool betweenstakeholdersand
software designers.The specificgoalsof the SRSare:
An example organization of an SRS is as follows:
Introduction
Purpose
Definitions
Systemoverview
References
Overall description
Productperspective
SystemInterfaces
User Interfaces
Hardware interfaces
Software interfaces
CommunicationInterfaces
MemoryConstraints
Designconstraints
Operations
Site AdaptationRequirements
Productfunctions
User characteristics
Constraints,assumptionsanddependencies
Specificrequirements
External interface requirements
Functional requirements

2. The Software Requirements Specification
Performance requirements
Logical database requirement
Software Systemattributes
Reliability
Availability
Security
Maintainability
Portability
Facilitatingreviews
Describingthe scope of work
Providingareference tosoftware designers(i.e.navigationaids,documentstructure)
Providingaframeworkfortesting primaryandsecondaryuse cases
Includingfeaturestocustomerrequirements
Providingaplatformforongoingrefinement(viaincomplete specsorquestions)
ReliabilityAvailabilitySecurityMaintainabilityPortability.
Concept of operations
Requirements engineering
Software Engineering Bodyof Knowledge (SWEBOK)
Design specification
Specification (technical standard)
Formal specification
Concept of Operation:
ConOpsisa documentdescribingthe characteristicsof aproposedsystemfromthe viewpointof an
individualwhowilluse thatsystem.Itisusedto communicate the quantitative andqualitative system
characteristicstoall stakeholders.CONOPSare widelyusedinthe military,governmental servicesand
otherfields.
A CONOPSgenerallyevolvesfroma conceptand isa descriptionof how asetof capabilitiesmaybe
employedtoachieve desiredobjectivesorendstate.

3. The Software Requirements Specification
In the fieldof jointmilitaryoperations,aCONOPSinDoDterminologyisaverbal orgraphic statement
that clearlyandconciselyexpresseswhatthe jointforce commanderintendstoaccomplishandhowit
will be done usingavailable resources.CONOPSmayalsobe usedorsummarizedinsystemacquisition
DODAFdescriptionssuchasthe OV-1 HighLevel OperationalConceptGraphic.
Requirements Engineering:
Requirementsengineering(RE) referstothe processof defining,documentingandmaintaining
requirementstothe sub-fieldsof systemsengineeringandsoftware engineeringconcernedwiththis
process.
In the waterfall model,requirementsengineeringispresentedasthe firstphase of the development
process.Latersoftware developmentmethods,includingthe Rational UnifiedProcess(RUP),extreme
programming(XP) andScrumassume that requirementsengineeringcontinuesthroughthe lifetimeof a
system.
Requirementmanagementwhichisasub-functionof SystemsEngineeringpracticesare alsoindexedin
the INCOSE(International Council onSystemsEngineering) manuals.
Software EngineeringBodyof Knowledge(SWEBOK):
The Software EngineeringBodyof Knowledge (SWEBOK)isaninternationalstandardISO/IECTR
19759:2005[1] specifyingaguide tothe generallyacceptedSoftware EngineeringBodyof Knowledge.
The Guide to the Software EngineeringBodyof Knowledge (SWEBOKGuide) hasbeencreatedthrough
cooperationamongseveral professionalbodiesandmembersof industryandispublishedbythe IEEE
ComputerSociety(IEEE).The standardcan be accessedfreelyfromthe IEEEComputerSociety.Inlate
2013, SWEBOKV3 was approvedforpublicationandreleased.
Designspecification:
A designspecificationisadetaileddocumentprovidinginformationaboutthe characteristicsof a
projectto setcriteriathe developerswill needtomeet.Itsuse iscalledforwhere astructure or product
has to be specially made tomeetaunique need.Forexample,adesignspecificationmustinclude all
necessarydrawings,dimensions,environmental factors,ergonomicfactors,aestheticfactors,andcost,
maintenance thatwill be needed,quality,safety,documentationanddescription.Italsotellsspecific
examplesof howthe designof the projectshouldbe executed,helpingothersworkproperly.

4. The Software Requirements Specification
Specification (Technical Standard):
A designspecificationisadetaileddocumentprovidinginformationaboutthe characteristics of a
projectto setcriteriathe developerswill needtomeet.Itsuse iscalledforwhere astructure or product
has to be speciallymade tomeetaunique need.Forexample,adesignspecificationmustinclude all
necessarydrawings,dimensions,environmental factors,ergonomicfactors,aestheticfactors,andcost,
maintenance thatwill be needed,quality,safety,documentationanddescription.Italsotellsspecific
examplesof howthe designof the projectshouldbe executed,helpingothersworkproperly.
Formal Specification:
In computerscience,formal specificationsare mathematicallybasedtechniqueswhose purpose are to
helpwiththe implementationof systemsandsoftware.Theyare usedtodescribe asystem, toanalyze
itsbehavior,andto aidinits designbyverifyingkeypropertiesof interestthroughrigorousandeffective
reasoningtools.These specificationsare formal inthe sense thattheyhave a syntax,theirsemanticsfall
withinone domain,andtheyare able tobe usedtoinferuseful information.

5. The Software Requirements Specification
Characteristics of a Good Software Requirements Specification (SRS)
Recently,Ineedtohave a lookat the IEEE SRS Standard.I think,all of youknow verywell aboutit.
However,here,Iwantto reemphasize some basicpointsabout goodSRScharacteristicsbriefly.
An SRS should be:
Correct
An SRS is correct if, and only if, every requirementstated therein is one thatthe software shall meet.Traceability
makes this procedure easier and less prone to error.
Unambiguous
An SRS is unambiguous if,and only if, every requirementstated therein has onlyone interpretation.As a minimum,
this requires thateach characteristic of the final product be described using a single unique term.
Complete
An SRS is complete if, and only if, it includes the following elements:

6. The Software Requirements Specification
 All significantrequirements,whether relating to functionality, performance,design constraints,attributes,or
external interfaces.In particular any external requirements imposed bya system specification should be
acknowledged and treated.
 Definition of the responses ofthe software to all realizable classes ofinputdata in all realizable classes of
situations.Note thatit is importantto specifythe responses to both valid and invalid inputvalues.
 Full labels and references to all figures,tables,and diagrams in the SRS and definition of all terms and units of
measure.
Consistent
Consistencyrefers to internal consistency.If an SRS does notagree with some higher-level document,such as a
system requirements specification,then it is not correct. An SRS is internallyconsistentif,and only if, no subsetof
individual requirements described in itconflict.
Ranked for importance and/or stability
An SRS is ranked for importance and/or stabilityif each requirementin it has an identifier to indicate either the
importance or stabilityof that particular requirement.Typically, all of the requirements thatrelate to a software
productare not equallyimportant.Some requirements maybe essential,especiallyfor life-critical applications,while
others may be desirable.Each requirementin the SRS should be identified to make these differences clear and
explicit.
Verifiable
An SRS is verifiable if, and only if, every requirementstated therein is verifiable.A requirement is verifiable if, and
only if, there exists some finite cost-effective process with which a person or machine can check that the software
productmeets the requirement.
Non verifiable requirements include statements such as "works well","good human interface",and "shall usually
happen".These requirements cannotbe verified because itis impossible to define the terms "good","well", or
"usually".
Modifiable
An SRS is modifiable if,and only if, its structure and style are such that any changes to the requirements can be
made easily,completely,and consistentlywhile retaining the structure and style. Modifiability generallyrequires an
SRS to
 Have a coherentand easy-to-use organization with a table of contents,an index, and explicit cross referencing;
 Not be redundant(i.e., the same requirementshould notappear in more than one place in the SRS);
 Express each requirementseparately,rather than intermixed with other requirements.
Traceable
An SRS is traceable if the origin of each of its requirements is clear and ifit facilitates the referencing of each
requirementin future developmentor enhancementdocumentation.The following two types of traceability are
recommended:
 Backward traceability (i.e.,to previous stages of development). This depends upon each requirementexplicitly
referencing its source in earlier documents.

7. The Software Requirements Specification
 Forward traceability (i.e., to all documents spawned by the SRS). This depends upon each requirementin the
SRS having a unique name or reference number.

8. The Software Requirements Specification

9. The Software Requirements Specification