Software Requirement

Engineering
Risk Reduction Through
Prototyping Week # 14
Reading
“Sharon, today I’d like to talk with you about the
requirements that the buyers in the Purchasing
Department have for the new Chemical Tracking
System,” began Lori, the requirements analyst. “Can
you tell me what you want the system to do?” “Wow,
I’m not sure how to do this,” replied Sharon with a
puzzled expression. “I don’t know how to describe what
I need, but I’ll know it when I see it.”
2
Discussion for Reading
• IKIWISI—“I’ll know it when I see it”—is a phrase that chills the blood of
requirements analysts.
• Many people have difficulty describing their needs without having
something tangible in front of them for reviewing is much easier than
creating.
• Software prototyping makes the requirements more real, brings use
cases to life, and closes gaps in your understanding of the requirements.
• Early feedback on prototypes helps the stakeholders arrive at a shared
understanding of the system’s requirements, which reduces the risk of
customer dissatisfaction.

3
Prototyping: What and Why
• A software prototype is a partial or possible implementation of a proposed new product. Prototypes
serve three major purposes:

• Clarify and complete the requirements. Used as a requirements tool, the prototype is a preliminary
implementation of a part of the system that’s not well understood. User evaluation of the prototype points out
problems with the requirements, which you can correct at low cost before you construct the actual product.
• Explore design alternatives. Used as a design tool, a prototype lets stakeholders explore different user interaction
techniques, optimize system usability, and evaluate potential technical approaches. Prototypes can demonstrate
requirements feasibility through working designs.
• Grow into the ultimate product. Used as a construction tool, a prototype is a functional implementation of an
initial subset of the product, which can be elaborated into the complete product through a sequence of small-scale
development cycles.

• The primary reason for creating a prototype is to resolve uncertainties early in the development
process. Use these uncertainties to decide which parts of the system to prototype and what you hope
to learn from the prototype evaluations.
• A prototype is useful for revealing and resolving ambiguity and incompleteness in the requirements.
4
Types of Prototypes
• Horizontal Prototypes
• When people say “software prototype,” they are usually thinking about
a horizontal prototype of a possible user interface. A horizontal
prototype is also called a behavioral prototype or a mock-up. It is called
horizontal because it doesn’t dive into all the layers of an architecture
or into system details but rather primarily depicts a portion of the user
interface.
• This type of prototype lets you explore some specific behaviors of the
intended system, with the goal of refining the requirements. The
prototype helps users judge whether a system based on the prototype
will let them get the job done.
5
Types of Prototypes
• Horizontal Prototypes
• Horizontal prototypes can demonstrate
• the functional options the user will have available,
• the look and feel of the user interface (colors, layout, graphics, controls), and
• the information architecture (navigation structure). The navigations might
work, but at some points the user might see only a message that describes
what would really be displayed.
• The information that appears in response to a database query could
be faked or constant, and report contents are hardcoded. Try to use
actual data in sample reports, charts, and tables to enhance the
validity of the prototype as a model of the real system.
6
Types of Prototypes
• Vertical Prototypes
• A vertical prototype, also known as a structural prototype or proof of
concept, implements a slice of application functionality from the user
interface through the technical services layers.
• A vertical prototype works like the real system is supposed to work
because it touches on all levels of the system implementation.
• Develop a vertical prototype when you’re uncertain whether a
proposed architectural approach is feasible and sound, or when you
want to optimize algorithms, evaluate a proposed database schema,
or test critical timing requirements.
7
Types of Prototypes
• Throwaway Prototypes
• Before constructing a prototype, make an explicit and well-communicated decision as to whether
the prototype will be discarded after evaluation or become part of the delivered product.
• Because you’ll discard the prototype after it has served its purpose, build it as quickly and
cheaply as you can. The more effort you invest in the prototype, the more reluctant the project
participants are to discard it.
• When developers build a throwaway prototype, they ignore much of what they know about solid
software construction techniques. A throwaway prototype emphasizes quick implementation and
modification over robustness, reliability, performance, and long-term maintainability.
• For this reason, don’t allow low-quality code from a throwaway prototype to migrate into a
production system. Otherwise, the users and the maintainers will suffer the consequences for the
life of the product.
• The throwaway prototype is most appropriate when the team faces uncertainty, ambiguity,
incompleteness, or vagueness in the requirements. Resolving these issues reduces the risk of
proceeding with construction
8
Types of Prototypes
• Throwaway Prototypes
• Figure 13-1 shows a sequence of development activities that move
from use cases to detailed user interface design with the help of a
throwaway prototype.

