Organizations of all types do it. Microsoft, Disney, and Boeing do it. It is known by several names: simulate, model, prototype. It is a process by which organizations innovate, better communicate both with their customers and with each other internally, develop and improve their products. Boeing builds digital prototypes of its aircraft allowing the detection of design conflicts before the parts are manufactured and assembled. Disney uses storyboards to work through the process of producing feature-length films. Microsoft sends out thousands of copies of "beta" versions of its software and then uses its customers as the testers of its "prototype" . Its a powerful technique, but what place does it have in systems analysis?
This paper will look at what prototyping is to systems analysis. It will explain some of the advantages and disadvantages of prototyping and discuss why an organization might or might not want to consider prototyping. It will discuss who should be involved in prototyping and how to choose a prototyping approach and a prototyping tool. This is meant to be an overview of prototyping in systems analysis rather than a step-by-step guide. Links are provided where more information is available online.
As mentioned earlier a prototype is like a model or a simulation of a real thing. In systems analysis a prototype is a model of the system (or subsystem) under analysis . A system can be anything from the food ordering system at a restaurant to the air traffic control system of a major airport. Prototypes of these systems can take many forms. They can be paper-based or computer-based. They can model the entire system with real data or just a few screens with sample data. Prototyping is the process of developing prototypes . It is a methodology in its own right and a technique and supplemental methodology to other methodologies. In this case, we will focus on the ways in which prototyping is used as a technique and a supplemental methodology to the systems development life cycle (SDLC).
A survey of MIS managers in Fortune 1000 firms  suggests that there are four prototyping methodologies in use today which supplement the traditional systems development life cycle:
Others suggest such categorizations as evolutionary versus throw-away . Evolutionary in this case is similar to #4 mentioned above (sometimes known as operational  ). It produces a model that evolves throughout the development of the system and eventually becomes the final system. Throw-away (sometimes known as exploratory  , or expendable ) would encompass the other three methodologies previously mentioned. A throw-away prototype is just what it sounds like. Once its purpose is fulfilled it is thrown away.
Another way that prototypes are classified is by the fidelity of the prototype, or the degree to which the prototype represents the appearance and interaction of the system. A low-fidelity prototype is one that is quickly constructed to depict concepts, design alternatives, and screen layouts. Medium-fidelity prototypes partially simulate the system interaction and functionality. High-fidelity prototypes are fully interactive, simulating much of the functionality in the final product. The chart below suggests techniques that could be used at different fidelity levels.
Included in the chart above are terms used to describe other prototyping concepts. A horizontal prototype models many features with little functionality. While a vertical prototype models few features, but with great detail in functionality.  A scenario prototype has both very few features and very little functionality. The figure below illustrates these concepts:
Another prototyping concept similar to those just discussed is that of a diagonal prototype. One that is horizontal down to a certain point and then is vertical beyond that.
One final classification of prototypes is global versus local. A global prototype models the entire system. It is much like a horizontal prototype, but goes into greater detail. A local prototype models a single system component. It is much like a vertical prototype that is focused on only one feature.
As shown here a prototype can be defined by its functionality, features, data, interaction, and lifespan. There are no doubt more ways to classify and categorize prototypes, but these few demonstrate how characteristics can vary from one prototype to the next.
Systems analysis is the requirements determination phase of the systems development life cycle (SDLC). In this phase developers determine how the current system functions and what users would like to see in a new system.  In Rapid Development: Taming Wild Software Schedules , Steve McConnell states that "A survey of more than 8000 projects found that the top three reasons that projects were delivered late, over budget, and with less functionality than desired all had to do with requirements-management practices: lack of user input, incomplete requirements, and changing requirements (Standish Group 1994)." Systems development today is any many ways software development. Just as with software, getting this phase right is critical to the success of the entire system. The reasons mentioned above for project shortfalls are really the result of poor communication. Prototyping, when used as a communication tool between the developers and the users, can help to overcome these problems.
As a model of the new system a prototype allows for several forms of communication. First, it allows the developers to communicate to the users their understanding of the requirements. (Obviously before a prototype can be built there must be some initial requirements discussions between developers and users). The initial prototype, whatever form it takes, will automatically reflect the developer's understanding of those early requirements. After viewing/interacting with the initial prototype the second form of communication begins. The users give the developers feedback. Not only will the users correct any misconceptions by the developers, but they will likely recognize misconceptions or requirements they did not anticipate of their own. From this point on the process is iterative. Developers will make corrections and changes to the prototype based on user feedback and the users will view/interact with the prototype and make changes to the requirements. This continues until they come to an agreement on the requirements or run out of time or money or both. At its best this process provides for very rich user input resulting in well thought out requirements both for the user and the developer.
Improved communication is just one of many benefits that can be realized when prototyping in the systems analysis phase. Here are some others reported in systems development literature [13, 8, 11, 6, 10]:
Opinions on the cost of prototyping vary. Some feel prototyping can allow for lower maintenance costs since the prototype is meant for change. While upfront costs can be high when purchasing special prototyping tools.  Others feel that the cost of prototyping is about the same as traditional requirements gathering. They argue the tool cost and extra time for building the prototype are offset by the time saved later in getting the requirements right.
Even though the benefits of prototyping are strong there are disadvantages and potential risks associated with it. The primary concerns are that of excessive change requests and "feature creep". Just by the nature of the iterative process users will again and again request changes. As they reexamine the prototype they may think of new features they would like that are beyond the scope of the original project. These can be controlled with proper planning but both are legitimate concerns. Other concerns include [8, 10, 2]:
Tying a Sensible Knot 
is a look at the best practices of New York State local government
information systems projects. In a section on prototyping this guide
summarizes how the NYS Department of Social Services considered
"feature creep" to be a good thing. Click here
to download a pdf version of this guide. The article on prototyping begins
on page 68.
The primary participants in the prototyping process are the developers and the users. The developers provide the development and prototyping expertise. The users provide the systems expertise. As with any project management support is critical both for the developers and the users. The developers will need support from their management to acquire the necessary resources for the project. Both developers and users will need management support to continue the iterative process through to its conclusion.
In the study described in Toward a Contingency Model for Selecting an Information System Prototyping Strategy,  the authors found that there were five variables, when combined with prototyping, that affected system success. The first two variables involved project innovativeness and system impact on the organization. The remaining three variables involved the developers and users.
The first developer/user variable determined to affect system success when used with prototyping was developer experience with prototyping. According to the study, the primary benefit of experience is that the developer is prepared for the frequent changes in user requirements and for the high level of interpersonal communication required. Ironically, this study found if developers were already familiar with the application in development prototyping was of little use because less interaction was needed to determine requirements.
The remaining two factors which
appear to affect system success are the amount of user participation and
the number of users involved in the project. It should come as no surprise
that when higher user participation is combined with prototyping projects
are more likely to succeed. What is critical is that the high user
participation comes from just a few people. A large number of users mixed
with prototyping makes the development process more difficult to manage.
Each user has his own ideas about how the system should work. Processing
and implementing the changes of each user becomes considerably more
difficult when a large number of users are involved.
Systems development efforts differ in so many ways. Each has its own scope, requirements, developers, users, management, level of innovativeness, development time, complexity, organizational culture, etc. While prototyping can be a strong asset for one project it can turn out to be a burden for another. The key is to use prototyping wisely. System development experts suggest that prototyping positively affects the outcome of a system under development in the following situations [2, 9, 5] :
*These recommendations are not universal. For example, some argue that the high number of changes in requirements for a project of long duration justify prototyping. While others argue that prototyping's lack of manageability make its use questionable in projects of long duration. Some argue that existing systems projects do not benefit from prototyping, whiles others argue that when the existing system becomes the prototype it can be beneficial.
Once an organization decides to use prototyping during systems analysis they must then decide on what kind of prototype they will build. Will they use an evolutionary or throw-away prototype? Will they use a low, medium or high-fidelity prototype? Will it demonstrate lots of features with little real functionality as with a horizontal prototype? Or will it have a lot of functionality in one area with few features as with a vertical prototype?
Here are some key points to considering when deciding on the most appropriate approach. The approach solutions suggested here are based on fidelity but the key points apply to any approach:
After deciding on a the prototyping approach the prototyping tool must be selected. The goal is to fit the tool to the requirements of the system under development, the skills of the developers, and the needs of the users. Here is a brief list of prototyping tools starting at the top with the less formal moving down to more formal tools [8, 2]. The links in this list provide one of three things: either information about general use of the tool, information about prototyping use of the tool, or an example of the use of the tool with prototyping.
Here are a set of features to be aware of when selecting a prototyping tool. They are derived from a set of requirements for user-interface prototyping , but can easily be extended to other parts of a prototyping project.
It should be mentioned that prototyping is not only used as a supplement to the SDLC, but it is also heavily used in Rapid Application Development (RAD) and Object-Oriented methodologies.
methodologies often use prototyping and are often associated with RAD.
The Information System Consultant's Handbook 
describes the purpose of object-oriented analysis as finding and
describing the business objects and in identifying the relationships
between the objects via a conceptual model. Prototyping naturally helps
developers and users in finding and describing these business objects and
identifying the relationships by giving them a hands-on tools. One of the
primary advantages reported of object-oriented development is the increase
in productivity because objects and code can be reused. Prototyping and
reuse go together because it is easier to prototype if there is a library
of reusable classes.
Prototyping can be a powerful technique in systems analysis. Before deciding to prototype developers must look at the system under development and consider whether prototyping is appropriate. They must weigh the potential benefits against the potential risks. They must consider the people involved in the project, whether they are experienced prototypers or unenthusiastic users. They must consider the prototyping approach, whether illustrative, simulated, functional, evolutionary, or throwaway, vertical, or horizontal, low-fidelity, or high-fidelity, global or local. They must consider the tools available to them.
Appropriately used in systems analysis, prototyping can lead to improved communication between developers and users. It can provide a process for defining the requirements. It can allow productive work to proceed even while uncertainties remain. It can provide a living specification for the final system. Appropriately used, prototyping can be the difference between success and failure.