In the mid-1980s, prototyping became seen as the solution to the requirements analysis problem. Prototypes are mock ups of the screens of an application which allow users to visualize the application that isn’t yet constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. When they were first introduced the initial results were considered amazing. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of the screens led to fewer changes later and hence reduced overall costs considerably. However, over the next decade, while proving a useful technique, it did not solve the requirements problem:
- Managers, once they see the prototypes, can find it difficult to understand that the finished design will not be produced for some time.
- Designers often feel compelled to use the patched together prototype code in the real system, because they are afraid to ‘waste time’ starting again.
- Prototypes principally help with design decisions and user interface design. However, they can’t tell you what the requirements were originally.
- Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
Prototyping can be used to show users what a requirement would be like if implemented, it can be used early in the requirements gathering phase of a project. It is useful when users are unsure of what the new system could or should do. The role of the analyst here is to demonstrate what the new system can do – this can only be simulated – to help the users towards more rigorous requirements definition. In theory what can be shown to users is quite detailed; however it is not yet ‘real’. The analyst should note users’ reactions to the prototype and discuss them in an appropriate forum where decisions will be made about whether to adopt or reject users’ observations and requests.
What could a user ‘see’? Prototypes can be flat diagrams (referred to as ‘wireframes’) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all colour from the software design (i.e. use a greyscale colour palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.