9
Types of Prototypes
• Evolutionary Prototypes
• In contrast to a throwaway prototype, an evolutionary prototype provides a solid
architectural foundation for building the product incrementally as the requirements
become clear over time.
• Evolutionary prototyping is a component of the spiral software development life
cycle model (Boehm 1988) and of some object-oriented software development
processes (Kruchten 1996).
• In contrast to he quick-and-dirty nature of throwaway prototyping, an evolutionary
prototype must be built with robust, production-quality code from the outset.
Therefore, an evolutionary prototype takes longer to create than a throwaway
prototype that simulates the same system capabilities. An evolutionary prototype
must be designed for easy growth and frequent enhancement, so developers must
emphasize software architecture and solid design principles.
10
Types of Prototypes

11
12
Paper and Electronic Prototypes
• You don’t always need an executable prototype to resolve requirements
uncertainties. A paper prototype (sometimes called a lo-fi prototype) is a
cheap, fast, and low-tech way to explore what a portion of an
implemented system might look like (Rettig 1994; Hohmann 1997).
• Paper prototypes help you test whether users and developers hold a
shared understanding of the requirements. They let you take a tentative
and low-risk step into a possible solution space prior to developing
production code.
• A similar technique is called a storyboard (Leffingwell and Widrig 2000).
Storyboards often illustrate the proposed user interface without engaging
the user in interacting with it.
13
Paper and Electronic Prototypes
• If you decide to build an electronic throwaway prototype, several
appropriate tools are available (Andriole 1996). These include the
following:
• Programming languages such as Microsoft Visual Basic, IBM
• VisualAge Smalltalk, and Inprise Delphi
• Scripting languages such as Perl, Python, and Rexx
• Commercial prototyping tool kits, screen painters, and graphical user
interface builders
• Drawing tools such as Microsoft Visio and Microsoft PowerPoint

14
The Risks of Prototyping
• Although prototyping reduces the risk of software project failure, it
introduces its own risks. The biggest risk is that a stakeholder will see
a running prototype and conclude that the product is nearly
completed.

“Wow, it looks like you’re almost done!” says the enthusiastic prototype
evaluator. “It looks great. Can you just finish this up and give it to me?”

15
The Risks of Prototyping
• Another risk of prototyping is that users become fixated on the how aspects
of the system, focusing on how the user interface will look and how it will
operate.
• A third risk is that users will infer the expected performance of the final
product from the prototype’s performance. You won’t be evaluating a
horizontal prototype in the intended production environment. You might
have built it using tools that differ in efficiency from the production
development tools, such as interpreted scripts versus compiled code. A
vertical prototype might not use tuned algorithms, or it might lack security
layers that will compromise the ultimate performance. If evaluators see the
prototype respond instantaneously to a simulated database query using
hard-coded query results, they might expect the same fabulous performance
in the production software with an enormous distributed database. 16
Prototyping Success Factors
• To make prototyping an effective part of your requirements process,
follow these guidelines:
• Include prototyping tasks in your project plan. Schedule time and resources to
develop, evaluate, and modify the prototypes.
• State the purpose of each prototype before you build it.
• Plan to develop multiple prototypes. You’ll rarely get them right on the first try
(which is the whole point of prototyping!).
• Create throwaway prototypes as quickly and cheaply as possible. Invest the
minimum effort in developing prototypes that will answer questions or resolve
requirements uncertainties. Don’t try to perfect a throwaway prototype.
• Don’t include extensive input data validations, defensive coding techniques,
error-handling code, or code documentation in a throwaway prototype.
17
Prototyping Success Factors
• Don’t prototype requirements that you already understand, except to explore
design alternatives.
• Use plausible data in prototype screen displays and reports. Evaluators can be
distracted by unrealistic data and fail to focus on the prototype as a model of
how the real system might look and behave.
• Don’t expect a prototype to fully replace an SRS. A lot of behind-thescenes
functionality is only implied by the prototype and should be documented in
an SRS to make it complete, specific, and traceable. The visible part of an
application is the proverbial tip of the iceberg. Screen images don’t give the
details of data field definitions and validation criteria, relationships between
fields (such as UI controls that appear only if the user makes certain
selections in other controls), exception handling, business rules, and other
essential bits of information.
18