Some have said: "The prototyping process experiences a series of birthdays while traditional software development experiences a series of deadlines."

This is cute, but not always true. I've been involved in prototyping efforts where the prototype's first 'birthday' was the single deadline. But we knew ahead of time what the goals were to be, and this made a huge difference in how we executed the prototyping effort.

Recursive just means that the first prototype most likely will not be the last for a specific PD effort (but it certainly can be). Each prototype will expose things that need to be changed, deleted or improved - things that constitute the goals for a subsequent prototype. But be careful, because of R limits you will eventually need closure to the process.

A prototype needs to have scope; and the scope should generally cover -

1. The type of prototype: e.g. experimental, exploratory, operational, horizontal vs. vertical vs. diagonal, global vs. local, Lo-fi vs. Hi-fi, paper, simulation, hard model, virtual, etc.*
2. The goals: e.g. demonstrate / verify performance, functionality, cost-of-manufacture, interoperability, interaction, etc.
3. The domain of the goals: e.g. is the prototype used for market, user, regulatory, technology, production, service, quality, robustness or financial verification or investigation?
4. The Stakeholders: those who are designated to interact with a prototype for the purpose of its evolvement.
5. The R constraints: budgets and schedules can dictate the extent of the first three items.

Some feel that the design specification of a prototype is the prototype itself. There is some sense to this, since an early-stage prototype is usually loosely defined and is used to discover or 'iron out' features and performance issues. However, as stated above, a prototype should have scope and closure so that it does not blow the business case for the PD project.

---

* See references at the end of this article.