Use Case Description
Supplementary material to support
Bennett, McRobb and Farmer:
Object Oriented Systems Analysis and
Design Using UML, (4th Edition),
McGraw Hill, 2010.
© 2010 Bennett, McRobb and Farmer
1
In This Presentation You Will Learn:
• What is a Use Case Description
• The difference between essential and real
use cases
• How to describe Use Cases informally as
a step-by-step sequence of actions
• How to apply Cockburn’s template for
formal Use Case Descriptions
© 2010 Bennett, McRobb and Farmer
2
What is a Use Case
Description?
• A Use Case Diagram gives an overall view:
– Of a system’s functionality (use cases)
– How functions relate to each other at run-time
(«extends» and «includes» relationships)
– How user roles (actors) interact with functions
• Use Case Diagrams do not show:
– Sequence or iteration of inputs and outputs while a
use case executes
– Alternative courses of action dependent on conditions
– Pre-conditions for a use case to commence execution
– Other meta-data about the use case
© 2010 Bennett, McRobb and Farmer
3
What is a Use Case
Description?
• A Use Case Description addresses these
limitations of the diagram
• There are several ways to document a
Use Case Description, ranging from very
informal to very formal
• Most organizations will have their own
style and standard, often based on
Cockburn’s (2001) template
© 2010 Bennett, McRobb and Farmer
4
Essential and Real Use Cases
• Some authors distinguish between
essential and real use cases
• An essential use case is quite abstract,
and makes no reference to design or
technology aspects
• A real use case is implementationoriented, referring to specific technologies
(e.g. interface widgets, hardware devices,
etc)
• For this presentation, we will focus mainly
on essential use case descriptions
© 2010 Bennett, McRobb and Farmer
5
Informal Step by Step Descriptions
• It is often useful to describe a use case
simply as a sequence of I/O:
– User inputs something
– System outputs something
– User inputs something else
– System outputs something else
• Very easy to confirm with users
• Also gives developers lots of clues about
data, processing and screen content
© 2010 Bennett, McRobb and Farmer
6
Example #1: ‘Buy product’
Buy product
online
Customer
(this example is adapted from Fowler, 2003)
© 2010 Bennett, McRobb and Farmer
7
Imagine the Scenario
• If you buy something from a website, you
probably:
– Browse through several products
– Choose one
– Go to the checkout
– Fill in some information
– Get confirmation of the sale
© 2010 Bennett, McRobb and Farmer
8
Main Scenario: ‘Buy product’
• Informal description:
Buy product online
1. Customer browses catalogue
2. System displays product details
3. Customer selects item to buy, goes to check-out
4. System displays shopping cart page
5. Customer fills in delivery information
6. System shows full pricing, including shipping
7. Customer fills in credit card details
8. System authorizes card, confirms sale on screen and
sends email to customer
(Note that ‘Shopping cart’ and ‘email’ are real aspects of this
use case, while the rest of the description is essential)
© 2010 Bennett, McRobb and Farmer
9
Optional Steps
• Description also covers any alternative
courses, and the triggers that initiate their
execution:
Alternative course: Card fails to authorize
• At step 8, system fails to authorize credit purchase.
• Return to step 7, allow customer to re-enter credit card
information, retry authorization.
© 2010 Bennett, McRobb and Farmer
10
What the Description tells us:
• Even an informal description gives a lot of
information that is useful to the developer:
– Sequence and any iteration of steps – what
order things should happen
– I/O – fields, text boxes, buttons, etc needed
on the screen
– Data – what must be stored or retrieved
– Process – calculations, other steps that will
need coding
– Alternatives – branch points in the sequence
© 2010 Bennett, McRobb and Farmer
11
Example #2: Training
Administration System
Book course
place
Admin clerk
(this example is adapted from Skidmore and Eva, 2004)
© 2010 Bennett, McRobb and Farmer
12
Main scenario: ‘Book course place’
Book course place
1. Admin clerk retrieves scheduled course details
2. System displays number of places free
3. Admin clerk chooses ‘add delegate to a course’
4. System requests delegate details
5. Admin clerk enters delegate details
6. System stores details and confirms
© 2010 Bennett, McRobb and Farmer
13
Alternate course: no free places
1. Admin clerk retrieves scheduled course
details
2a. System displays ‘no places free’
2a1. Admin clerk selects ‘search for dates with
free places’
2a2. Systems displays dates with free places
2a3. Admin clerk selects date
(back to main course, step 4)
© 2010 Bennett, McRobb and Farmer
14
Alternate course: details missing
4. System requests delegate details
5a. Admin clerk enters details that are
known
5a1. Systems displays ‘reservation is
conditional on full details – OK?’
5a2. Admin clerk clicks OK
(back to main course, step 6)
© 2010 Bennett, McRobb and Farmer
15
Formal Descriptions: Cockburn’s
Template
• The usual basis for formal use case descriptions, this is
divided into five main sections:
– Characteristic Information: a summary of the
purpose and context of the use case
– Description: Main Success Scenario, Extensions and
‘Technology and Data Variations List’
– (Optional) Related Information: non-functional
aspects, links to other use cases, etc.
– (Optional) Open Issues: unresolved issues still to be
addressed
– Schedule (for development)
© 2010 Bennett, McRobb and Farmer
16
Characteristic Information in detail
• Goal in Context: what is this use case for?
• Scope: the system (or systems) within which this use
case applies
• Level: is this use case primary - called directly by the
actor?
• Preconditions: what should be true for the use case to
execute?
• Success End Condition: what should have changed
after it has executed?
• Minimal Guarantee: what should minimally occur even if
the use case fails to achieve its main goal
• Primary Actor: self explanatory
• Trigger: what event causes execution to begin?
© 2010 Bennett, McRobb and Farmer
17
Description in detail
• Main Success Scenario: the steps of the scenario from
trigger to success, including any final closing down (e.g.
interfaces or database connections)
• Extensions: alternate courses are described here, also
any calls to other «includes» or «extends» use cases
• Technology and Data Variations List: describes
alternative ways that the use case might be
implemented, e.g. to allow for different UI devices (say,
touch screen vs keyboard and mouse interface)
© 2010 Bennett, McRobb and Farmer
18
Related Information (optional)
• Priority: how important is this use case to the project?
• Performance Target: how quickly must the system
respond to input or complete execution?
• Frequency: how often will it need to execute?
• Subordinate Use Cases: other use cases on which this
one depends for its success
• Channel to primary actor: how will the actor
communicate with the use case?
• Secondary Actors: other actors who can initiate and
execute the use case
• Channel to Secondary Actors: as above
© 2010 Bennett, McRobb and Farmer
19
Open Issues and Schedule
• Any unresolved questions should be
described in enough detail for another
developer to work on them later
• If the development schedule for this use
case has been decided, it should be
documented
© 2010 Bennett, McRobb and Farmer
20
Summary
In this presentation you have learned :
• What a Use Case Description is
• What is the difference between essential
and real use cases
• How to describe Use Cases informally as
a step-by-step sequence of actions
• How to apply Cockburn’s template for
formal Use Case Descriptions
© 2010 Bennett, McRobb and Farmer
21
References
• Fowler (2003)
• Skidmore and Eva (2004)
• Cockburn (2001)
(For full bibliographic details, see
Bennett, McRobb and Farmer)
© 2010 Bennett, McRobb and Farmer
22