Use Cases

Supplemental Lecture for

Chapter 2 of Xiaoping Jia
OOSD using Java

NJIT
1
 Define the Problem

 The most critical question:

 “Is this the right system to make?”

2
 Use Case Relationships
Business Model
Domain Model
Objects, attributes, associations

VISION

Use Case Model GLOSSARY

SUPPLEMENTARY
Requirements SPECIFICATION

Interaction Diagrams
Design

3
 Use Cases are not Diagrams
 Use Cases may have a diagram associated
with them, and a use case diagram is an
easy way for an analyst to discuss a
process with a subject matter expert (SME).
 But use cases are primarily text. The text is
important. The diagram is optional.

4
 Emphasize Goals
 Investigating goals rather than tasks and
procedures improves information gathering
by focusing on the essence of requirements
—the intent behind them.
 Seeing requirements as identifying tasks to
be done has a strong bias toward
reproducing the existing system, even when
it is being replaced because it is seriously
defective.
5
 Why Use Cases?
 Simple and familiar storytelling makes it
easier, especially for customers, to
contribute and review goals.
 Use cases keep it simple (KISS)
 They emphasize goals and the user
perspective.
 New use case writers tend to take them too
seriously.

6
 Actors or Use Case First?
 Because you have to understand each part of
Use Cases, the parts are presented separately.
But those who create use cases switch back and
forth. The text describes use cases substantially
before paying attention to actors. Typically, both
actors and use cases are identified early and
then examined to see if more use cases can be
found from the actors, or more actors found by
examining the use cases.

7
 Identify Use Cases

 Capture the specific ways of using the

system as dialogues between an actor
and the system.
 Use cases are used to
 Capture system requirements
 Communicate with end users and Subject
Matter Experts
 Test the system
8
 Specifying Use Cases
 Create a written document for each Use Case
 Clearly define intent of the Use Case

 Define Main Success Scenario (Happy Path)

 Define any alternate action paths

 Use format of Stimulus: Response

 Each specification must be testable

 Write from actor’s perspective, in actor’s

vocabulary

9
 www.usecases.org Template
 Name
 This is the basic format used
 Primary Actor
in the text and in Alistair
Cockburn’s Writing Effective
 Scope
Use Cases (Addison Wesley,
 Level 2000, ISBN 0201702258).
 Stakeholders and
Interests
 I prefer to modify it slightly to
use the actor actions and
 Minimal Guarantee
system response in tabular
 Success Guarantee form. Larman calls this the
 Main Success Scenario Two-Column Variation.
 Extensions

10
 Optional Items
 You can add some of the following items
 Trigger (after Success Guarantee)

 (at end:)
 Special requirements

 Technology and Data Variations

 Frequency of Occurrence

 Open Issues

11
 SAMPLE:
Fully
Dressed
Use
Case

12
 Elements in the Preface
 Only put items that are important to
understand before reading the Main
Success Scenario. These might include:
 Name (Always needed for identification)
 Primary Actor
 Stakeholders and Interests List
 Preconditions
 Success Conditions (Post Conditions)

13
 Naming Use Cases
 Must be a complete process from the
viewpoint of the end user.
 Usually in verb-object form, like Buy Pizza
 Use enough detail to make it specific
 Use active voice, not passive
 From viewpoint of the actor, not the
system

14
Hint
 Appropriate use case names are very important.
Because they are selected early, they tend to set
the direction for the entire project.
 Most common errors in use case diagrams are
poor names, showing procedures instead of
complete user processes, and not including the
boundary and system name.
 Rational Rose does not show the boundary and
name, so assignments turned in using that tool do
not have to have them. Rational Rose is preferred
for assignments.
15
 Golden Rule of Use-Case
Names
 Each use case should have a name that
indicates what value (or goal) is achieved by
the actor's interaction with the system
 Here are some good questions to help you
adhere to this rule:
 Why would the actor initiate this interaction

with the system?

