1 version 1.0 02/05/2004 © 2004 robert oshana requirements engineering prototyping

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 1

Prototyping



Software Prototyping

• Animating and demonstrating system requirements



What is a Prototype?

• A prototype is a concrete executable model of selected aspects of a proposed system

• Rapid prototyping is the process of quickly building and evaluating a series of prototypes

• Usually only a partial representation of the system and serves as an aid in analysis and design



ProjectRisk?

technology

requirements

I nvestmentStrategy?


throwaway

throwaway

evolutionary

evolutionary

Breadth of risk

Breadth of risk

Breadth of risk

narrow

narrow

narrow

narrow

broad

broad

broad

broad

vertical

vertical

vertical

vertical

horizontal

horizontal

horizontal

horizontal

ProjectRisk?

technology

requirements



throwaway

throwaway

evolutionary

evolutionary

Breadth of risk

Breadth of risk

Breadth of risk

narrow

narrow

narrow

narrow

broad

broad

broad

broad

vertical

vertical

vertical

vertical

horizontal

horizontal

horizontal

horizontal

Types of prototypes



Continuum of understanding user’s needs

Well known Fuzzy Unknown

Fuzzy needs become more understood

Yes, but… responses from the user – unknown needs become known



Uses of system prototypes

• The principal use is to help customers and developers understand the requirements for the system

• The prototype may be used for user training before a final system is delivered

• The prototype may be used for back-to-back testing



Prototyping benefits• Misunderstandings between

software users and developers are exposed

• Missing services may be detected

• Confusing services may be identified

• A working system is available early in the process

• The prototype may serve as a basis for deriving a system specification



Prototyping Opportunities

• Not to prototype at all should simply not be an option in software development

• End user cannot throw the S/W needs (stated in natural language) over the wall and expect the development team to return the finished S/WE with no problems

• Must be some interaction between the end user and the development team



Prototyping process

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport



Prototyping objectives

• The objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood.



Prototyping objectives

• The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood



Approaches to prototyping

Evolutionaryprototyping

Throw-awayPrototyping

Deliveredsystem

Executable Prototype +System Specification

OutlineRequirements



Evolutionary prototyping

• Must be used for systems where the specification cannot be developed in advance e.g. AI systems and user interface systems

• Based on techniques which allow rapid system iterations

• Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system



Evolutionary prototyping

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N



Evol. prototyping problems

• Existing management processes assume a waterfall model of development

• Continual change tends to corrupt system structure so long-term maintenance is expensive

• Specialist skills are required which may not be available in all development teams

• Organizations must accept that the lifetime of systems developed this way will inevitably be short



Throw-away prototyping• Used to reduce requirements risk• The prototype is developed from an initial

specification, delivered for experiment then discarded

• The throw-away prototype should NOT be considered as a final system– Some system characteristics may have been

left out– There is no specification for long-term

maintenance

– The system will be poorly structured and difficult to maintain



Throw-away prototyping

Outlinerequirements

Developprototype

Evaluateprototype

Specifysystem

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents



Prototypes as specifications

• Some parts of the requirements (e.g. safety-critical functions) may be impossible to prototype and so don’t appear in the specification

• An implementation has no legal standing as a contract

• Non-functional requirements cannot be adequately tested in a system prototype



Incremental development

• System is developed and delivered in increments after establishing an overall architecture

• Users may experiment with delivered increments while others are being developed. therefore, these serve as a form of prototype system

• Intended to combine some of the advantages of prototyping but with a more manageable process and better system structure



Incremental development process

Validateincrement

Build systemincrement

Specify systemincrement

Design systemarchitecture

Define systemdeliverables

Systemcomplete?

Integrateincrement

Validatesystem

Deliver finalsystem

YES

NO



Prototyping with reuse

• The system is prototyped by ‘gluing’ together existing components

• Likely to become more widely used as libraries of objects become available

• Needs a composition language such as a Unix shell language

• Visual Basic is largely based on this approach



Reusable component composition

