Inspections

The specification review should be undertaken as an inspection. For those readers unfamiliar with the term, inspections (Fagan inspections, to attribute them correctly) are a formalized process of ensuring the quality of documents. Much has been written about Fagan inspections, and we do not propose to add to that body of literature here. A brief outline of the process is sufficient.

The inspection process kicks off with a planning activity in which the materials and the inspectors are determined. A moderator usually handles this task. The inspectors are given an overview of the document under consideration, and they have about three days to study the material. The inspection meeting properlimited to two hoursstudies the document using checklists. These checklists, which are lists of potential errors, are updated when new errors are discovered. The author reworks the document, and the moderator ensures all defects have been removed. If necessary, the moderator arranges a follow-up inspection.

The original paper (one of the most cited papers in software history) is Fagan, Michael. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, vol. 15, no. 3 (1976), pp. 258287. Fagan inspections have been incorporated into several books.

Fagan inspections teach us that a certain amount of formality in our processes can, indeed, be beneficial in accuracy and efficiency. Much statistical evidence shows that inspections reduce the cost of development, and that projects employing inspections are more likely to meet their deadlines.

You can easily adopt some of the Fagan rules. For instance, try these tactics:

• Assign a moderator to take responsibility for arranging the inspection and distributing the materials.

• Give inspectors three days to read the document and prepare for the inspection.

• Limit inspections to two hours and no more than two inspections a day.

• Have between three and eight inspectors.

Gilb, Tom, and Dorothy Graham. Software Inspection. Addison-Wesley, 1993.

Wiegers, Karl. Peer Reviews in Software: A Practical Guide. Addison-Wesley, 2001.

All of these guidelines make sense in the context of inspecting a requirements specification.