Software Requirement Specification
A software is developed with respect to the requirements given by the customers. Any deviations in the requirements are considered as defects in the software. So while a software is being implemented, utmost care should be taken by the developers so that it is developed as per the requirements and specifications.
What is Software Requirement Specification?
The software requirement specification describes the specifications of the software that executes specific functions in a target environment. It comprises multiple objectives to be served by the software. It can be either written by the customers or by the developers.
The customers who contribute on the software requirement specification mostly focuses on the requirements, and expectations from the end users. The developers who write the software requirement specification serve multiple purposes which includes defining the contract between the clients, and the developers.
Characteristics of Software Requirement Specification
The characteristics of software requirement specification are listed below −
1. Correctness
The customer review is conducted to describe the appropriate requirements in the software requirement specification. It is considered as ideal if it encompasses every requirement that the software should have.
2. Completeness
The software requirement specification is considered as complete under the below conditions −
- All the mandatory requirements covering all the functionalities, design, architecture, performance parameters, dependencies, constraints, attributes, interfaces etc should be included.
- It should also contain the software responses to both valid, and invalid input data sets.
- It should contain the labels, and descriptions of the various figures, diagrams, units, and terminologies.
3. Consistency
The software requirement specification is considered as consistent, if no sub-parts of any requirements are contradictory to each other. The different types of conflicts that appear in the software requirement specification document are listed below −
- A particular behavior of the real life entities may contradict. For example, the format of an output report may be defined in one requirement as pdf but in another requirement it may be defined in the document format. One condition may describe that all outputs should be of integer type while another requirement describes all the outputs should be of the type long.
- There can be sensible or temporary conflicts between two particular activities. For example, One requirement may define that the software should process the payment on a daily basis but the other requirement may describe that the software should process the payment on hourly basis. One condition may narrate that the payment will be processed after successful placing of orders but another may describe both of the activities should co-exist.
- Multiple requirements may describe the similar real life entities using different terminologies. For example, an user input can be termed as alert in one requirement, and dialogue box in another requirement.
4. Unambiguous
The software requirement specification is considered as unambiguous if every requirement has consistent interpretation, and distinct description. All the requirements should be clear, and easily explained.
5. Ranking for Stability and Importance
Each requirement in the software requirement specification should be ranked with respect to its stability, and importance. All the requirements may not be similar, for some the pre-conditions are mandatory while for others it may not be so. All these factors should be clearly explicitly described. Other factors include the required, nice to have, and optional categories of requirements.
6. Modifiability
All the requirements in the software requirement specification should be modifiable, and every change should be cross-referenced and indexed.
7. Verifiability
All the requirements in the software requirement specification should be verified with extensive, and periodic reviews.
8. Traceability
All the requirements in the software requirement specification should be traceable to the source of each requirement. They should also reference all the developments or enhancements which shall happen in future.
9. Design Independence
There should be an option to choose one design from various design alternatives for the software. The software requirement specification should not contain any implementation details of the software.
10. Testability
The software requirement specification should be described in simple words such that test plans, and test cases can be easily generated from it.
11. Easily Understandable
The software requirement specification language should be clear and easily understandable. It should not contain any formal notations, and symbols.
12. Abstraction
If the software requirement specification is described at the requirement analysis stage, it should be done explicitly.
Types of Traceability
The different types of traceability are listed below −
Backward Traceability
It depends on the individual requirements explicitly pointing to their origins.
Forward Traceability
It depends on the individual elements in the software requirement specification having a distinct number or name. It is mainly important for the maintenance and operation stages. As there are changes made in the code, and design, it should be ensured that these changes are aligned as per the new requirements.
Properties of Software Requirement Specification
The properties of the software requirement specification are listed below −
- The software requirement specification document should be concise, clear, uniform, and complete. Unnecessary, and redundant descriptions decrease its readability, and make it more error prone.
- The software requirement specification document should follow a systematic approach. It undergoes various modifications in order to accommodate all the customer requirements. Also, it becomes easy to incorporate changes in the software requirement specification due to its structured format.
- The software requirement specification document should extensively cover the black box requirements of the software. It means that it should describe the outputs generated from the software from various sets of inputs. It defines the external characteristics of the software, and does not touch upon its internal implementation details.
- The software requirement specification document should contain the responses to unwanted events in the software. Thus it should summarize the responses to extreme circumstances.
- The software requirement specification document should contain all the correct requirements.
Conclusion
This concludes our comprehensive take on the tutorial on Software Requirement Specification. Weve started with describing what is software requirement specification, what are the characteristics of the software requirement specification, what are the different types of traceability, and what are the properties of the software requirement specification. This equips you with in-depth knowledge of Software Requirement Specification. It is wise to keep practicing what youve learned and exploring others relevant to Software Testing to deepen your understanding and expand your horizons.