Componentcomposition

system

Executableprototype

Reusablecomponentrepository

SystemSpecification

Componentcatalogue



User interface prototyping

• It is impossible to pre-specify the look and feel of a user interface in an effective way. prototyping is essential

• UI development consumes an increasing part of overall system development costs

• Prototyping may use very high level languages such as Smalltalk or Lisp

• User interface generators may be used to ‘draw’ the interface and simulate its functionality



Prototyping Pitfalls

• Learning curve– high expectations for productivity with

insufficient effort behind the learning curve—training for the use of a prototyping technique—need to develop corporate and project

specific underlying structure to support the technology (or lower productivity may result)

• Tool efficiency– execution efficiencies associated with tools

outside the domain of conventional programming languages



Prototyping Pitfalls• Applicability

– application domain has an impact on selecting a prototyping technique

—i.e. need real-time support features for a process control system

– techniques for specific application domains—business—computer aided design—distributed—flight control—user interface—software engineering environments



Prototyping Pitfalls

• Undefined Role Models for Personnel– approach to providing feedback to end users

has resulted in a problem related to the behavior of the end user and developers

—end users can be biased in interactions with development team based on past experiences



Prototyping Opportunities

• Existing investment in maintained systems– prototyping can be used on critical portions of existing

software systems

• Adding investment in fully exploiting the technology– s/w prototyping must be integrated via training, case

studies, library development

• Developer to end user pass off– end user involvement becomes enhanced when

changes in requirements can first be prototyped



Prototyping

• One should not start full-scale implementation efforts based on early user interface designs

• Early usability evaluations based on prototypes faster and cheaper

• Traditional S/W engineering focused on refinement of various intermediate work products– executable programs at the last moment



Prototyping

• No user interface til the last possible moment is high risk

• Not possible to involve users in the design process by having them look at abstract specifications

• Main idea behind prototyping is to save time and cost and to develop something that can be used with real users



Prototyping

• Savings can only be achieved by somehow reducing the prototype compared with the full system– cutting down the number of features– reducing the level of functionality of the features

(they seem to work but do not actually do anything)



Vertical Prototyping

• Cutting down on the number of features is called vertical prototyping

• Result is a narrow system that does include in-depth functionality but only for a few selected features

• Can only test a limited part of the full system– but it will be tested in depth



Vertical Prototyping

– Under realistic circumstances– with real user tasks

—actually accessing a DB with some real data



Two Dimensions of Prototyping

Different Features

Fu

nctio

nality

Vertical Prototype Full System

Scenario Horizontal Prototype



Horizontal Prototyping

• Reducing the level of functionality• Result is a surface layer that includes the

entire user interface to a full featured system but with no underlying functionality

• Horizontal prototype is a simulation of interface where no real work can be performed



Horizontal Prototyping

• Makes it possible to test the entire user interface even though the test is somewhat less realistic– users cannot perform any real tasks on a

system with no functionality

• Advantages are fast implementation with various prototyping and screen design tools

• Can be used to assess how well the entire interface “hangs together”




Different Features

Fu

nctio

nality





Scenarios

• Reducing both the number of features and the level of functionality is a scenario

• Scenarios are only able to simulate the user interface as long as the test user follows a previously planned path

• Easy and cheap to build• Not particularly realistic



Scenarios

• Ultimate minimalist prototype• Describe a single interaction session

without any flexibility for the user• Combines the limitations of horizontal

(users cannot interact with real data) and vertical (users cannot move freely through the system)



Scenarios

• Scenarios are encapsulated the following way– an individual user– using a specific set of computer facilities– to achieve a specific outcome– user specified circumstances– over a certain time interval



Scenarios

• Two main uses– used during the design of a user interface as a

way of expressing and and understanding the way users will eventually interact with the future system

– can be used during user evaluation of a user interface design to get user feedback without the expense of constructing a running prototype




Different Features

Fu

nctio

nality





Example Scenario - ATM

• 1. The user approaches the machine and inserts a bank card. No matter what side is up, the machine reads the card correctly

