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" [12].
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 [2].
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 [3]
suggests that there are four prototyping methodologies in use today which
supplement the traditional systems development life cycle:

Illustrative: produces only
mockups of reports and screens.

Simulated: simulates some system
functions but does not use real data or a database, model not implemented.

Functional: performs some actual system functions and uses real data
and/or a database, model not implemented.

Evolutionary: produces
model(s) that become part of the final operational system.

Others suggest such
categorizations as evolutionary versus throw-away [10].
Evolutionary in this case is similar to #4 mentioned above (sometimes known as operational
[8]
). It produces a model that evolves throughout the development of the
system and eventually becomes the final system. Throw-away (sometimes known as
exploratory [8]
, or
expendable [5]) 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.[4]
A low-fidelity prototypeis
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.

Figure 1: Transition of Prototyping Techniques [4]for more information on the techniques mentioned
in the chart click here

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. [8]
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.[8]

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. [7]
In Rapid Development: Taming Wild Software Schedules [10],
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]:

Provides a process to perfect the requirements
definition.

Provides a formal specification embodied in an
operating replica.

More enthusiastic and
constructive end-user, customer participation in requirements
activities.

Improved morale of end-users,
customers, and developers.

Greater level of user
satisfaction with systems development.

Users better prepared for
later stages of development due to familiarity with prototype.

Delivery of early
proof-of-concept.

Prototype may be easily
changed and even discarded.

Allows productive work to proceed despite initial
uncertainties.

Demonstrates progress at an early stage of
development.

May provide early training for future users of the
system.

May produce some useful deliverables even if the
project runs out of time or money.

Should result in a product that is a better fit for the
customer's requirements.

Systems produced through prototyping may be
judged easier to learn and easier to use.

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. [8]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]:

Can result in unrealistic
schedule and budget expectations.

Iterative
nature makes it difficult for management to plan and schedule.

Can bias the system analysis
process. If the prototype is computer-based manual alternatives are
unlikely to be considered.

Working prototypes may lead management and
customers to believe that the final product is almost ready for
delivery.

People can begin to think of
the prototype as the solution.

The excellent (or disappointing) performance
characteristics of prototypes may mislead the customer.

Prototypes generally lack security,
auditing, and other controls, and data integrity may be difficult to
ensure.

Often inefficient and
difficult to maintain.

Tendency not to document.

Customers may not be prepared to provide the
level or frequency of feedback required for iterative prototyping.

Tying a Sensible Knot [1]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, [5]
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]
:

Situation

Reason
to consider prototyping

Users
are uncomfortable with abstract models

Gives
user something real to interact with

*The
project will have a long development time

Gives
user and developers something to work with early on

The
requirements are highly uncertain

Allows
users to work through the requirements as the prototype develops

*No
comparable system has been previously developed - high innovation

Allows
for experimentation

Reaching
a solution calls for simulation, experimentation, or incremental
evaluation

Allows
for simulation, experimentation, and incremental evaluation

A
critical system is needed quickly

Prototyping
tools are generally designed for quick implementation. Can begin
requirements gathering quickly.

in
general prototyping tools are not designed for this type of project

users
are not available

many
of the advantages of prototyping are lost

large
number of users

managing
requests for changes is almost impossible

*small,
short-lived projects

the
prototyping effort can not be justified

*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.[5]

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.[4]
The approach solutions suggested here are based on fidelity but the key
points apply to any approach:

Key Points

Solution based on fidelity

Cost and schedule
constraints

If budget and schedule
are limited, consider low-fidelity prototyping,
especially paper mock-up, because they are very cheap and fast to develop.
If there are experienced programmers with fast tools to build a
computer-based prototype, medium-fidelity prototyping is also a
consideration.

Navigation and flow

Medium-fidelity prototyping
is good to simulate the system's interaction. In low-fidelity prototyping,
storyboard can show the system's direction.

User driven or
facilitator-driven

If a user-driven prototype is needed, medium to high-fidelity prototyping is recommended because users
can directly interact with the prototype. User-driven prototypes are the
type primarily discussed in this paper. Otherwise, if a
facilitator-driven prototype is needed where, for example, a developer
steps through screens while the user looks on, low-fidelity prototyping is the choice.

Look-and-feel the product

Medium and high-fidelity
prototyping can help users gain the feeling of how the product works. If
using a low-fidelity prototype, the developer must be good at facilitating the
prototyping process.

Developer facilitation
skill/programming skill

This choice is based on the experience level of the
developer(s). If the developer has experience with prototyping using
low-fidelity prototyping this may be the appropriate choice. If the
developer has experience with medium to high-fidelity prototyping
involving programming it may be the most appropriate.

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
[14],
but can easily be extended to other parts of a prototyping project.

Ease
of use: good prototyping tools should allow all members to participate
in development and refinement of the prototype. Steep learning curves
are unacceptable because many of the contributors do not have time to
learn the tools.

Fast
turn-around: in prototyping many small refinements must be made.
Tools should allow developers to quickly make changes and quickly see
the results.

Extensive
control over prototype features: prototyping tools should be very
flexible so developers can try out new ideas.

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.

The promise of RAD is "cheaper, faster,
better". [16]
It strives to achieve that promise through [15]:

Gathering requirements using workshops or focus
groups

Prototyping and early, reiterative user testing of
designs

The re-use of software components

A rigidly paced schedule that defers design
improvements to the next product version

Less
formality in reviews and other team communication

Object-Oriented
methodologies often use prototyping and are often associated with RAD.
The Information System Consultant's Handbook [2]
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.