Creating requirements involves tracking and documenting all of the criteria for a system's success. A requirements management tool, such as IBM Rational's RequisitePro, can support this effort. While the tool won't verify that the requirements are consistent, correct, complete, relevant, coherent, and testable, it can help manage the task more efficiently by allowing you to document, track, and maintain the requirements in an automated fashion.
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.
Testing, in its broadest sense, means ensuring that your visionaries and programmers are creating a helpful product that people will actually use. As the two authors of this installment of Bug Report illustrate, understanding how those users will operate your application is more than an exercise in empathy; it's a simple key to avoiding some real usability meltdowns.
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."
Brian Lawrence points to Mastering the Requirements Process as a valuable reference book. The book presents a complete step-by-step method for gathering, modeling, and specifying requirements. Along the way the authors offer easy-to-understand and appropriate examples that nicely illustrate how to apply their techniques.
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.
Recognized requirements expert, Karl Wiegers, shares the symptoms and solutions for common requirements-related project problems, including inadequate customer involvement, vague and ambiguous requirements, inadequate change process, and scope creep.