Every system contains at least one (and probably more) set of requirements that fits into one of these categories: the functional who, what, where, when, why, how, and the nonfunctional design and project constraints. No one method or technique captures all requirements, but this approach can assist quality engineers in identifying missing requirements. Our objective is to spot the gaps in the requirements sets—just as a Tetris player spots gaps in those moving blocks—as soon as possible.

Brian Marick argues for using testers at the requirements analysis stage of a project. He says, "While QA is primarily about process, testing—my specialty—is about product. Whatever else a tester might do, she certainly eventually exercises the product with the aim of discovering problems a user might encounter. This essay is about that 'whatever else' the tester does."

Most advice on requirements gathering is targeted for brand-new "green-field" projects. What about evolving projects? Here's a seven-point strategy for those of us working on maintenance, updates, and legacy documentation.