Requirements Phase Testing

TESTING DURING THE REQUIREMENTS STAGES

Ideas are tested now, not code. The "testers" (reviewers) include marketers, product managers, senior designers, and human factors analysts. Members of the Testing Group are rarely involved at this stage. (See Chapter 13 for useful planning-stage tasks for testers.)

The reviewers read drafts of the planning documents. Then they gather data, using comparative product evaluations, focus groups, or task analyses. These arc commonly described as planning and design tools, but they are also testing procedures: each can lead to a major overhaul of existing plans.

The reviewers should evaluate the requirements document (and the functional definition based on it) in terms of at least six issues:

• Are these the "right" requirements? Is this the product that should be built?
• Are they complete? Does Release 1 need more functions? Can some of the listed requirements be dropped?
• Are they compatible? Requirements can be logically incompatible (i.e., contradictory) or psycho logically incompatible. Some features spring from such different conceptualizations of the product that if the user understands one of them, she probably won't understand the other(s).
• Are they achievable? Do they assume that the hardware works more quickly than it does? Do they require too much memory, too many I/O devices, too fine a resolution of input or output devices?
• Are they reasonable? There are tradeoffs between development speed, development cost, product performance, reliability, and memory usage. Are these recognized or do the requirements ask for lightning speed, zero defects, 6 bytes of storage, and completion by tomorrow afternoon? Any of these might be individually achievable, but not all at once, for the same product. Is the need for a priority scheme recognized?
• Are they testable? How easy will it be to tell whether the design documents match the requirements?