Lecture 4

Use Cases and prototyping

Reading:
Writing Effective Use Cases, A. Cockburn (alistair.cockburn.us/get/2465) – MUST
READ (Examples)
http://www.cragsystems.co.uk/use_case_tutorial/ == Recommended
Ian Summorvillie, Software Engineering, Chapter 4 (Further Reading)
 Outline
• What is a use case?

• Terminology

• Styles of use cases

• Steps for creating a use case

• User interface Prototyping

2
 Functional Req
– Functional Requirement is a verb, while Non-
Functional Requirement is an attribute
– transaction corrections, adjustments, and
cancellations
– Reporting Requirements
– Administrative functions, Authorization levels, Audit
Tracking,
– External Interfaces, Historical Data management,
Legal or Regulatory Requirements are various types
of functional requirements.

3
 Non Functional Req
Basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

4
 Use cases
• Functional Requirements
– Tell us what the user will do with the system.
– Not enough details for developers
– Need a way to describe the sequence of interactions
to accomplish a functional requirement.
• use case: a written description of the user's
interaction with the software product to
accomplish a goal
– It is an example behavior of the system.
• clearly written steps lead to a "main success scenario"
• written from actor's point of view, not the system's

• Use cases capture functional requirements

– Not necessary one to one mapping between them
5
 Benefits of doing use
cases?
• Establish an understanding between the customer and
the system developers of the detailed requirement
– success scenarios

• Alert developers of problematic situations, error cases

to test
– extension scenarios

• Capture a level of functionality to plan around

– list of goals

6
 Qualities of a good use
case
• Focuses on interaction
– Starts with a request from an actor to the system.
– Ends with the production of all the answers to the
request.

• Focuses on essential behaviors, from the actor’s point

of view
– Does not describe internal system activities.
– Does not describe the GUI in detail.

• Concise, clear, accessible to non-programmers

– Easy to read.
– Summary fits on a page.
– Main success scenario and extensions. 7
 Use cases vs. internal
features
:

Use Cases Internal Functions

• call someone • transmit / receive data
• receive a call • energy (battery)
• send a message • user I/O (display,
• memorize a number keys, ...)
• phone-book mgmt.
Point of view: user
Point of view: developer /
designer

8
 Use cases and
requirements
• Which of these requirements would probably be
represented or mentioned directly in a use case?
1. Special deals may not run longer than 6 months.
2. Customers only become preferred after 1 year.
3. A customer has one and only one sales contact.
4. Database response time is less than 2 seconds.
5. Web site uptime requirement is 99.8%.
6. Number of simultaneous users will be 200 max.

• Answer: None!
– Most of these are non-functional requirements, so the use
cases wouldn't mention them.
– The user doesn't see them directly.
9
 Terminology
• actor: an entity that acts on the system
– primary actor: initiates interaction to achieve goal
– supporting actor: performs sub-goals in use case

• goal: action that actor wants to accomplish

– user ( E.g register device) – MOST IMPORTANT
– summary ( E.g configure users in system),
– subfunction (E.g logging in, locate device in DB)

• stakeholder: anyone interested in the system

– supplier, stock agency, vendor
– stakeholder might not "act" in any scenario

Use cases are always initiated by actors and describe

the flow of events that these actors are involved in.
10
 Terminology
• Actor can be a human being or another system
– External system – E.g billing system needs to get the
courses a student registered to from registration system
– Human – a student, teacher, registrar

• An actor is not a person but a role played by a person

or an external system.
– E.g the same person can be a student or an instructor.

11
 Styles of use cases
1. Use case diagram
– shows all use cases in system
– In UML (Unified Modelling Language – a famous design
language)

2. Informal use case

 a short paragraph

3. Formal use case

 a multi-part structured description

Let's examine each of these in detail...

12
 1. Use case diagram
• The overall list of the system's use cases can be drawn
as high-level diagrams, with:
– actors as stick-men, with their names (nouns)
– use cases as ellipses, with their names (verb phrases)
– line associations, connecting an actor to a use case in
which that actor participates
– use cases can be connected to other cases that they use /
rely on
• E.g Check out book depends on login

13
 Actor-goal lists: function
content of the system
Actor Goal
Library Patron Search for a book It can be useful to
Check out a book create a list or table
of primary actors and
Return a book
their "goals" (use
Librarian Search for a book cases they start).
Check availability
Request a book from The diagram will
another library then capture this
material

14
Use case summary
diagrams

15
 <<includes>>
relationship

Validate Use case may be used in other contexts

• <<includes>> (aka<<uses>>) relationship used for
events that are in the flow of events of the source use case.
• << >> are called stereotypes in UML
16
 <<extends>>
Relationship

<<extend>>used for exceptional conditions,

especially those that can occur at any time.
• E.g Request Laboratory Test case may be performed after
Reviewing Patient’s Case
17
Use case summary
diagram

