The requirements phase of the software development (SD) process has often been described as the most critical phase because of its impact on overall development costs. Poor requirements definition can easily translate to cost overruns, poorly developed end products and even outright project failure. In all cases you end up with unhappy customers.

The solution is to get the requirements right the first time. Sounds simple, after all people ought to know what they want. But the issue isn't whether people know what they want. The issue is can they convey what they want to the developer? The human mind is not systematic in its approach to problem analysis. So when a user has to elaborate all her needs to a developer, two things will often happen.

First, the user will usually be able to elaborate primary functions only. The underlying detail will not be clearly revealed if revealed at all. Second, user activity will be biased by the user's specific point of view. This bias can easily blur the user's interpretation of functions. It's a dilemma every developer faces and many if not most never uncover the true requirements.

Throwaway Prototyping (TP) is the perfect solution to ambiguous requirements. Here is how it works. With a first pass set of initial requirements the developer builds a "quick and dirty" prototype.

Note two things. First, the requirements are strictly preliminary. They may turn out to be accurate or they may be totally wrong. Second, quick and dirty simply means no frills. That is, no validation, no security, no performance consideration and minimal functionality.

With these preliminary set of requirements and the initial prototype in hand, the developer and user analyze the prototype for accuracy. Usually, one of two things will happen. The user will agree with the prototype, meaning the initial requirements represented by the prototype are correct. The user will disagree with some part or all of the prototype. In a sense, this disagreement is exactly what the prototype is suppose to surface. Disagreement crystallizes the differences between developers and users. This disagreement is an opportunity to get it right!

Once agreement is reached between developer and user on the changes to be made, the prototype is rebuilt to meet the new agreed upon requirements.

The next phase involves both user and developer working together to extend the prototype to include new requirements. Once additional requirements have been surfaced, the developer enhances the prototype with the added functionality and the whole process is repeated.

This process is repeated until all the agreed upon requirements have been uncovered and represented in the prototype.

Why do prototypes work? First, a prototype's visual nature more closely resembles the human view of the real world. A picture is automatically packed with stored information. This visually stored information releases the human mind from trying to store all the detail in working memory and allows the viewer to think in greater depth about what's being represented in the prototype.

Second, a prototype acts as a perfect mediator between the developer's point of view and the user's point of view, views that are more often than not significantly different. Without a mediating prototype, the finished product will more than likely be a clear representation of the developer's view only. The prototype is able to merge the disparate views creating a product that's much closer to the user's desires.

Once all requirements have been defined, the prototype is thrown away - a task often disturbing to the user. Remember, however, throwaway prototypes are merely a guide. Their lack of robustness and underlying detail makes their extension into the real product dangerous.

RR 2 Box 168, Jericho, VT 05465, 802-899-3115 Info@lavalleeccs.com