Prototyping

In this section:


		user participation
		prototyping
		focus groups
		workshops & JAD
		benchmarking
		issues & problems

A written document does not convey how the product will actually work for most users. A lot of projects come to grief because the requirements document, although signed off by users or shown to customers, does not meet what they actually want.

A prototype is a cheap and effective way to confirm the broad thrust of requirements. Users are much more able to articulate what they actually want when faced with a software prototype.

We are not however advocating that you prototype all the requirements - just enough to check that the general direction is correct.

Why?

Building a simple prototype as part of the requirements definition takes 2 to 4 weeks and might simulate 8 or 10 screens, and include one relatively simple business process.

Typically a tool such as VB or Director is used to create this sort of prototype.

It only takes a few weeks

In a large project, there might be a need to other issues such as technical feasibility, for example that the database can support the transaction load generated by 100 simultaneous users.

Following the DSDM approach, we can identify 3 types of prototype:

HCI or User Interface prototype
Business Process prototype
Technical Feasibility prototype.

They are not incompatible with one another, but they have different purposes. Combining all three can lengthen the time required.

A more complex prototype that also demonstrates features of all 3 types might take 6 to 8 weeks to build. It should use the actual programming tools you intend to use for the real product, and will probably be reused as part of the actual production code.

Other types of prototype

There is no point in building a prototype if it is not validated with the users.

There are a number of techniques that can be used. See focus groups and benchmarking for more information.

Validating the prototype

Previous topic

Next topic

Top