• 2. The machine asks the user to enter a four-digit personal identification number, and the user does so using the numeric keypad




• 3. The machine presents the user with a menu of four options, “withdraw $100”, “withdraw other amounts”, “make a deposit”, and “other transactions”. There is a button next to each of the menu options




• 4. The user presses the button for “withdraw $100”, and the machine pays out that amount, deducting it from the user’s account. If the user has more than one account tied to the bank card, the amount is deducted from the account with the largest balance.




• 5. The machine returns the bank card to the user




• This scenario raises some questions;– is $100 the best amount to have available as a

single-button choice?– Is it a good idea to have this accelerated option

for a pay out at the single push of a button, or should the user always be asked to specify the amount, in case there are several possibilities?



Scenarios

• Good tools in early design stages– Can be generated and edited before the user

interface has been fully designed

• Helpful for early participatory design exercises– users will find it easier to relate to the task-

oriented nature of the scenarios than to the abstract, and often function-oriented, nature of system specifications



Scenarios• Scenarios are also good for testing• Mockup drawings to supplement narrative• Elaborate scenarios are sometimes

produced in the form of “day in the life” videotapes– enactments of users (actors) interacting with a

simulated system in the course of their daily activities

– good special effects– can be shown to users for discussion



Producing Fast Prototypes

• 1. Place less emphasis on the efficiency of the implementation– does not matter how much disk space the

prototype uses because it will only be used for a short period of time

– slow response times for test users may be ok (too slow may cause errors!)

—efficiency measures will be invalid—better for early evaluation than measurement




• 2. Accept less reliable or poorer quality code– but try to reduce bugs and crashes

• 3. Use simplified algorithms that cannot handle all the special cases (such as leap years) – normally require a disproportionate amount of

effort to get right




• 4. Use a human expert operating behind the scenes to take over certain computer operations that will be too difficult to program– wizard of oz– User interacts normally with the computer– Input goes to the “wizard” instead of the

computer




– Wizard transforms the user input into appropriate format

– “listening typewriter”– experience with previously implemented

systems is helpful in order to place realistic bounds on the wizards abilities




• 5. Use a different computer system than the eventual target platform– faster, more advanced computer can be used to supports

more flexible prototyping tools

• 6. Use low fidelity media– not as elaborate as the final system– still represent the essential nature of the interaction

—scanned images instead of live video




• 7. Use fake data and other content– prototype of a hypermedia system using video

can use exiting video material, even if it is not an exact match

– ripomatics in the advertising industry—used to demonstrate concepts to clients before

they commit to pay for the shooting of new footage




• 8. Use paper mock-ups instead of running a computer program– based on printouts of screen designs, dialog

boxes, pop ups, etc– drawn using some standard package– user indicates the action– human plays the computer

—needs to be an expert in the way the system is going to work in order to keep the state of the system in mind




– Can be shown to large audiences on an overhead projector

– used when computers are not available (some conference rooms)




• 9. Rely on a completely imaginary prototype– experimenter describes a possible interface to

the user orally– pose a set of “what-if” questions as the user

steps through an example task– called “forward scenario simulation”

—more like interviewing and brainstorming rather than prototyping



Combining Techniques

• Several techniques could be combined to explore different aspects of usability of the total system– still images to test the integration of text and

images to support learning– live video to test interaction mechanisms for

controlling the data



Paper Prototyping Tips

• Prototyping is a quick way to incorporate direct feedback from real users into a design

• Bypasses times to create a working coded user interface

• Paper, scissors, and stickies • Maximum speed and flexibility




• Everyone on the development team can stay closely involved and productive

• Even if you can create a prototype fairly quickly in HTML or VB, must consider if the right people have the proficiency in the tool

• How well can the design team stay involved?




• Many usability problems come from someone on the design team with key information not being involved at the right level

• With paper, all can gather around the same table and contribute

• Changes can also be made on the fly without waiting for more development




