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.
Cookies are important to the proper functioning of a site. To improve your experience, we use cookies to remember log-in details and provide secure log-in, collect statistics to optimize site functionality, and deliver content tailored to your interests. Click Agree and Proceed to accept cookies and go directly to the site or click on View Cookie Settings to see detailed descriptions of the types of cookies and choose whether to accept certain cookies while on the site.
About Author
Ankita Sachan
Ankita is a Bright QA engineer and have experience in Manual and Automation Testing. loves to Travel to different places.