Download - SRS
S ft R i tSoftware RequirementsSpecification
S ft R i t S ifi ti A C t tSoftware Requirements Specification: A Contract Document
fRequirements document is a reference document. SRS document is a contract between the SRS document is a contract between the d l t t d th td l t t d th tdevelopment team and the customer. development team and the customer.
Once the SRS document is approved by the customer,customer,
any subsequent controversies are settled by referring the SRS document.y g
SW R i t S ifi tiSW Requirements SpecificationPurpose of SRS
communication between the Customer, Analyst, system developers, maintainers, ...contract between Purchaser and Suppliercontract between Purchaser and Supplier firm foundation for the design phasesupport system testing activitiesy gsupport project management and controlcontrolling the evolution of the system
SRS Document (CONT.)
The SRS doc ment is kno n as black boThe SRS document is known as black-box specification:
the system is considered as a black box whose internalthe system is considered as a black box whose internal details are not known.only its visible external (i.e. input/output) behavior is documented.
I t D t O t t D tSInput Data Output Data
SRS Document (CONT.)
SRS document concentrates on:what needs to be donecarefully avoids the solution (“how to do”) aspects.
The SRS document serves as a contract between development team and the customer.Should be carefully written
SRS Document (CONT.)
The requirements at this stage:written using end-user terminologywritten using end user terminology.
If necessary:f flater a formal requirement specification
may be developed from it.
Software Requirements Specification (SRS)(SRS)
Defines the customer’s requirements in terms of :FunctionFunctionPerformanceE l i fExternal interfacesDesign constraints
The SRS is the basis of contract between the purchaser and supplierpurchaser and supplier
Specification Principles
Separate functionality from implementationDevelop model of desired behavior of the systemDevelop model of desired behavior of the systemEstablish the context in which s/w operatesDefine the environment in which system operatesCreate a cognitive modelSpecifications must be tolerant of incompleteness & augmentableaugmentableContent & structure of a specifications should be amenable to changeg
What is not included in an SRS ?What is not included in an SRS ?Project requirements
cost, delivery schedules, staffing, reporting procedures
Design solutionsDesign solutionspartitioning of SW into modules, choosing data structures
Product assurance plansQuality Assurance procedures, Configuration M t d V ifi ti & V lid tiManagement procedures, Verification & Validation procedures
Benefits of SRSBenefits of SRSForces the users to consider their specific requirements carefullyEnhances communication between the
SPurchaser and System developersProvides a firm foundation for the system d i hdesign phaseEnables planning of validation, verification, and acceptance proceduresand acceptance proceduresEnables project planning eg. estimates of cost and time resource schedulingcost and time, resource schedulingUsable during maintenance phase
Types of RequirementsTypes of RequirementsFunctional requirementsNon functional requirements
Performance requirementsI t f i tInterface requirementsDesign constraintsOther requirementsOther requirements
Functional RequirementsFunctional RequirementsTransformations (inputs, processing, outputs)Requirements for sequencing and parallelism (dynamic requirements)D tData
Inputs and OutputsStored dataTransient data
Exception handlingN t f f ti M d t / D i bl / O ti l /Nature of function: Mandatory/ Desirable/ Optional / Volatile / Stable
Performance RequirementsqCapacity
no. of simultaneous users, processing requirementsno. of simultaneous users, processing requirements for normal and peak loads, static storage capacity, spare capacity
R tiResponse timeSystem priorities for users and functionsSystem efficiencyAvailabilityFault recovery
All these requirements should be stated inAll these requirements should be stated in measurable terms so that they can be verified.
VerifiableVerifiableA requirement is verifiable if and only if there exists some finite cost effective process with which a person or machine can check that the SW meets the requirementSW meets the requirement.
E t l I t f R i tExternal Interface RequirementsUser interfacesUser interfaces
eg. if display terminal used, specify required screen formats, menus, report layouts, function keys
Hardware interfacescharacteristics of the interface between the SW product and HW components of the systemproduct and HW components of the system
Software interfacesspecify the use of other SW products eg. OS,specify the use of other SW products eg. OS, DBMS, other SW packages
Design ConstraintsSW design constraints
standards for design, coding, naming, etc.g g gSW interfaces (to OS, DBMS, other SW)use a specific application packageconstraints on program size data size etcconstraints on program size, data size etc.
HW design constraintsspecific type of HW, reliability requirementsp yp y qHW interfacesrequirements for spare capacity or spare performanceperformance
Design Constraints (contd)Design Constraints (contd)User-interface design constraints
features of operator/user with details of working environmentany special features requiredany special features required
Other RequirementsOther RequirementsSecuritySafetyEnvironmentalReusabilityTraining...
SRS StandardsSRS StandardsANSI/IEEE SRS Standard 830-1984BS 6719: 1986European Space Agency Standards(ESA PSS-05-0, Jan 1987)US DoD-Std-7935A...
SRS Prototype Outlineyp
[ IEEE SRS Standard ][ ]
1. Introduction1.1 Purpose1.2 Scopep1.3 Definitions, Acronyms and Abbreviations1.4 References1.5 Overview
SRS - Introduction SectionPurpose
delineate the purpose of the particular SRSspecify the intended audience for the SRSspecify the intended audience for the SRS
Scopeidentify the SW products to be produced by namey p p yexplain what the SW product will do, and if necessary, what it will not dodescribe the application of the SW being specified iedescribe the application of the SW being specified. ie. benefits, objectives, goals as precisely as possible
Overviewdescribe what the rest of the SRS containshow the SRS is organized
SRS P t t O tliSRS Prototype Outline[ IEEE SRS Standard ][ IEEE SRS Standard ]
2 General description2. General description2.1 Product perspective2 2 Product function summary2.2 Product function summary2.3 User characteristics2 4 General constraints2.4 General constraints2.5 Assumptions and dependencies
Product PerspectiveProduct PerspectiveState whether the product is independent and totally self containedtotally self containedIf the product is component of a larger system then:then:
describe the functions of each component of the larger system and identify interfacesoverview of the principal external interfaces of this productoverview of HW and peripheral equipment to be usedoverview of HW and peripheral equipment to be used
Give a block diagram showing the major components of the product, interconnections, andcomponents of the product, interconnections, and external interfaces.
Product FunctionsProduct FunctionsProvide a summary of functions the SW will
fperformThe functions should be organized in such a way that they are understandable by the userway that they are understandable by the user
CUser CharacteristicsD ib th l h t i ti f thDescribe the general characteristics of the eventual users of the product. (such as educational level experience and technicaleducational level, experience and technical expertise )
General ConstraintsGeneral ConstraintsRegulatory policiesHW limitationsInterfaces to other applicationsParallel operationAudit functionsControl functionsCriticality of the applicationy ppSafety and security considerations
SRS Prototype Outline[ IEEE SRS Standard ]
3. Specific Requirements - Functional requirements
E l i f i- External interface requirements- Performance requirements
Design constraints- Design constraints- Attributes eg. security, availability,
maintainability, transferability/conversionmaintainability, transferability/conversion- Other requirements
AppendicesppIndex
Functional RequirementsFunctional Requirements
IntroductionIntroductiondescribe purpose of the function and the approaches and techniques employed
Inputs and Outputssources of inputs and destination of outputsquantities units of measure ranges of valid inputsquantities, units of measure, ranges of valid inputs and outputstimingg
Functional RequirementsFunctional RequirementsProcessing
validation of input dataexact sequence of operationsresponses to abnormal situationsresponses to abnormal situationsany methods (eg. equations, algorithms) to be used to transform inputs to outputs
External Interface RequirementsExternal Interface RequirementsUser interfacesH d i t fHardware interfacesSoftware interfacesC fCommunications interfacesOther requirements
d t b f f i bilitidatabase: frequency of use, accessing capabilities, static and dynamic organization, retention requirements for dataoperations: periods of interactive and unattended operations, backup, recovery operationsit d t ti i tsite adaptation requirements
AppendicesAppendicesNot always necessaryIt may include:
sample I/O formatsDFD ERD d tDFD, ERD documentsresults of user surveys, cost analysis studiessupporting documents to help readers of SRSsupporting documents to help readers of SRS
Ch t i ti f G d SRSCharacteristics of a Good SRSUnambiguousgCompleteVerifiableConsistent ModifiableTraceableUsable during the Operation and Maintenance phase
Examples of Requirements statementsAmbiguousThe data set will contain an end of Ambiguous
Non-verifiable
The data set will contain an end of file character.The product should have a good
Non-verifiable human interface.The program shall never enter an infinite loop
Non-verifiableinfinite loop.The output of the program shall usually be given within 10 secs.
Verifiable The output of a program shall be given within 20secs of event X 60% of the timeof the time.
Examples of Bad SRS D tDocuments
U t t d S ifi tiUnstructured Specifications: Narrative essay --- one of the worst types of specification doc mentspecification document:
Difficult to change, difficult to be precisedifficult to be precise, difficult to be unambiguous,
f t di ti tscope for contradictions, etc.
Examples of Bad SRS D tDocuments
Noise: Presence of text containing information irrelevant to the problemthe problem.
Silence:aspects important to proper solution of the problemaspects important to proper solution of the problem are omitted.
Examples of Bad SRS D tDocuments
Overspecification:Overspecification:Addressing “how to” aspectsFor example, “Library member names should be stored in a sorted descending order”Overspecification restricts the solution space for the designer.designer.
Contradictions:Contradictions might arise
if the same thing described at several places in different ways.
Examples of Bad SRS Documents
Ambiguity:Ambiguity:Literary expressionsUnquantifiable aspects, e.g. “good user interface”
Forward References:References to aspects of problem
defined only later on in the textdefined only later on in the text.Wishful Thinking:
Descriptions of aspects p pfor which realistic solutions will be hard to find.
CompleteComplete
All significant requirements are includedDefinition of responses of the SW to allDefinition of responses of the SW to all realizable classes of input data in all situations.Conformity to a standardConformity to a standardFull labeling and referencing of all figures, tables etc. and definition of all terms and units of measure
VerifiableVerifiableA requirement is verifiable if and only if there exists some finite cost effective process with which a person or machine can check that the SW meets the requirementSW meets the requirement.
ConsistentConsistentNo two requirements are in conflict
ModifiableModifiableStructure and style of SRS is such that changes to requirements can be made easily, completely and consistently.
SRS i ti t bl f t t i dSRS organisation -- table of contents, index, explicit cross-referencingno redundancyy
TraceableTraceableAn SRS is traceable if the origin of each requirement is clear and it facilitates the referencing of each requirement in future.Backward traceabilityBackward traceability
requirement explicitly referencing its source in previous documentsp
Foward traceabilityeach requirement has a unique name or reference number and it can be traced to design documents, program implementation.
SRS ReviewSRS ReviewFormal Review done by Users, Developers, yManagers, Operations personnel
To verify that SRS confirms to the actual user requirements
To detect defects early and correct them.
Review typically done using checklists.
Sample SRS ChecklistSample SRS ChecklistAre all HW resources defined ?Have response times been specfied for functions ?Have all the HW, external SW and data interfaces been defined ?interfaces been defined ?Is each requirement testable ?Is the initial state of the system defined ?Is the initial state of the system defined ?Are the responses to exceptional conditions specified ?specified ?Are possible future modifications specified ?