Software prototypes or mockups are "visuals only" versions of the software program being developed which simulates the flow, layout, and functionality of the final application.
They help demonstrate how the final software would function in terms of business flow and interface, before the real version is developed.
Whenever a software is developed, it is developed based on the requirements of the client. When you describe the business requirements, the business analyst, together with the project manager, defines the specifications of the software based on which the final product is developed.
Trouble starts because different people can interpret a given sentence written in the specification document in different ways.
Trouble starts when different people interpret a sentence given in a specification document in different ways.
Who provides the project specifications with such intricate details that no anomalies can be present? As a client, you might assume that the details are "implied" when making a general statement.
On the other side, project managers and developers assume that the client has provided full details, and create software based on these details, often without covering the implied meaning.
What this causes is an essential communication gap, despite an effort by all parties to document and communicate all the features properly and with full details, which -- for all practical purposes -- is impossible to accomplish just using textual documents. So how do we tackle this problem? We make prototypes.
Changes cost exponentially more to implement the later they are detected in the development lifecycle. Early determination of what is really required, can result in faster and less expensive software.
Although lacking real code logic, prototypes can describe workflows of an application much better than any documentation can. The development team can easily build a prototype showing how the functionality would work in the end solution, according to how they interpret it and present it to you for inspection.
You can look at the prototype and quickly identify the mistakes in interpretation, which resolves many misunderstandings. Since you and the end users know the problem domain better than anyone on the development team does, increased interaction results in the final product being of better quality. The final product is more likely to satisfy the users' desire for look, feel and performance.
Prototypes save time and money by improving the quality of requirement specifications, and bridge communication gaps.
Prototypes allow everyone to visualise the application and quickly expose missing requirements and unnecessary complexity.
A prototype demonstrates to the customers what is functionally feasible and stretches their imagination, leading to more creative inputs and early client involvement and interaction.