Prototype

Problem: Early acquired requirements are difficult to validate without testing.

Context:

Trying to gather requirements necessary for test planning, as in pattern Application Design is Bounded By Test Design, and for the architecture, as for the pattern Architect Also Implements.

Forces:

Requirements are always changing.

Written requirements are usually too ambiguous.

Need to get requirements changes early.

Designers and implementors must understand requirements directly.

Solution:

Build a prototype, whose purpose is to understand requirements. Prototypes are particularly useful for external interfaces. Throw the prototype away when you're done.

Resulting Context:

A better assessment of requirements to supplement use cases. This pattern nicely complements Engage Customers and Scenarios Define Problem.

Design Rationale:

The processes of the visualizations used for Developer Controls Process, and the pattern Engage QA, are based largely on prototyping.

"The best friend of the architect is the pencil in the drafting room, and the sledgehammer on the job." -- Frank Lloyd Wright, quoted in Building with Frank Lloyd Wright, by Herbert Jacobs, Chronicle Books, 1978.

Next: Take No Small Slips