MIDTERM
REQUIREMENTS GATHERING,
STORYBOARDING
AND
PROTOTYPING
By the end of the lecture you should
be able to…
Practically apply three phases of the
UCD process:
Requirements gathering
Design and storyboarding
Prototype implementation
Waterfall model of lifecycle (revised)
Requirements
specification
Architectural
design
Defined
design
Coding
Integration &
deployment
Integration &
deployment
Stages of the Waterfall model
(revised)
Requirements specification
Functional requirements
Data requirements (Inputs and outputs)
Environmental requirements (context)
User requirements
Usability requirements
Architectural design
Focus on how requirements can be achieved
E.g. OO, UML, ERD
Stages of the Waterfall model
(revised)
Detailed design, coding and unit testing
E.g. specification of classes, objects, methods and
properties
Produce software
Integration and testing
Integrate individual components
Put into operation
Maintenance
Usage may identify further errors
REQUIREMENTS GATHERING
Describing what the proposed system
should do
Not how it should do it, or what it should look like
In UCSD: requirements cannot be used
as contractual basis
Not possible to accurately specify requirements
at the start of a project
May be iteratively refined as
design/development progresses
Clients might not ask for a feature because
they did not know initially that it is possible
REQUIREMENTS GATHERING
Output: The requirements statement
Functional requirements: What system
needs to do to be useful
Usability requirements: What the system
needs to do to be usable
For each requirement
What it is?
Where it comes from? (Justification)
Metric to measure system performance with
respect to it (if possible)
Metrics
A ‘metric’ is a way of measuring
things
Metrics can be direct or indirect
Ifyou weigh something, then you are directly
measuring its weight
Measuring the volume and density and then
calculating the mass is an indirect metric
Metrics
Most HCI metrics are indirect
Quantitative
Time & response time
Key presses
Number of errors
Qualitative
User satisfaction
User enjoyment
Types of requirements
Functional requirements
Usability requirements
Data requirements
Environmental requirements
User requirements
FUNCTIONAL AND USABILITY
requirements
Difference between useful and usable:
Useful: can do the task
Usable: easy to do the task
Functional requirements:
What makes the system useful
Typically quantitative
They are there or not there
E.g. “The system should allow the user to enter
credit cards details and debit the user’s account
accordingly”
It is clear whether or not the system does or does not do
this
FUNCTIONAL AND USABILITY
requirements
Usability requirements:
What makes the system usable
More qualitative
Might not be clear how to measure whether
a system fulfills a usability requirement or
not
USER, DATA and ENVIRONMENT
requirements
User requirements
Who the users are?
What capabilities do they have?
Environment requirements
Where will the system be used?
Under what circumstances?
Data requirements
What data the system needs to input and
output?
STORYBOARDS
Important that design must relate to
requirements
Storyboards: Rough sketches of what the
system will look like
Good for predominant graphical interfaces and web sites
Cheap to produce, easy to change
Maybe also need a ‘map’ showing how the
‘narrative’ of the storyboard runs
Storyboard = example of paper
prototyping
STORYBOARDS examples
STORYBOARDS examples
STORYBOARDS examples
STORYBOARDS TEMPLATE
PROTOTYPES
IEEE defines prototyping as “ A type
of development in which emphasis is
placed on developing prototypes
early in the development process to
permit early feedback and analysis in
support of the development
process.”
PROTOTYPES
Consists of user interfaces that seem to
look and behave like a complete system
Can be tested on real users
Purpose
To turn an abstract idea into physical form
To communicate your ideas
To iterate and improve
PROTOTYPES
Produce information on
The functionality
Operation sequences
User support
Look and feel
Characteristics
Should be ‘cheap’
Quick & easy to change
Types of prototyping
Throw-away Prototyping
Evolutionary Prototyping
Low Fidelity Prototyping
High Fidelity Prototyping
Throw Away Prototype
Throw Away Prototype is developed from the initial
requirements but is not used for the final project.
Written specifications of the requirements
Some developers believe that this type is a waste of time
because you don’t use it.
Regardless if prototype is discarded or kept for production,
you must use a easy to use language.
Evolutionary Prototype
Evolutionary prototyping is consider the most fundamental
form of prototyping.
Evolutionary prototyping main concept is to build a robust
prototype and constantly improve it.
Objective to deliver a working system to the end user.
According to Steve McConnell, "evolutionary delivery is a
lifecycle model that straddles the ground between
evolutionary prototyping and staged delivery."
Low-fidelity Prototyping
Low-fidelity prototyping is generally limited function, limited
interaction prototyping effort.
They are constructed to depict concepts, design alternatives
and screen layouts. They are intended to demonstrate
general look and feel of the interface.
They are created to educate , communicate and inform, but
not to train, test or serve as a basis for which to code.
Low fidelity prototyping is used early in the design cycle to
show general conceptual approaches without much
investment in development.
Low vs. High Fidelity Prototyping Debate, Rudd J., Stern K.,Isensee S., ACM Interactions, Jan. 1996
High-Fidelity Prototyping
High-fidelity prototypes represent the core functionality of the
products user interface.
High fidelity prototypes are fully interactive systems. Users
can enter data in entry fields, respond to messages, select
icon to open windows and interact with user interface as if it
were a real system.
They trade-off speed for accuracy.
Building high fidelity prototypes consume resources and have
high cost.
Low vs. High Fidelity Prototyping Debate, Rudd J., Stern K.,Isensee S., ACM Interactions, Jan. 1996
Advantages & Disadvantages of Prototyping
Advantages Disadvantages
Users can try the system and provide Each iteration builds on the previous
constructive feedback during iteration and further refines the solution.
development This makes it difficult to reject the initial
solution as inappropriate and start over.
An operational prototype can be produced Formal end-of-phase reviews do not occur.
in weeks Thus, its is very difficult to contain the
scope of the prototype.
Users become more positive about System documentation is often absent or
implementing the system as they see a incomplete, since the primary focus is on
solution emerging that will meet their development of the prototype.
needs
Prototyping enables early detection of System backup and recovery,
errors performance, and security issues can be
overlooked.
Reference: http://facpub.stjohns.edu/~wolfem
Risks in Prototyping
Client may believe that system is real.
Unrealistic expectations of the progress
Implementers make poor choice
Justified in prototype but not in real system
Tempting to build real system same way
Prototype is not identical to the real system
Users may interact differently due to different
response characteristics
Must interpret prototype experience with care
ANY QUESTIONS?