What goal does the actor have in mind when
undertaking these actions?
What value is achieved and for which actor?
From Dr. Use Case (Leslee Probasco) in the Rational Edge, March, 2001
16
 Use Case Name Examples
 Excellent - Purchase Concert Ticket
 Very Good - Purchase Concert Tickets
 Good - Purchase Ticket (insufficient detail)
 Fair - Ticket Purchase (passive)
 Poor - Ticket Order (system view, not user)
 Unacceptable - Pay for Ticket (procedure,
not process)

17
 CRUD
 Examples of bad use case names with the
acronym CRUD. (All are procedural and
reveal nothing about the actor’s
intentions.)
 C - actor Creates data
 R - actor Retrieves data
 U - actor Updates data
 D - actor Deletes data

18
 Singular or Plural
 This is usually determined by context.
 There is a preference for the simplest form, but
most common form can be better.
 In the example of concert tickets, most people
buy more than one, but a significant number buy
only one.
 At a supermarket, Buy Items would be best.
 At a vending machine, it would be Buy Item.

19
 Identify Actors

 We cannot understand a system until we

know who will use it
 Direct users
 Users responsible to operate and maintain it
 External systems used by the system
 External systems that interact with the system

20
 Specifying Actors
 Actors are external to the system
 Actors are non-deterministic
 What interacts with the system?
 Actors may be different roles that one
individual user interacts with the system
 Actors may be other systems
 Don’t assume that Actor = Individual

21
 Types of Actors
 Primary Actor
 Has goals to be fulfilled by system
 Supporting Actor
 Provides service to the system
 Offstage Actor
 Interested in the behavior, but no contribution
 In diagrams, Primary actors go on the left and
others on the right.

22
 Define Actors
 Actors should not be analyzed or described in detail
unless the application domain demands it.
 Template for definition:

 Name

 Definition

 Example for an ATM application:

Customer: Owner of an account who manages account by

depositing and withdrawing funds

23
 Identifying Actors
 Primary Actor
 Emphasis is on the primary actor for the

use case.
 Stakeholders and Interests
 Other actors are listed as stakeholders.

 The interests of each key actor should

be described.

24
 Working with Use Cases
 Determine the actors that will interact with
the system
 Examine the actors and document their
needs
 For each separate need, create a use
case
 During Analysis, extend use cases with
interaction diagrams

25
 Preconditions
 Anything that must always be true before
beginning a scenario is a precondition.
 Preconditions are assumed to be true, not
tested within the Use Case itself.
 Ignore obvious preconditions such as the
power being turned on. Only document
items necessary to understand the Use
Case.

26
 Success Guarantees
 Success Guarantees (or Postconditions)
state what must be true if the Use Case is
completed successfully. This may include
the main success scenario and some
alternative paths. For example, if the happy
path is a cash sale, a credit sale might also
be regarded a success.
 Stakeholders should agree on the guarantee.

27
 Scenarios
 The Main Success Scenario, or “happy
path” is the expected primary use of the
system, without problems or exceptions.
 Alternative Scenarios or Extensions are
used to document other common paths
through the system and error handling or
exceptions.

28
 Documenting the Happy Path
 The Success Scenario (or basic course) gives the best
understanding of the use case
 Each step contains the activities and inputs of the actor and
the system response
 If there are three or more items, create a list

 Label steps for configuration management and requirements

traceability
 Use present tense and active voice

 Remember that User Interface designers will use this

specification
Note: Do not use the term “happy path” in formal documents.
29
Extensions (Alternative Flows)

 Extensions or Alternative Flow Use Cases

allow the specification of
 Different ways of handling transactions

 Error processes

 Sections are convenient way to handle

alternative courses of action
 Sections are a segment of a use case
executed out of sequence

30
 Two Parts for Extensions
 Condition
 Describe the reason for the alternative
flow as a condition that the user can
detect
 Handling
 Describe the flow of processing in the
same manner as the happy path, using
a numbering system consistent with the
original section.
31
Documenting Extensions
 Use same format as Happy Path
 Document actions that vary from ideal path
 Include error conditions
 Number each alternate, and start with the
