This is the second in the series about reviewing requirements. This week we are considering the method of using Testcases to review the requirements. Some people would feel that this is too early in the process to be considering testcases but we do not have to write complete testcases. Test conditions or objectives will be enough at the start and the payback is substantial.
As we mentioned in the last blog, reviewing requirements can be surprisingly difficult for some people. The following problems may arise:
- You don’t know anything about the system under review
- The requirements are disorganised
- It is difficult to maintain concentration for an extended period of time
The act of writing testcases (conditions or objectives) and attaching them to the requirement for which they were written (Traceability) has the impact of clarifying thoughts on what the requirement really means. Most requirements generate multiple testcases. In order to write even the start of the testcases, we need to be able to decompose the requirement into its component parts and understand each one. The process of doing this will highlight the deficiencies in the requirements.
- If our test conditions contradict each other then the requirements are probably inconsistent.
- If our test conditions don’t seem to cover everything, then the requirements are probably incomplete.
- If our test conditions expect to test items that are clearly wrong then the underlying requirements are probably wrong.
- If our test conditions seem unclear when completed, then the requirements are probably just as unclear.
- We could draw other conclusions but these are the main ones for requirements.
The process here is used to clarify the thought processes.
Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Requirements review is very cost-effective.
Contact us for further information.
Leave a Reply