• A mockup or simulated throwaway implementation of a planned system.
• Demonstrates functional or behavioral requirements rather than non-functional ones.
• Emphasis on fast, cheap development.

• Feasibility (proof of concept) prototypes have a different goal than usability prototype.
• Various styles are possible; storyboard, facade implementation, RAD, etc.
• If it's not thrown away, it isn't a prototype.

• Clarify Requirements via feedback from user
• Provides a visible demonstration that is easier for user to assess than written description.

• Gives early guidance / feedback to developers
• Provides a tangible/visible demonstration of feasability or usability.
• Missing features or misunderstood requirements can be identified.
• Incomplete or inconsistent requirements can be discovered by developer.
• Difficult to use or confusing features can be identified, esp. usability.
• Easily modified to explore alternatives.
• A basis for writing the specification for the production system.
• Easy to scrap (low investment)

• Takes resources that aren't directly used for finished product.
• Customer may conclude finished product is nearly ready.
• Developers may think "quick and dirty" is acceptable.
• Management may apply pressure to turn the prototype into the finished product.
• Developers enamored with their prototype spend too much time perfecting it.

• Go low-tech: paper and pencil storyboard
• Inefficiency is okay
• Reuse code
• Take advantage of Prototyping tools
• "wizard of oz" style
• Select the simplest prototype style necessary to gather the feedback you need.

The prototype must be discarded. Don't reuse any code in the actual system.