There are some important advantages to using a prototype in systems analysis. Identifying requirements is one such important advantage. When developing a prototype, new requirements may emerge. These requirements may emerge as a result of the user see the system and realizing that system requirements may not have been communicated in their entirety. Additionally, the user may see the prototype and realize that they simply left out important business items. Furthermore, through interactions with the user during the prototype development process, a developer may identify misunderstandings in the business requirements. In any case, quick identification of gaps in what the system will deliver versus what is needed are crucial and can be brought to light through the prototype process. This often translates into it costs more time savings.


There are clear disadvantages to using the process of prototyping as well. For instance, prototyping may fail to capture important complex requirements of large systems. Additionally, prototyping tends to not lend itself to strict documentation processes. Therefore, though customers may be able to communicate quickly any changes in business requirements, these requirements may not be documented.

McConnell (1996) warns that there may be inappropriate tendencies for managers to want to retain prototypes and to convert them into fully functional systems, even when the initial use of the prototype is reserved as a throwaway. Cooper (1995) reveals this dilemma stating that “any code, even prototype code, tends to never be thrown away.”