Prototyping is a repetitive practice involving analysts and users in which a miniature or a test version of an information system is built and rebuilt according to user feedback.[5] Prototyping preceded by interviews and collecting documentation, allows the analyst to quickly convert basic requirements into a working, though a limited version of the desired information system. The prototype will be then viewed and experienced by the user, thus generating new requirements.
For example, in the first interviews, a stakeholder might have said that he wanted all significant products billing information on a single computer display form, such as the customer’s name and address, the product record, and the inventory history. Once the same user sees how jammed and confusing such a design would be in the prototype, he might change his mind and opt for a presentation in which the information is organized on different screens. This calls for a redesign of the system, hence prototyping.
The advantages that can be realized through this approach are:
- Systems requirements are better captured as the system is being developed.
- It solves the communication problems that may have existed between users and analysts in making sure that the requirements are specific as possible.
- It involves the user in analysis and design, and thus captures requirements in concrete, rather than verbal or abstract.
On the other hand, the drawbacks of this technique are:
- Prototypes are mainly developed as stand-alone systems hence ignoring sharing of data and systems interactions.
- The prototype may be presumed as efficient by the initial user but other users may find it difficult to adapt.
- There is a trend to avoid outlining formal documentation due to the changing requirements. This may delay the overall system development.
