In Software Development Life Cycle (SDLC) the first step is Requirement Gathering where we need to start carefully with reading the Software Requirements Specification (SRS) document, understanding the requirement, raised the queries about missing, incomplete or unclear requirements. The main aim of the this stage is to understand and unclear the hidden requirements.
The SRS is basically the set up agreement between supplier and the customer tell us about “what are we going to implement in software application.” As per the IEEE standard the characteristics of a great SRS should be Clear, Correct, Complete, Traceable, Modifiable, Verifiable, Ranked for importance and/or stability, Consistent and Unambiguous.
If development team started working on implementation without resolving the missing/unclear requirements then this will introduce defects in the software application.
It is always better to catch the ambiguities in requirement early in the SDLC. Cost of fixing the defects in early stage is lower than fixing defect in later stages. It is most important to identify the ambiguities in the requirement before design specifications and project implementation phases of SDLC, hence this first stage is also known as Defect Prevention step.
In this article we will discuss about detailed guidelines for Software Requirements Specification document reviews and checklist:
- Make sure that all team is participating in the Software Requirements Specification document Review and read specification document carefully and discuss each and every point with your team members.
- The main part of SRS should cover about the Functionality and it should tell us about “What is the software supposed to do?” It will be helpful if SRS covering about “What is the software not supposed to do?” So make sure that all functionality is properly covered.
- Review the requirement specification document carefully and if you observed terms used which in specs leads to ambiguities then ask stakeholder about the clarification. You can check the ambiguous terms used in SRS like usually, sometimes, some, mostly, most, may be etc.
- Check the terms used like lists but not clearly mentioned or fully mentioned the list like So on, etc, Make sure you should clarify the full list.
- Check about what all attributes are considered in the SRS like correctness, portability, security, maintainability etc.
- Do not assume any requirements; if any requirement is unclear then you should raise the queries. Example, if one input field is accepting amount greater than 10 and less than 100. So here you can ask about are we going to support decimal points for this filed, if yes then how many places.
- If the requirement is explained with big paragraph then make sure that you are breaking the paragraph in small sentence and prepare a picture or graph to better understanding of scenario.
- If any unclear specifications, make sure that all queries should be resolved from the Product Manager as soon as possible.
- If any calculation is involved to get the particular values, then make sure that you reviewing the calculation with different sets of input data (think of passing boundary value conditions.)
- Check for the Performance parameters requirement is considered in SRS document, if yes then you can ask for the requirements about what should beresponse time, availability, speed, recovery time etc.
- If the module is bit bigger and complex in nature then divide the module into its features and check the test scenarios around the feature. You can also break down the test scenarios as well into the test cases if test scenario is also bit complex.
- Make sure that all question/queries/pending issues should be tracked under issue tracker (you can also track this in simple excel as well). Make sure that capturing each and every question in the tracker and make sure that it should get resolved from the Product Manager or Program owner.
- Upon getting clarification from them, then make sure that revision history is maintained.
- Once the all queries get resolved and final sign off requirement specification document is finalized and now if any change requirement is came then you should raise queries about impacted areas.
Conclusion:
In this article we have covered characteristics of requirement measurement. Here I am sum up the requirement testing in simple statement:
- Requirements should be clear and every point should specifically mention.
- Requirements should be complete, without any inconsistency.
- Requirements should be testable and every testable requirement should have some criteria to evaluate the requirement.
- Requirements should be measurable and it can be measured with specific standards/terms.
Make sure that any ambiguities in requirement should be identified early in the SDLC phase so it will reduce the cost to fixing the uncertainty in requirement. You should more talk stakeholders to clarify the requirement before starting design and implementation phase.
Have you worked on reviewed Software Requirements Specification document?
⇓ Subscribe Us ⇓
If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:
Happy Testing!!!