Abbreviated as SRS, software requirement specification is a documented artifact, which provides the structure and the complete description of a software product, to be developed. Generally, it specifies the functional and non-functional requirements of a software product along with the user requirements. SRS decides how the product will look like, what should be its functions, how it will be functioning, and many such things.
It works as a foundation stone, to design and develop a software product in a particular manner for a particular purpose and environment. This artifact helps developers and testers to adhere to the specified requirements throughout their phase in order to achieve a quality product.
It is pertinent to mention that although, business analyst and project manager are involved in preparing SRS, it is preferable to assign the task of writing an SRS document to a technical writer, who is well versed with the technical language and may apply his skills and experience in building the SRS document in a simple manner, which may be easily understood by a large group of people or professionals engaged in the development.
Its need
The need for a software requirement specification in the development of a software product may be seen through following points:
Minimizes the efforts and maximizes the productivity of a development as well as of testing phase.
It saves a good amount of time, which may be required in communicating a client throughout the development process.
Avoids the situation of task redundancy or repetition in the development process.
It serves the purpose of verifying and validating the software product against the specifications and requirements during the testing phase at a later stage.
It helps in identifying the missing or wrong requirement or the functionality.
It may prove to be useful in estimating the quantity of time and cost, required to develop a software product.
What is covered under SRS document?
Below given is a basic structure of an SRS document, which may vary depending upon the need and approach of an organization.
Purpose
Identifying and specifying the purpose of an SRS keeping in view the targeted audience and the environment.
Scope
It consists of feasibility study of a software product to perform desirably in an intended environment. Further, it may involve the benefits, objectives and goals of a software product, to be developed. It may provide a solution to the questions like, what will be performed or will not be performed by a software product, etc.
Overview
It provides a small brief description of the complete SRS including its organized structure.
Definitions
This section consists of all the useful terminologies, used in the SRS, along with its definition and meaning so as to easily understand the SRS without any issue. Further, it also consists of abbreviations used throughout the SRS.
Use Case
It contains all the scenarios, where a user may execute a software product in a multiple way to perform or achieve a specific task.
Product description
It simply provides a precise description of a software product to be developed, which may include its working, applications, use, etc.
Product functions and characteristics
Functions and features of the desired software product, is specified in this section.
Assumptions, limitations and dependencies
This section reflects all the assumptions made, any sort of limitation and dependencies involved in the SRS.
Functional requirements
These are the primary requirements, on the basis of which software product will be developed to impart the desired working.
Non-functional requirements
These are the secondary but essential requirements pertaining to performance aspect of a software product such as reliability, stability, security, maintainability, portability and many similar attributes.
Any other specific requirement(s)
This include any other requirements as desired by the client or stakeholder for some special purpose.
Qualities of SRS
We are mentioning here, some of the desirable qualities of a SRS, which may work in the direction of quality achievement in the software product.
It should be correct and not wrongly be written so as to meet the specified needs and the requirements of a client.
It should be clearly defined and should not be unambiguous, so as to avoid the situation of misinterpreted or misunderstood specifications, which may lead to production of undesirable software product.
It should be complete so as to equip a developer with everything he/she may need in the development of a software product.
It should reflect the requirements, which are prevailing in the market.
It should be consistent in nature.
Consider only those requirements, which may be verified at a later stage.
May be modified during the course of development.
It should be traceable, which may help in mapping the requirements to other high level of documents at a later stage.
.png)
.png)
.png)
.png)
