Software Requirement Specification (SRS) Document Checklist
The SRS document is reviewed by the testing person or a group of persons by using any verification method (like peer reviews, walkthroughs, inspections, etc). We may use inspections due to their effectiveness and capability to produce good results. We may conduct reviews twice or even more often. Every review will improve the quality of the document but may consume resources and increase the cost of the software development. A checklist is a popular verification tool that consists of a list of critical information content that a deliverable should contain. A checklist may also look for duplicate information, missing information, unclear information, wrong information, etc. Checklists are used during reviewing and may make reviews more structured and effective.
An SRS document checklist should address the following issues :
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
- Correctness :
In the SRS document, every requirement stated in the document should correctly represent an expectation from the proposed software. All applicable safety and security requirements must be identified. Also, all the inputs and outputs of each requirement are required and sufficient for the specified processing. For example, If there’s a client requirement for the software to respond to all buttons pressed within 2 seconds, but the SRS states that ‘the software shall respond to all buttons presses within 20 seconds’, then that will be referred to as incorrectness in the documentation.
- Ambiguity :
The SRS document may contain some ambiguity in the software requirements. For example, If a requirement conveys more than one meaning of a thing, then it will be a serious problem so, to avoid this ambiguity, every requirement must have a single meaning only. Hence, the software requirement statement should be short, correct, precise, and clear. The SRS document checklist must focus on ambiguous words to avoid ambiguity.
- Completeness :
The SRS document should be complete in all aspects like it must have all the important functional requirements (like hardware faults, I/O errors, computational errors, processing overload, buffer overflow, events failing to occur, etc) and non-functional requirements needed for the software and this completeness of the SRS document must be checked thoroughly through a checklist.
- Consistency :
In the SRS document, the consistency of the document can be maintained if all the stated requirements do not vary from the other stated requirements. Every object is referred to with a unique name and is defined by one set of characteristics that are not in conflict with one another. Also, if the Mathematical equations, acronyms, and abbreviations are defined and used consistently, then the document will be consistent. The checklist must highlight the issues related to inconsistency and should be designed to find inconsistencies.
- Verifiability :
In the SRS document, it is said to be verifiable, if and only if, every requirement stated in the document is verifiable. The non-verifiable requirements include statements like ‘good interfaces’, ‘excellent response time’, ‘usually’, ‘well’, etc, which should not be used. The requirements terminology like “shall”, “will”, “may”, etc. should be used. In the document, we should only use measurable terms and must avoid all the indefinite terms.
- Traceability :
The SRS document can be traceable if the source of each and every requirement is defined correctly as it may help in future development. Traceability may help to structure the document and should find a place in the design of the checklist.
- Feasibility :
In the SRS document, some of the requirements may not be feasible to implement due to technical reasons or lack of resources so, those such requirements should be identified and accordingly removed from the SRS document. A document checklist can also help us to find some other non-feasible requirements in the software. Like for example, the data expected from external sources must exist at the defined sources, or the data sent to external destinations is expected at those destinations otherwise, the requirements may not be feasible to implement.