Techniques of Writing Software Requirement Specfication
Posted By Ankita Sachan | 31-Oct-2018
A software requirements specification (SRS) is an elaborated description of a software to be developed with its functional and non-functional requirements. It should embody the use cases that how a user will interact with the software. The software requirement specification document consists of all the necessary requirements needed for project development.
A good SRS defines that how software can act with all internal modules, hardware, communication with different programs and user interactions with a wide range of real-life eventualities. it is important that QAs should be cleared with each detail laid out in this document in order to avoid faults in test cases and its expected results.
Qualities of a good SRS
- Correctness: User review is used to make sure the correctness of requirements expressed within the SRS. SRS is alleged to be correct if it covers all the requirements that are literally expected from the system.
- Completeness: Completeness of SRS indicates each sense of completion as well as the listing of all the pages, resolving the to be determined elements to the maximum potential and covering all the functional and non-functional requirements properly.
- Consistency: One can say requirements in SRS as consistent if there are no conflicts between any set of requirements. Examples of conflict include variations in terminologies used at different places, logical conflicts like period of time for report generation, etc.
- Unambiguousness: An SRS is said to be unambiguous if all the requirements expressed have just one interpretation. Some of the ways to stop unambiguousness include the utilization of modeling techniques like ER diagrams, correct reviews and buddy checks, etc.
- Ranking for importance and stability: There should a criterion to classify the requirements as less or more specifically as desirable or essential. A symbol mark is used with each demand to point its rank or stability.
- Modifiability: SRS should be created as modifiable as possible and should be capable of simply accepting changes to the system to some extent. Modifications should be properly indexed and cross-referenced.
- Verifiability: An SRS is verifiable if there exists a particular technique to quantifiably measure the extent to which each and every requirement is met by the system. For example, a requirement stating that the system should be user-friendly isn't verifiable and listing such requirements should be avoided.
- Traceability: One must be able to trace a requirement to a design component & then to a code section within the program. Similarly, one ought to be able to trace a requirement to the corresponding test cases.
- Design Independence: There should be a choice to choose between multiple design alternatives for the final system. More specifically, the SRS mustn't embody any implementation details.
- Testability: An SRS should be written in such a way that it is straightforward to come up with test cases and test plans from the document.