Testing Requirements
I'm sure all of you would agree that software requirements are a pre-requisite to developing any large system. However, how do you determine when the requirements are detailed enough to proceed with development? How much details do you need before you can sign off on the software requirements specifications (SRS)?
The answer is simple. Requirements Definition is one of the various activities of the software lifecycle, and like any other activity, it must be tested before being declared as complete.
The purpose of the requirements verification activity is not to examine whether the requirements are right or wrong. This has already been determined during the requirements gathering and analysis phase. The purpose of the requirements verification activity is to determine if the requirements are complete, and to ensure that there are no trade-offs. In other words:
- Are the requirements detailed enough that a designer can start implementing his/her feature?
- Are any requirements contradicting each other?
If the requirements are incomplete or contradictory, someone will identify the problem at some point in the product's lifecycle. Perhaps a designer will require more details before proceeding. Or perhaps a tester will realize that two requirements contradict each other while writing the system test. In either case, the issue will have to be resolved before proceeding. The question is, how much will the resolution cost?
If a developer discovers the issue early on, say, as he's trying to design the application, it can hopefully be resolved without incurring any incremental costs. However, if the problem is discovered by the tester while executing system tests on an application that's about to be shipped, it might require the redesign of an entire feature, which will not only cost money, but also delay the release.
Requirements Inspection
The first activity should be a simple inspection. Once the requirements have been reviewed and accepted, the author of the document, along with representatives from product development and quality assurance, should inspect the requirements to make sure that they contain enough details, and that no two requirements contradict each other. This activity shouldn't take more than 1-2 hours, depending on the size of the SRS. Remember, the goal of this activity is not to argue about whether a requirement is right or wrong; it's to determine whether the specified requirement is detailed enough to proceed with an implementation.
Acceptance Test Plan
Once the inspection is successful, the Quality Assurance team should attempt to draft the Acceptance Test Plan (ATP). This activity, which should take no more than 2-3 days, will really help determine how detailed the SRS is. If the Quality Assurance team cannot write the ATP based on the SRS, do not expect the developer to be able to implement the feature. As a best-case scenario (or worst-case?), the developer will try to read between the lines and deduct his own solution, which may or may not meet the customer's expectation.
Discommended Methods
While there are other activities that can help you test the SRS, the two listed above are by far the most efficient. They will identify the vast majority of the problems, and will only take 2-3 days to complete. While there are other activities that can achieve the same goal, many are not worth the effort. In my opinion, writing a user's manual or extremely detailed test cases are not efficient exercises for testing requirements. They require too much effort, and are too tedious to maintain when the requirements change. (Yes, requirements do change!).
Summary
Before signing off on the SRS and starting the implementation, carefully inspect the requirements and write the ATP. The time invested in these two activities will be more than worth it, and will help you meet your customer's demands and keep the project on track.
This article was originally published on www.gantthead.com.