Definition
Importance of SRS
Characteristics of SRS
Format of SRS- e.g
A Software Requirements Specification (SRS)is a requirements specification for a softwaresystem –i.e it is a complete description of thebehaviour of a system to be developed.
It includes a set of use cases that describe all theinteractions the users will have with the software.
In addition to use cases, the SRS also contains non-functional requirements. Non-functionalrequirements are requirements which imposeconstraints on the design or implementation (such asperformance engineering requirements, qualitystandards, or design constraints).
NOTE: Software requirements is a sub-field ofsoftware engineering that deals with the elicitation,analysis, specification, and validation of requirementsfor software.
The software requirement specification (SRS)document enlists all necessary requirementsfor project development.
To derive the requirements we need to haveclear and thorough understanding of theproducts to be developed.
This is prepared after detailed communicationswith project team and the customer.
Correct
An SRS is correct if, and only if, everyrequirement stated therein is one that thesoftware shall meet.
Unambiguous
An SRS is unambiguous if, and only if, everyrequirement stated therein has only oneinterpretation. As a minimum, this requiresthat each characteristic of the final productbe described using a single unique term.
Complete
An SRS is complete if, and only if, it includes the followingelements:
◦All significant requirements, whether relating to functionality,performance, design constraints, attributes, or external interfaces.In particular any external requirements imposed by a systemspecification should be acknowledged and treated.
◦Definition of the responses of the software to all realizable classesof input data in all realizable classes of situations. Note that it isimportant to specify the responses to both valid and invalid inputvalues.
◦Full labels and references to all figures, tables, and diagrams inthe SRS and definition of all terms and units of measure.
Consistent
Consistency refers to internal consistency. Ifan SRS does not agree with some higher-leveldocument, such as a system requirementsspecification, then it is not correct.
An SRS is internally consistent if, and only if,no subset of individual requirementsdescribed in it conflict.
Ranked for importance and/or stability
Typically, all of the requirements that relateto a software product are not equallyimportant.
Some requirements may be essential,especially for life-critical applications, whileothers may be desirable.
Each requirement in the SRS should beidentified to make these differences clear andexplicit.
Verifiable
An SRS is verifiable if, and only if, every requirementstated therein is verifiable.
A requirement is verifiable if, and only if, there existssome finite cost-effective process with which aperson or machine can check that the softwareproduct meets the requirement.
Nonverifiable requirements include statements suchas "works well", "good human interface", and "shallusually happen". These requirements cannot beverified because it is impossible to define the terms"good", "well", or "usually".
Modifiable
An SRS is modifiable if, and only if, its structure andstyle are such that any changes to the requirementscan be made easily, completely, and consistentlywhile retaining the structure and style.
Modifiability generally requires an SRS to Have acoherent and easy-to-use organization with a tableof contents, an index, and explicit cross referencing;
Not be redundant (i.e., the same requirement shouldnot appear in more than one place in the SRS);
Express each requirement separately, rather thanintermixed with other requirements.
Traceable
An SRS is traceable if the origin of each of itsrequirements is clear and if it facilitates thereferencing of each requirement in futuredevelopment or enhancement documentation.
The following two types of traceability arerecommended:
◦Backward traceability (i.e., to previous stages ofdevelopment).
◦Forward traceability (i.e., to all documents spawned bythe SRS).
A importance of developing a software requirementspecification is in streamlining the development process.
The developer working from the software requirementspecification has, ideally, all of their questions answeredabout the application and can start to develop.
Since this is a functional specification that was clientapproved, they are building nothing less than what thecustomer wants.
There should be nothing left to guess or interpret whenthe functional spec is completed. This is the brilliance ofthe software requirement specification.
Establish the basis for agreement between thecustomers and the suppliers on what thesoftware product is to do.
The complete description of the functions to beperformed by the software specified in the SRSwill assist the potential users to determine if thesoftware specified meets their needs or how thesoftware must be modified to meet their needs.
[NOTE: We use it as the basis of our contractwith our clients all the time].
Reduce the development effort.
The preparation of the SRS forces the variousconcerned groups in the customer’s organizationto consider rigorously all of the requirementsbefore design begins and reduces later redesign,recoding, and retesting.
Careful review of the requirements in the SRS canreveal omissions, misunderstandings, andinconsistencies early in the development cyclewhen these problems are easier to correct.
Provide a basis for estimating costs andschedules.
The description of the product to bedeveloped as given in the SRS is a realisticbasis for estimating project costs and can beused to obtain approval for bids or priceestimates.
[NOTE: Again, we use the SRS as the basis forour fixed price estimates]
Provide a baseline for validation and verification.
Organizations can develop their validation andVerification plans much more productively from agood SRS. As a part of the development contract, theSRS provides a baseline against which compliance canbe measured.
[NOTE: We use the SRS to create the Test Plan].
Facilitate transfer.
The SRS makes it easier to transfer the softwareproduct to new users or new machines. Customersthus find it easier to transfer the software to otherparts of their organization, and suppliers find iteasier to transfer it to new customers.
Serve as a basis for enhancement.
Because the SRS discusses the product but notthe project that developed it, the SRS serves as abasis for later enhancement of the finishedproduct.
The SRS may need to be altered, but it doesprovide a foundation for continued productionevaluation.
[NOTE: This is often a major pitfall – when theSRS is not continually updated with changes]
Again from the IEEE standard: The basic issues that the SRS writer(s) shalladdress are the following:
a) Functionality. What is the software supposed to do?
b) External interfaces. How does the software interact with people, thesystem’s hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recoverytime of various software functions, etc.?
d) Attributes. What are the portability, correctness, maintainability,security, etc. considerations?
e) Design constraints imposed on an implementation. Are there anyrequired standards in effect, implementation language, policies fordatabase integrity, resource limits, operating environment(s) etc.?
verification and validation (V&V) is theprocess of checking that a software systemmeets specifications and that it fulfills itsintended purpose.
Verification: The process of evaluatingsoftware to determine whether the productsof a given development phase satisfy theconditions imposed at the start of that phase.
Validation: The process of evaluatingsoftware during or at the end of thedevelopment process to determine whether itsatisfies specified requirements.