18
 2. Informal use case
• informal use case: a paragraph describing the
scenario
• Example (for a library management system):

– Patron loses a book

– The library patron reports to the librarian that she has
lost a book. The librarian prints out the library record
and asks patron to speak with the head librarian, who will
arrange for the patron to pay a fee. The system will be
updated to reflect lost book, and patron's record is
updated as well. The head librarian may authorize
purchase of a replacement book

19
 Informal use case with
structured text
• I
– I.A
• I.A.ii You will probably use
– I.A.ii.3 something in this
» I.A.ii.3.q general style.

Although not ideal, it is almost always

better than unstructured natural language

20
 What is an extension?
• A possible branch in a use case scenario, often
triggered by an error or failure in the process.
– Useful for finding edge cases that need to be handled and
tested.
• Do
– Think about how every step of the use case could fail.
– Give a plausible response to each extension from the
system.
– Response should either jump to another step of the case,
or end it.
• Don’t
– List things outside the use case ("User's power goes out").
– Make unreasonable assumptions ("DB will never fail").
– List a remedy that your system can't actually implement.21
 Formal Use case

Parts that make up a formal use case

(continued on the next slide).
22
Formal Use case

23
 3. Formal use case
(goal of primary actor) (level of goal [summary, user, subfunction])
(primary actor)
"Place an order" (User goal / Clerk)
(action steps:
full sentences showing
Main scenario: who takes the action!
1. Clerk specifies customer, item and3quantity.
- 9 steps long.)
2. System accepts and queues the order.
...
(condition causing different actions)
Extensions: (action step(s)
1a. Low credit & Customer is 'Preferred':
handling those conditions)
1a1. System gives them credit anyway.
1b. Low credit & not 'Preferred' customer:
1b1. Clerk performs Sign Up Preferred
Customer scenario and accepts only prepayment.
2a. Low on stock: Customer accepts rain-check:
(calling another use case)
2a1. Clerk reduces order to available stock
level. 24
 Use case exercise
• Consider a Netflix-like video rental web system.
– A customer with an account can use their membership
and credit card in the web app to order a video for rental.
– The software can look up movies and actors by keywords.
– A customer can check out up to 3 movies, for 5 days
each.
– Late fees can be paid at the time of return or at next
checkout.

• Exercise:
– Come up with 3-4 use case names for this software.
– Identify some of the actors and stakeholders in this
system.
25
Solution

26
 What notation is good?
• There are standard templates for requirements
documents, diagrams, etc. with specific rules.
• Is this a good thing? Should we use these standards or
make up our own?
– Standards are helpful as a template or starting point.
– But don't be a slave to formal rules or use a
model/scheme that doesn't fit your project's needs.

27
 Cockburn's 4 use case
steps
1. Identify actors and goals
– What computers, subsystems, people
will drive our system? (actors)
– What does each actor need our
system to do? (goals)

2. Write the main success scenario

– easiest to read; everything else is a
complication on this
– capture each actor's intent and
responsibility
• say what information passes between
them
• number each line

28
 Cockburn's 4 use case
steps
3. List the failure extensions
– usually almost every step can fail (bad credit, out of
stock...)
• note failure condition separately, after main success
scenario
– Describe failure-handling
• recoverable: back to main course (low stock + reduce
quantity)
• non-recoverable: fails (out of stock, or not a valued
customer)
• each scenario goes from trigger to completion
– Label with step number and letter:
• 5a failure condition
– 5a.1 use case continued with failure scenario
– 5a.2 continued
29
 Cockburn's 4 use case
steps
• 4. List the variations
– Many steps can have alternative behaviors or scenarios
– Label with step number and alternative
• 5’. Alternative 1 for step 5
• 5’’. Alternative 2 for step 5

30
 Usability
• Usability: The effectiveness with which users can
accomplish tasks in a (software) system, as measured
by:
– Learnability: is it easy to learn?
– Efficiency: once learned, is it fast to use?
– Safety: are errors few and recoverable?

• Importance criteria – Learnability, Efficiency, or safety

– Depends on the user
• Novices need learnability.
• Experts need efficiency.
• But no user is uniformly a novice or an expert.
– Depends on the task
• Missile launchers need safety.
31
•
 Usability Matters: the cost of
getting it wrong
50% of all
“malfunctioning”
electronic devices
returned to stores are
in full working order,
but users can't figure
out how to operate
them.

• Elke den Ouden, 2006

Three Mile Island:
nuclear reactor meltdown
• You can read further
for detail information.
caused by an ambiguous
user interface 32
 A good user interface is hard
to design ...
• You are not the user
– Most software engineering is about communicating with
other programmers.
– UI is about communicating with users.

• Users are always right ...

– Consistent problems are the system’s fault.

• Except when they aren’t

– Users don’t always know what they want.

33
 Achieving usability: Best
practices
• some methods to achieve good usability:
– user testing / field studies
• having users use the product and gathering data