condition:
3A. Condition: If [actor] performs [action] the system …
 If subsequent steps are the same as the happy
path, identify and label as (same)
 Steps not included in alternate course are
assumed not to be performed.
32
 Special Requirements
 If a non-functional requirement , quality
attribute, or constraint affects a use case
directly, describe it as a special
requirement.

33
 Types of Use Cases
 The most common Use Cases are High
Level Use Cases and Expanded Essential
Use Cases in analysis, and Expanded
Real Use Cases in design. The next slide
gives definitions.
 In addition, Use Case diagrams may be
used in discussions with stakeholders
while capturing their requirements.

34
 Elaborating Use Cases
 High Level Use Case (Brief)
 Name, Actors, Purpose, Overview

 Expanded Use Case (Fully Dressed)

 Add System Events and System Responses

 Essential Use Case (Black Box)

 Leave out technological implications

 Real Use Case (White Box)

 Leave in technology

35
 Expanded Essential Use Cases
(Fully Dressed Use Cases)
 Purpose:
 to allow the system designer and client to visualize the flow of actor

actions and system responses. From this the client will understand
how users will use the system, and the designer will be able to write
pseudocode for each function. In addition, it is possible to use this
document to anticipate opportunities for user error, which must be
accounted for in the final system.
 Definitions:
 What it is: an analysis document which describes in detail the

elements of functions identified in a High Level Use Case.

 What is is not: Expanded Essential Use Cases are not graphical

drawings. They do not include stick figures, boxes representing the

system, or any other icons found in a High Level Use Case although
they may be associated with one.

36
 Expanded Essential
Use Cases
 How to make one:
 Step 1: Name the Use Case (system function, e.g. “enter

timesheet information”).
 Step 2: Identify the Actor(s) involved.

 Step 3: Describe the Intent of the Use Case in language the client

will understand.
 Step 4: Identify the Assumptions and Limitations relevant to this

Use Case and other Use Cases which the current one might
extend or build upon.
 Step 5: Specify the ideal flow of actions using two columns

labeled “Actor Actions” and “System Responses.” Number each

step. This constitutes the Happy Path for this Use Case.
 Step 6: Identify opportunities for user error and create an

Alternative Path to handle each.

37
 Postconditions
 Postconditions (or success guarantees)
state what always must be true for a use
case to succeed. Avoid the obvious, but
clearly document any that are not obvious.
This is one of the most important parts of
a use case.

38
 Conditions and Branching
 Stick to the “Happy Path,” “Sunny Day
Scenario,” Typical Flow, or Basic Flow (all
names for the same basic idea) in the
main section and defer all conditional
sections and branching to the extensions
or alternate flows.

39
 Warning
 Use cases should not be misused to imitate
function specification by successive iteration
 Don’t refine them until the program is fully
specified
 The uses relation should only be used when
the same scenario is encountered more
than once

40
 Use Cases not an OO idea
 Use Cases are not an Object-Oriented
methodology. They are common in
structured development as well.
 However, the Unified Process encourages
use-case driven development.

41
 Use case levels
 User-goal level
 A complete process from the view point of a
user to meet a goal of the user, roughly
corresponding to an elementary business
process.
 Subfunction level
 Details steps to support a user goal.

42
 Use-case driven development
 Requirements are primarily recorded in
the Use Case model.
 Iterations are planned around
implementing particular Use Cases.
 Use Case Realizations drive design.
 Use Case often influence the way user
manuals are organized.

43
Use Cases are always wrong!

 Written documentation gives the illusion of

authority and correctness, but it is an illusion.
 Use cases give a preliminary understanding that
users and developers can discuss and agree on.
 But there should be constant feedback from
customers in the development process to correct
missing information and misinformation before it
jeopardizes the functionality of the program.

44
 Bibliography
 http://members.aol.com/acockburn/papers
/AltIntro.htm
 http://www.agilemodeling.com/artifacts/us
eCaseDiagram.htm

45