|
Are Your Requirements Complete? 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.
|
|
|
Requirements When the Field Isn't Green 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.
|
|
|
Collaborate for Quality Project teams are searching for ways to develop requirements that are as free from defects as possible. Here's how you can use collaborative workshops, along with walkthroughs and QA checklists, to develop high-quality requirements.
|
|
|
Testing in the Dark How can you test software without knowing what it should do? Here is a step-by-step approach to overcoming undocumented requirements, including how to discover the requirements, how to define "quality" for the project, and how to create a test plan including release criteria.
|
|
|
On-Track Requirements: How to Evaluate Requirements for Testability Prior to using the requirements to develop the Test Plan, an analysis should be performed to evaluate the testability of the requirements. This article suggests a proven method used on a recent project that accomplishes such an evaluation.
|
|