Paper
Prototyping
http://www.flickr.com/photos/21218849@N03/3901372331/sizes/l/
Customers and users
should be your friends
• They probably know much more about the
problem than you do.
• They probably have some ideas about how to
solve the problem.
• They are your best resource for discovering
your own mistakes before you start to code.
Risk: an unwanted event that has
negative consequences
• Risk impact: the loss that would result if a risk
turns into a problem
– Measured in time, quality, cost
• Risk likelihood: probability that the risk will
turn into a problem
– Risk exposure = impact * likelihood
• Risk control: the degree to which you can
reduce exposure
Risk management
• Risk management
– Risk assessment
• Risk identification
• Risk analysis
• Risk prioritization
– Risk control
• Risk reduction
• Risk management planning
• Risk resolution
Example risks
in an e-commerce application
• Risk: mobile phones (unexpectedly) need to
be supported
– Impact: 30% of revenue? Likelihood: ???
• Risk: credit card validation component cannot
handle debit cards
– Impact: 10% of revenue? Likelihood: ???
Risk management and prototyping
• Traditional requirements-gathering
– Good for controlling risks regarding what the
system should do
– But don’t know what the system should look like
• Prototyping
– Good for controlling risks regarding what the
system should look like
– Not so good for non-visual aspects of the system
Top ten risks
•
•
•
•
•
•
•
•
•
•
Personnel shortfalls
Unrealistic schedules and budgets
Developing the wrong software functions **
Developing the wrong user interface ***
Gold plating ***
Continuing stream of requirements changes **
Shortfalls in externally performed tasks *
Shortfalls in externally furnished components *
Real-time performance shortfalls
Straining computer science capabilities *
The general idea of prototyping
1. You depict what you think the system should
look like.
2. You test the prototypes with customers or
(preferably) users.
3. You fix up the prototypes and use what you
learn to implement the real system.
Waterfall kinds of processes
Requirements analysis
Prototyping
Design
Implementation
Testing
Operation
Spiral kinds of processes
Draft a menu of
program designs
Analyze risk &
prototype
Draft a menu of
architecture designs
Draft a menu of
requirements
Analyze risk &
prototype
Establish
requirements
Plan
Establish
architecture
Plan
Operation
Analyze risk &
prototype
Testing
Implementation
Establish
program design
Different kinds of prototypes
• Throwaway prototypes
– Paper prototypes: sketches on pieces of paper
– Low-fidelity prototypes: implemented with a
tool (e.g.: Photoshop)
• Evolutionary prototypes
– High-fidelity prototypes: implemented on the
target platform… not fully functional, but destined
to be incorporated into the final product
Paper prototypes
• Sketch on paper and/or post-it notes
• Don’t worry (much) about colors, fonts, icons
• Doesn’t need to be beautiful
• Does need to show all important UI elements
• Does need to be intelligible by users
Example system
Here are the functional requirements:
• System will have web pages for mobile phones
where citizens can report panhandlers
• Certain users called “volunteers” will
view reports and “claim” panhandlers
• After visiting a claimed panhandler to offer
social services (e.g.: counseling), a volunteer
can mark a panhandler’s report as “done”
Example system
Here’s a panhandler report state chart
Report status
New
(just reported)
claim
Done
(visited by volunteer)
unclaim
Claimed
(by volunteer)
mark done
succeeds
“Testing” prototypes
• Pretend to be the computer while a user tries
to perform a use case with your prototype
• Let the user interface speak for itself
– So shut up and see if the user can do it himself!!!
• If the user misunderstands the user interface,
then fix it on the spot if you can.
– Principle: the user is always right (in prototyping)
UC#1: Report panhandler
•
•
•
•
Actor: any user
Preconditions: user views site in mobile browser
Postconditions: system records report
Flow of events:
– User selects a city
– User enters information about the panhandler
– System validates inputs
– System records report in database
1. User selects a city
2. User enters information
about the panhandler
3. System validates inputs
4. System records report in
database
UC#2: Process panhandler
• Actor: volunteer (member of task force)
• Preconditions: volunteer logged in via mobile browser
• Postconditions:
– Volunteer reviews list or map of panhandlers
– Volunteer marks report as “claimed”
– System records report as claimed
– Volunteer visits the panhandler
– Volunteer marks report as “done”
– System records report as done
1. Volunteer reviews list or map of
panhandlers
2. Volunteer marks report as
“claimed”
3. System records report as claimed
4. Volunteer visits the panhandler
5. Volunteer marks report as “done”
6. System records report as done
1. Volunteer reviews list or map of
panhandlers
2. Volunteer marks report as
“claimed”
3. System records report as claimed
4. Volunteer visits the panhandler
5. Volunteer marks report as “done”
6. System records report as done
Some problems revealed by prototype
• What happens during “validation” of a
panhandler report?
• How does the volunteer navigate from the
“list view” to the “map view”?
• What happens if there are lots and lots of
reports… how does the user make sense of it?
• So what happens when the user marks a
panhandler report as “done”?
Non-visual problems that the
prototype might not catch
• What if there are duplicate reports?
• How do new cities get added to the system?
• Do users need to be authenticated to make a
panhandler report? Why/why not?
• Is the mapping interface really going to run
properly in a mobile browser? Sounds risky.
Identifying such problems requires techniques
beyond prototyping.
Low-fidelity prototypes
• Fidelity = “faithfulness” or closeness to what
the ultimate product would look like
– Paper prototypes are “ultra low” fidelity
• Low-fidelity prototypes can be made in
– Photoshop
– PowerPoint
– HTML
– Any other tool that’s cheap and easy to use
Promoting health awareness with a
“know your numbers” card & system
http://www.flickr.com/photos/juhansonin/347137175/sizes/o/
Prototype splash-screen for Anaconda,
an installer framework for Linux
http://www.flickr.com/photos/sstorari/3671284171/sizes/o/
Prototype of what an iPod might look
like with a 320x480 resolution
http://www.flickr.com/photos/ben30/2866006814/sizes/o/
Prototype of a site for managing and
sharing photos
http://www.flickr.com/photos/
missrogue/68077527/sizes/o/
Paper vs low-fidelity
• Low-fidelity lets you explore
– Colors, fonts, iconography, etc
• But low-fidelity
– Is more expensive
– Requires somebody with design “skillz”
– Is harder to fix on the fly
• And neither one can detect certain problems…
Diagram Notations
http://www.flickr.com/photos/cardoso/2197507288/
Did you plan to build the Enterprise
all on your own????
• Diagrams are often useful when…
– You need to communicate, visualize, or analyze
something
– And that something has some sort of structure
Typical parts of requirements
documentation
• Functional requirements
– Unstructured text
– Use cases
• Non-functional requirements
– Unstructured text
• Fit criteria
• Diagrams
– Class diagrams and entity-relationship diagrams
– Dataflow, sequence, and state diagrams
Use case diagram: shows
activities supported by the system
UC#1: Report repression
UC#2: Clarify tweet
Repressed citizen
UC#3: View reports
Concerned public
UC#3a: View on map
UC#3b: View as RSS feed
Notes on use case diagrams
• Stick man for user
• Ovals for use cases
– Italicize “abstract” use cases
• Simple arrows when a UC “calls” another
• Open arrowheads for specialization
– Similar to the role that sub-classing plays in OO
UML class diagram: shows
entities, attributes, relationships
User
+ Twitter username
1
Repression report *
+ source (tweet)
0..1 + location (geocode)
*
+ when (datetime)
+ details (string)
Clarification tweet
+ report
* + when (datetime)
+ text (string)
*
Repression tweet
1
+ user
+ when (datetime)
+ text (string)
System boundary
Repression view
* + reports
Google map view
+ JavaScript
RSS View
+ XML text
Notes on UML class diagrams
• One box per kind of entity, listing attributes
– Italicize abstract entities, attributes
• Lines without arrowheads show references
– Similar to member variables in OO
– Labeled with cardinality (multiplicity)
• Integers, ranges, or asterisk (for unlimited)
• Lines with open arrowheads for specialization
• Lines with regular arrowheads can be used to
indicate dependencies
– Usually omitted in requirements’ class diagrams
Entity-relationship diagram: shows
entities, attributes, relationships
User
Twitter username
1
yields
writes
n
1
Clarification tweet r
report
when (datetime)
text (string)
0..1
Repression report
p source (tweet)
location (geocode)
when (datetime)
details (string)
shows
s
asks
about
q
Repression tweet
user
when (datetime)
text (string)
Google map view
JavaScript
Repression view
reports
RSS View
XML text
Notes on entity-relationship diagrams
(ERDs)
• One box per kind of entity
• List entities on branches
• Lines with a diamond show relationships
– Diamond label indicates role of relationship
• Numbers or variables on lines show cardinality
Dataflow diagram: shows
flow of information
Reporter
Repression
info
Clarification
message
Tweet
Send
clar req
Tweet
Location
Viewing user
Map
Report
Twitter DB
Tweet
Interpret
Geocoder
RSS feed
RSS
View
Map
View
Geocode
Report
Reports
Reports
Reports DB
Clarification
message
Raw
report
Clarify
Notes on dataflow diagrams
• Each oval is a “function” provided by system.
– Each inward arrow is a parameter (labeled)
– Each outward arrow is an output (labeled)
• Each rectangle is an actor
– A person, place, or thing that can do stuff and/or
initiate events
• Each “half-rectangle” is a data store
• Often clearer if you do a separate dataflow
diagram for each use case
Message sequence diagram: shows
flow of control
User
Twitter
System
Database
Tweet event
Read tweets
Geocode
Create report
[if geocode != null]
Request to clarify
Deliver request [if geocode == null]
[geocode != null]
Geocoder
Notes on message sequence diagrams
• One box per entity involved
– E.g.: if you have two users interacting with each
other, then you would have two boxes
– Each box has a dashed line, showing its “lifetime”,
which can end if an object is destroyed
• Arrows show messages
– Also, draw an arrow back if there’s a return value
• Conditionals are written with brackets [ ]
– Loops can be enclosed in a shaded box
State chart: shows
change over time
Report status
Raw
(just text)
record
Geocoded
(geocode != null)
geocoding fails &
user retweets
In database
(geocode == null)
geocoding
succeeds
Notes on state charts
• One box per state
• Arrows show a possible state transition
– Annotated to indicate under what conditions the
transition occurs
• Filled circle shows where you “start”
• Nested filled circle shows where you “stop”
Putting it together:
a typical requirements document
• Requirements definition
– Unstructured text: functional & non-functional reqs
– Use case descriptions
– Class diagrams or ERDs showing external entities
• Requirements specification
– Unstructured text: functional & non-functional reqs
– Dataflow diagram
– Message sequence diagrams or state charts
An example system to support
drug and alcohol counseling
http://cf.polarishealth.com/demo/start_demo.html
Requirements definition,
functional reqs, unstructured text
• Before each counseling visit, each counselee
takes a survey.
• After each survey, the system prints a report
showing the counselee’s progress.
• Administrative assistants can add counselees
and their counselors to the system.
Requirements definition: written from external viewpoint; system is like a “black box”
Requirements definition,
non-functional reqs, with fit criteria
• Each survey will be short enough for an
average user to complete within 10 minutes.
• Progress reports will each be 2 pages or less.
• The system will print progress reports within 2
minutes of a survey’s completion.
• Users can take a survey using a Windows
machine that has a Pentium II 550 MHz CPU,
with 0.5 GB of RAM.
Requirements definition: written from external viewpoint; system is like a “black box”
UC#1: Survey and report
• Actor: Counselee
• Precondition: Counselee registered in system
• Postconditions:
– Counselee progress data is recorded in system
– Report is printed for use by counselor
• Flow of events:
– Counselee logs in (lastname + PIN)
– System collects survey data from counselee
– System prints report
Class diagram of entities
User
+ lastname (string)
+ PIN (int)
Counselor
+ reports
Counselee
*
+ counselor
+ surveys
Report
+ surveys
*
+ counselor
1
*
1
1
*
Survey
+ questions (String [])
*
+ answers (int [])
+ counselee
System boundary
Requirements specification,
functional reqs, unstructured text
• Survey data will be stored in the database at
the end of the survey, and a report will be
sent to the printer.
• The system will provide screens for adding,
editing, and deactivating counselee and
counselor records from a database.
Requirements specification: written from system’s viewpoint, involving internal details of system
Requirements specification,
non-functional reqs, with fit criteria
• 95% of the code will be platform-independent
(Java or platform-independent JavaScript).
• The system will record completed surveys in
the database within 30 seconds; reports will
be sent to the printer within 30 seconds and
emerge within 60 seconds.
Requirements specification: written from system’s viewpoint, involving internal details of system
Dataflow diagram
(note: only shows UC#1)
Last name
& PIN
Counselee
Authent
icate
User ID
Health
Information
Pick up
Survey
Printout
Printout
Counselor
Printer
Survey
answers
Postscript
Survey DB
All this
patient’s
answers (ever)
Create
report
Message sequence diagram
UC#1
Counselee
Server
Database
Log in
Present question
Answer question
[survey complete]
Record answers
Get report data
Send report to printer
Printer
A few general comments
• These are just the basic diagrams.
– Sufficient for our homework, exams, and probably
90% of what you’ll see after graduation
– Fancier versions of these diagrams do exist
• It’s OK to draw diagrams by hand
– As long as you respect the notation
– And, at least for homework, scan it into a PDF
What’s next for you?
• Get organized tomorrow in teams to design
use cases and then design your paper
prototypes based on the functional
requirements you had made a note of.
• Design gallery (Friday): It would be a display of
your designs and each one of you should
compulsorily give feedback to the other team
(two ideas/feedback per person).