Requirements Analysis – Part 5 Prototypes

Prototypes are mock-ups of an application. Mock-ups allow users to visualize an application that hasn’t yet been 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. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.

While proving a useful technique, prototyping did not solve the requirements problem:

1. Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
2. Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to ‘waste time’ starting again.
3. Prototypes help with design decisions and user interface design. However, they can not tell you what the requirements originally were.
4. Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.

Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations.

Prototypes can be flat diagrams (wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the software design 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.