Inspecting Requirements

• products. These categories might include reporting, edit operations, security, user customization, printing, and transaction logging, or whatever functional areas your products typically include.
• Make sure that the source and usage of all data items are stated.

The Inspection Meeting
During the inspection meeting, the reader describes his interpretation of each requirement in his own words. Such paraphrasing allows the other participants to compare their understanding with that of someone other than the author. Differences in interpretation can reveal omissions and surface assumptions. Inspection is a powerful method for uncovering ambiguities, in which different readers interpret a requirement in different ways.

If the reader has difficulty describing a requirement, perhaps it is too complex, poorly expressed, or incorrect. Simply reading the specification aloud verbatim or asking the inspectors if anyone has any questions on each page fails to catch many requirements problems.

Review Early and Often
Run your requirements through a quality gauntlet of both informal reviews and formal inspections. Instead of waiting until the big honkin' requirements specification is done, start holding informal reviews when it is perhaps 10 percent complete. Informal reviews will reveal many errors quickly and cheaply.

I recently reviewed a badly flawed 300-page specification. It had serious organizational problems, violated every rule for writing unambiguous requirements, and omitted important information. Had I examined just the first thirty pages several months ago, I could have suggested many improvements in the way it was being written. This would have saved much rework at this late stage.

I want to learn about errors in the requirements before I've written any code for that part of the system, not when an irate customer calls. Inspections are a powerful way to help me achieve that goal.