• Users feel more comfortable being critical of paper prototypes because it doesn’t have a polished look– with a polished prototype users are more likely

to blame themselves or their lack of experience

• Remember goal is to measure the function and flow of the interface, NOT the look




• After doing several iteration with paper, then transfer to a more polished look

• Sometimes the inability to create a fancy effect on paper may be a warning that the effect is not usable– example - a rollover– some designers will use new technologies only

because it looks cool




• Paper mock ups are intended to capture the site’s functionality, not to demonstrate technology

• For existing products, create screen shots and annotate with stickies, whiteout, or other supplies

• Screen shots with hand drawn annotations is fine




• But be careful to not disrupt the entire screen with a hand drawn annotation



More on Rapid Prototyping

• Rapid Prototyping facilitates iterative design and formative evaluation

• Defined as "a form of simple, rapidly produced prototyping in which the prototype is used to collect information about both requirements and the adequacy of possible designs..”

• Not developed into the final product



Rapid prototyping

• Traditional techniques push evaluation to late in the cycle

• Prototyping involves building a system early that simulates the final system

• Rapid prototyping accelerates the construction, allowing for multiple iterations and more substantial changes



Artillery approach to rapid prototyping

Ready

Fire

Aim

design/redesign

prototyping/implementation

evaluationand analysis



Introduction

• Prototypes also encourage user participation and buy-in

• Early evaluation helps solve problem of how one tests a design without investing a large amount of effort into its construction.



Prototyping as Technique

• Prototyping is a technique, not a tool • Effective very early in the process • A process of synthesis, working towards

the abstract • Provides perspective and insight for both

developers and interaction designers



Dimensions of Prototyping

• Representation– How interaction designs are represented (e.g.

UAN) – More visual and user-task oriented are easier to

translate – Tend to avoid programming language styles



Dimensions of Prototyping

• Scope– The amount of the system included in the

prototype – Prototypes that do not include the underlying

system limit the functionality that can be tested, making integration more difficult

– As system gets implemented, add to prototype



Executability

• When can the prototype be run? • When compiled as part of the

implementation, turnaround is slow • In addition, it may only be available

intermittently • Continuously available prototypes are not

tied to the implementation • Typically interpreted, they allow fast update

for quick iteration cycles



Maturation

• How the prototype transitions to product. • System usually moves from prototype to

implementation to final product • If prototypes are discarded the process is

revolutionary. • If prototypes grow into final product it is

evolutionary.



Maturation

• Revolutionary processes useful in conjunction with very early prototyping

• Evolutionary allows code to be re-used



Characterizing Prototypes

• Global vs. Local– A global prototype is representative of the whole

system. It has breadth, and maybe depth. – A local prototype concentrates on one aspect. – Local prototypes are most useful in answering

specific questions or debates



Local prototyping

Should arc line selection require precisepicking with a mouse?

Should “grab handle” be used to aid arc selection



Local prototyping

OR



Weighing Prototypes

• Advantages– Promotes iterative design, leading to overall

shorter development, better products, etc. – Begins the paradigm shift in the user



Weighing Prototypes

• Pitfalls– Might not fit in with established procedures – May lead to reduction in discipline – Perception that prototype means project is

finished – Accuracy in the prototype – Need to ensure prototype is indeed like final

systems – Overdesign



Styles and approaches to prototyping

• Wizard of Oz Prototyping– A third party behind the scenes is running

things & responding to user actions without the user knowing about him/her

– This may be used in conjunction with low fidelity prototyping or horizontal prototyping (cases where the prototype has low executability).



Prototype Content

• Early Prototypes– Testing conceptual model, broader scope – Accuracy to final product can be lower – Should provide depth on most common user functions

• Late Prototypes– Accuracy to final product is more more critical – More detail oriented



Quickly Sketch this...



Add Behavior...



Transform it to this...

1 version 1.0 02/05/2004 © 2004 robert oshana requirements engineering prototyping

Documents

system requirements

system slide

system specification

understood slide

known slide

design slide

testing slide

away prototyping