– evaluations and reviews by UI experts

– prototyping
• paper prototyping
• code prototyping

• Good UI design focuses on the user, not developer or

system.

34
 User Interface:
Prototyping
• prototyping: Creating a scaled-down or incomplete
version of a system to demonstrate or test its aspects.

• What are some possible benefits of prototyping?

– aids UI design
– help discover additional requirements
– help discover test cases and provide a basis for testing
– allows interaction with user and customer to ensure
satisfaction
– team-building

35
Types of Prototyping

36
 Some prototyping
methods
• UI builders
• draw a GUI visually by dragging/dropping UI controls on
screen
• Code prototyping
– Writing a "rough" version of your code

• paper prototyping: a paper version of a UI

37
 Why paper prototyping?
• Question: Why not just code up a working
code prototype?
– much faster to create and change than
code
– more visual bandwidth (can see more at
once)
– more conducive to working in teams
– can be done by non-technical people

38
 When to do (paper)
prototyping?
• Question. Requirements are the what and
design is the how. Which is paper prototyping?

• Answer. Prototyping
– helps uncover requirements and upcoming
design issues
– during or after requirements but before design
– shows us what is in the UI, but also shows us
details of how the user can achieve goals in
the UI
– Included as a requirements artifact to initially envision the
system

39
 Paper prototype usability
testing
• user is given tasks to perform using paper prototype
• Facilitator guides the user through tasks, prompting for
feedback.
• session can be observed by people or camera
• one developer can "play computer"

“Computer” Facilitator

Observer(s)

User

40
 Schneiderman's 8 Golden
Rules
• Strive for consistency. • Offer simple error
• Give shortcuts to expert handling.
user. • Permit easy undo of
• Offer informative actions.
feedback. • Let the user be in control.
• Make each interaction • Reduce short-term
with the user yield a memory load on the user.
result.

p://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.h
41
Bad error messages

42
 UI Hall of Fame
Reading Assignment :
• Read about UI hall of fame/shame

43
 UI design: components
• When to use:
– A button?
– A check box?
– A radio button?
– A text field?
– A list?
– A combo box?
– A menu?
– A dialog box?
– Other..?

44
 UI design - buttons, toolbars,
menus
• Use buttons for single independent actions that are
relevant to the current screen.
– Use button text with verb phrases such as
"Save" or "Cancel", not generic: "OK", "Yes",
"No"
– use Mnemonics or Accelerators (Ctrl-S)

• Use toolbars for common actions.

• Use menus for infrequent actions

applicable to many screens.
– Users hate menus! Try not to rely
too much on menus. Provide
another way to access the same
functionality (toolbar, hotkey, etc)
45
 Checkboxes, radio
buttons
• Use check boxes for independent on/off switches
• Use radio buttons for a small number of related
choices, when only one can be activated at a time

46
 Lists, combo boxes, etc.
• use text fields (usually with a label)
when the user may type in anything
they want
– you will usually have to validate the
input

• use lists when there are many fixed

choices (too many for radio buttons to
be practical) and you want all choices
visible at once

• use combo boxes when there are many

fixed choices, but you don't want to take
up screen space by showing them all at
once
47
 UI design - multiple
screens
• you can use a tabbed pane when
there are many screens that the
user may want to switch between at
any moment
– or multiple pages, if it's a web site

• use dialog boxes or option panes

to present temporary screens or
options
– users hate popup dialogs; use them
very rarely
– don't prompt for lots of user input by
popping up dialogs
• instead, put the choices on the
48
existing
 An example UI
• Did the designer of this UI choose the right
components?
– assume there are 30 collections and 3 ways to search
(by title, author, relevancy)
LIBSYS: Search

Choose collection: All

Phrase:

Search by: Title

Adjacent words Yes No

Default
Cancel
OK

49
 Creating a paper
prototype
• gather materials
– paper, pencils/pens
– tape, scissors
– highlighters, transparencies

• identify the screens in your UI

– consider use cases, inputs and outputs to user

• think about how to get from one screen to next

– this will help choose between tabs, dialogs, etc.

50
 Application backgrounds
• draw the app background (the parts that matter for the
prototyping) on its own, then lay the various
subscreens on top

51
 Interactive widgets
widget how to simulate it
buttons or check tape
boxes
tabs and dialog index cards or small
boxes papers
text fields removable tape
combo boxes put the expanded
choices on a separate
paper / Post-It
selections highlighted piece of tape
a disabled widget cut out a separate gray
version that can be
placed on top of the
normal one

52
Example paper prot.
screen

53
 Summary
• Uses case describe example system behaviors
(contracts) from the user’s point of view.

• Can be diagrams, informal paragraphs, formal use

cases.

• 4 steps to create use cases

54
• Tasks
1, Finishing up functional and non functional requirement
2, develop use case for your specific system on paper
3, sketch your user interface.

55