COEPD – Center of Excellence for Professional Development Happy Learning
Inspection Checklist For Software Requirements
What is a requirement? In the most simplified language, a requirement is, basically, the need of a client. The client specifies that need to a Business Analyst, or we analysts have to extract that during our elicitation meeting. It may happen (which happens most of the time) that the client is not sure what he/she wants and we have to read between the lines to help them reach to that conclusion. After we have had that nice, long chat with the client, we think we have really got the requirements clinched and our job of elicitation is done. But is it really done? Well, the answer is no. So before you, as a business analyst, move ahead with prioritizing the requirements and documenting them and planning the approach, you must be having a checklist of what all you should have done and completed before you ended that call with the client. This is when we use the Requirements Inspection Checklist.
Requirements Inspection Checklist poses a variety of questions to the analyst, who in turn, uses them to validate the requirements gathered during the elicitation activity. But we already have our 3C for validating requirements, don’t we? But there is much more to that than the requirements being Correct, Complete and Consistent. A lot of questions, posed in the Requirements Inspection Checklist, need to be answered before the analyst obtains the final sign-off on the requirements elicited.
Apart from other areas, the checklist focuses on the Functional, Non-functional and Transition requirements. These ‘other’ areas are checks for important requirements’ features like their organization (how they are organized), their Traceability and any other ‘Special Issues’ that come up once you go through what you have obtained from the client. We have a ‘General Checklist’, an ‘Interface Checklist’, a ‘Behavioral Requirements Checklist’ and a ‘Non-Behavioral Requirements Checklist’, a ‘Requirements Quality Checklist’ and many more, which is flexible, depending upon the type of requirements already gathered by the business analyst.
Probing further into the questions which are a part of the inspection checklist, we have the following questions which, once answered satisfactorily, can help us analysts finish most of our inspection tasks and can save several more ‘clarification’ calls with the client :
- Do requirements exhibit a clear distinction between functions and data?
- Here, the analyst checks whether functionalities (to be developed) for which the requirements have been gathered are separated from the data required as input for the same.
- Do requirements define all the information to be displayed to users?
- This is one of the most essential parts, as at the end of the day, the most important thing is what the user will be able to view and how will they utilize what they view. Basically, this is another way of asking “Do we know all about how the users will know what to use?”
- Do requirements address system and user response to error conditions?
- A nightmare for every stakeholder. But in a way, it is caused by user responses, too. So once we have the requirements, we need to check how the system reacts to erroneous conditions. Specifically, we check when error messages are displayed, ambiguity in the messages, how clearly they describe the error that has occurred.
- Is each requirement stated clearly, concisely and unambiguously?
- This will answer the 3C we talked about earlier, as these are the primary attributes for requirements.
- Is each requirement testable?
- The testers are the ones we need to convince, after all. So while it may not be possible to have a member of the Quality Assurance team present during requirement elicitation, we analysts should ensure that every requirement we gather, should be testable once developed.
- Are there ambiguous or implied requirements?
- All requirements specified should be direct and self-explanatory.
- Are there conflicting requirements?
- After taking care of the conflicts between the stakeholders specifying requirements, we need to check if we have not received any requirements that come in the way of implementing another opposite or similar requirement.
- Are performance requirements stated?
- We check here, if these non-functional requirements have been clearly stated, as they will be as important as our functionalities.
- Have requirements for performing software upgrades been specified?
- These are the transition requirements.
- Are there requirements that contain an unnecessary level of design detail?
- The design team does not want to be performing unnecessary exhaustive investigation on the requirements, resulting in a delay. So we analysts must ensure that the requirements we have are precise and ready-to-work-on, for them.
- If the requirements involve complex decision chains, are they expressed in a form that facilitates comprehension (i.e., decision tables, decision trees, etc.)?
- Decision trees and decision tables basically help us in clearly determining the power flow in case we need decisions taken and critical questions answered. So the requirements need to help us define our RACI stakeholders more clearly.
- Have the real-time constraints been specified in sufficient detail?
- Our software solution will have (and should have) certain constraints, certain drawbacks, for it to efficiently perform its function. These constraints occur in real time, may have to be possibly verified during our UAT. Again, if these constraints have been clarified by the requirements, it becomes easier for all concerned.
- Has the precision and accuracy of calculations been specified?
- Now this is about any calculations or other mathematical operations our software solution may have to perform.
Summing up, the above questions help make our task easier in communicating the requirements to the developers and other stakeholders. We don’t want to be calling the stakeholders time and again, asking the same questions in different ways. To be efficient analysts, we not only should be getting the information right at one go, but also we need to own that information till we deliver the promised software solution.
References:
- http://www.swqual.com/images/requirements_checklist.pdf
- http://www.swqual.com/images/requirements_checklist.pdf
