http://www.flickr.com/photos/21218849@N03/3901372331/sizes/l/

PaperPrototyping

• 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.

Customers and users should be your friends

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 risksin 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

• 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

Design

Implementation

Operation

Testing

Prototyping

Spiral kinds of processes

Draft a menu ofrequirements

EstablishrequirementsPlan

Analyze risk &prototype

Draft a menu ofarchitecture designs

Analyze risk &prototype

Analyze risk &prototype

Draft a menu ofprogram designs

Establisharchitecture

Establishprogram design

ImplementationTestingOperation

Plan

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 systemHere 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 systemHere’s a panhandler report state chart

New(just reported)

Claimed(by volunteer)

Done(visited by volunteer)

Report status

claim unclaim

mark donesucceeds

“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 city2. User enters information

about the panhandler3. System validates inputs4. 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 claimed4. Volunteer visits the panhandler5. 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 claimed4. Volunteer visits the panhandler5. 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 theprototype 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

http://www.flickr.com/photos/juhansonin/347137175/sizes/o/

Promoting health awareness with a“know your numbers” card & system

http://www.flickr.com/photos/sstorari/3671284171/sizes/o/

Prototype splash-screen for Anaconda, an installer framework for Linux

http://www.flickr.com/photos/ben30/2866006814/sizes/o/

Prototype of what an iPod might look like with a 320x480 resolution

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 Enterpriseall 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: showsactivities supported by the system

Repressed citizen

Concerned public

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: showsentities, attributes, relationships

User+ Twitter username

Repression report+ source (tweet)+ location (geocode)+ when (datetime)+ details (string)

*

*

Repression view+ reports*

Google map view+ JavaScript

RSS View+ XML text

Repression tweet+ user+ when (datetime)+ text (string)

1

*

0..1

1

System boundary

Clarification tweet+ report+ when (datetime)+ text (string)

*

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: showsentities, attributes, relationships

User Twitter username

Repression report source (tweet) location (geocode) when (datetime) details (string)

Clarification tweet report when (datetime) text (string)

Repression view reports

1

0..1r

s

p

q

Google map view JavaScript

RSS View XML text

yields

shows

asks about

Repression tweet user when (datetime) text (string)

writes

1

n

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: showsflow of information

Reporter

Viewing user

ReportTwitter DB

Send clar req

Reports DB

Inter-pret Clarify

Geocoder

RSS View

RepressionRepressioninfoinfo TweetTweet

TweetTweet

GeocodeGeocode

LocationLocation RawRawreportreport

ClarificationClarificationmessagemessage

TweetTweetClarificationClarification

messagemessage

ReportReportReportsReports

RSS feedRSS feed

Map View

MapMap

ReportsReports

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

[geocode != null]

Message sequence diagram: showsflow of control

User Twitter System Database

Tweet eventRead tweets

Request to clarify[if geocode == null]Deliver request

Geocoder

Geocode

Create report[if geocode != null]

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: showschange over time

Raw (just text)

In database(geocode == null)

Geocoded(geocode != null)

Report status

record geocoding fails & user retweets

geocodingsucceeds

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

http://cf.polarishealth.com/demo/start_demo.html

An example system to support drug and alcohol counseling

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

Counselor+ reports

Counselee+ counselor+ surveys

Survey+ questions (String [])+ answers (int [])+ counselee

1

*

User+ lastname (string)+ PIN (int)

1

*

Report+ surveys+ counselor

**

1

*

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)

Survey DB

Survey

SurveySurveyanswersanswers

HealthHealthInformationInformation

All thisAll thispatient’spatient’s

answers (ever)answers (ever)

Counselee

Counselor

Create report

PostscriptPostscriptPrinterPick up PrintoutPrintout

PrintoutPrintout

Authenticate

User IDUser ID

Last nameLast name & PIN & PIN

Message sequence diagramUC#1

[survey complete]

Counselee Server Database

Log in

Printer

Present question

Answer question

Record answers

Get report data

Send report to 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).