When a software is required to be built; it should stick to the requirements of the users. Sadly, most often the built software does not match the requirements of the user. It happens because understanding between the project team and the users often is not good enough. This results in wrong software product made and delivered.
The best way to mitigate this risk is to develop a software product prototype first and show it to the users. Users see and interact with this prototype. Then they give their feedback as to what changes they need in the prototype. The prototype is then modified based on this feedback and shown to users again. This process continues until users are fully satisfied. Based on this prototype, the software product is built.
Creating a prototype is thus a way to minimize risks involved in software development. Building prototypes are actually a kind of feasibility study. If during prototype building if the project team finds that it is technically or economically not feasible to build a software product then the project can be shelved.
There are 2 types of prototypes: throwaway prototype & evolutionary prototype. When a project team creates a prototype which does not involve extensive source code writing and thus this prototype can be thrown away and not used in actual software development is known as throwaway prototype. Generally this type of prototype suits well for waterfall based software projects.