You should define a checklist or checklists which helps focus the attention of requirements validators on critical attributes of the requirements document. These checklists should identify what readers should look for when they are validating the system requirements.
| Key benefit | Help to focus the validation process |
| Costs of introduction | Low-moderate |
| Costs of implementation | Low |
| Guideline type | Basic |
The use of checklists for requirements analysis has already been discussed in Guideline 5.2, Use checklists for requirements analysis and similar checklists may also be used in the validation process. These checklists are oriented towards individual requirements; validation checklists should also be concerned with the quality properties of the requirements document as a whole and with the relationships between individual requirements. This canÕt be checked during requirements analysis as the requirements document is unfinished at that stage.
Questions which might be included in such a checklist should be based on the following general issues:
Checklists should be expressed in a fairly general way and should be understandable by people such as end-users who are not system experts. As a general rule, checklists should not be too long. Checklists should not normally have more than ten items. If you have more than this, checkers cannot remember all items and must continually re-consult the checklist.
The danger , of course, is that checklist become too vague and it is impossible to answer the checklist questions in any useful way. You have to find the right balance between generality and detail. Unlike program inspections, low-level checklists concerned with very specific faults are not so good for requirements inspections because of the differences between the requirements for different types of system.
Checklists can be distributed and simply used as a reminder of what people should look for when reading the requirements document. Alternatively, they can be used more systematically where, for each requirement, an indication is given that the checklist item has been considered. This may be done on paper or you can manage this type of checklist completion by using a simple database or a spreadsheet. The checklist items are shown along the horizontal axis and the requirements along the vertical axis. The checker should fill in each cell with an appropriate comment. You shouldnÕt force checkers to use an automated approach, as people may read the document in places and at times when they donÕt have computer access.
This is not an expensive guideline to implement if you use a fairly general checklist with questions like those listed above. To introduce the guideline, you need to draw up an initial checklist based on the experience of people who have been involved in requirements validation. If a checklist is simply used a memory aid, there are no costs involved in applying the guideline.
If checkers of the requirements must mark each requirement against the checklists, clearly some additional time is required. This should not be more than one or two minutes per requirement.
In principle, there should be few problems in applying the guideline so long as you have a fairly flexible process which allows people to ignore inappropriate checklist entries. In practice, some requirements analysts may resent the introduction of checklists as they see them as de-skilling the process. You have to emphasise that the checklists are designed to help them and point out that professional judgement must still be used.