In this section:

|
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? |
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 |