Software Requirement Specification (SRS)
The result of the requirements phase of a software development process is the software requirement specification document. This is also addressed as a requirements document. This document establishes a base for software engineering activities (operations) and is created when overall requirements are generated and examined.
Software requirements specification (SRS) is an official document, which serves as representation of software that allows the users to consider whether it (SRS) is as per their requirements or not. As well as the requirements document includes user requirements for a system along with in depth specification of the system requirement.
SRS defines it as "a document that accurately and clearly explains each of the important requirements of the software and the external interfaces. Each requirement is defined in a manner that its success can be objectively confirmed by a specified method , for instance, inspection , demonstration, analysis, or test."
Basically what happens from requirements analysis activity to the specification activity is the knowledge obtained about the system. The modeling is mainly a tool to help obtain using and full knowledge about the proposed system. The SRS is written based on the knowledge gathered during analysis.
Whereas transforming knowledge into a structured document is not a simple specification itself is a major task, which is partially independent. The requirement document is used by various individuals in the organization. System customers want SRS to define and verify even if requirements meet the desired needs or not.
Furthermore, SRS allows the manager to plan for the system development processes. System engineers need a requirements document to know what system is to be developed. They also need this document to develop validation tests for the required system. Requirements document is desired by system maintenance engineers to use the requirement and the relationship between its parts.
In addition, the requirement document has to identify the demands in precise data for developers and testers. It should also contain information about possible modifications in the system, which can assist system designers to avoid restricted conclusions on design. SRS also assists maintenance engineers to modify the system to new requirements.
Characteristics of a Software Requirement Specification
 |
| Characteristics of SRS |
Correct - if every single requirement added in the software requirement specification denotes something required in the final system then a SRS is correct.
Complete - it is a very important feature of an SRS which means if totally the software has to deal and the response of the software to all classes of input data are given in software requirement specification then the SRS is complete. It guarantees that everything is indeed given . And if we can compare the correctness feature to the completeness feature, completeness is the most difficult feature to establish.
Unambiguous - if every requirement declared has one and only one interpretation, then the SRS is unambiguous. The requirements which are naturally ambiguous are commonly written in natural language. Using formal languages is the massive effort required to write an SRS in the main drawback, and also the high cost of doing so, and increasing difficulty in reading and understanding formally given statements.
Verifiable - The software requirement specification is verifiable if each given requirement is to be verifiable. If there are some cost effective processes or methods which can check whether the final software meets the requirements then a requirement is verifiable. To verify the software the most important feature is required and that is Unambiguity.
Consistent - if there is no requirement that challenges with the other then an SRS is consistent. To mention the same object, different requirements may use different terms. It could be a logical or temporal challenge between requirements causing Inconsistencies. It happens when the SRS holds two or more requirements whose logical or temporal characteristics cannot be satisfied together by any software system.
Ranked for importance and Stability - if for each requirement the importance and the stability of the requirement are mentioned. The changes in the future are considered by the stability of a requirement.
Modifiable - if the type and the framework of SRS are in such a manner that , and change can be made easily while maintaining completeness and consistency then the software requirement specification is modifiable. The succeeding SRS will be inconsistent if only one incident of the requirement is modified.
Traceable - if the source of each of its requirements is clear or accurate and if it facilitates the mentioning of each requirement in future development then an SRS is traceable. And it is furthermore divided into two types, forward traceability and backward traceability .
The forward traceability is that in which each requirement is supposed to be traceable to some design and code elements, whereas the backward traceability requires that it is possible to trace design and code elements to the requirements they support. The traceability supports the verification and validation.
Software Requirement Specification (SRS) as Black Box Specification
Software requirement specification is called as black box specification because it answers only about what the proposed system is supposed to do without increasing on how to obtain it. It is the result of the analysis activity and shows up very early in the development process. Basically, what moves from requirement analysis activity to the specification activity is the knowledge gathered about the system. The modeling is almost a tool to assist in achieving through and complete knowledge about the proposed system. The SRS is written on the basis of the knowledge gathered during analysis.
Need of Software Requirement Specification (SRS)
Software systems mostly focus on the demand of the client, who moreover wants to automate an existing manual system or needs a new software system. The software system is separately developed by the developer.
At last , the completed system will be operated or used by the end users. Therefore, in a new system there are basically three major parties who are interested: the client, the developer, the end users.
Somehow the requirements for the system that will Fulfill the needs of the client and the concerns of the user have to be mentioned to the developer. However the problem is that the client generally does not understand software or the software development process and the developer many times does not understand the client's problem and application area. This causes a major communication gap between the interested parties in the development.
To overpass the communication gap is a primary purpose of software requirements specification. Another important purpose of developing an SRS is assisting the client to understand their own requirements.