Use Cases

This page, part of a series on UML, describes what Use Cases are and how to use them to develop and test applications.

Topics this page:

Use Case Diagrams

Site Map
About this site

References:

$60 Object-Oriented Software Engineering: A Use-Case Driven Approach, by Ivar Jacobson, et al. Addison-Wesley, Reading, MA, 1992. 524 pages

$45 The Object Advantage: business process engineering with object technology, by Jacobson, I., Ericsson, M. and Jacobson, A. Addison-Wesley, May 2001. Applies object-oriented technology to the business process engineering (BPR) model.

$35 Writing Effective Use Cases by Alistair Cockburn (name pronounced "Coburn") of usecases.org. Addison-Wesley, Oct. 2000. 270 pages.

$32 Practical Software Requirements (Manning Publications October 1, 1998) by Benjamin L. Kovitz gives a structure.

Software Requirements, 2nd edition (Microsoft Press February 26, 2003) by Karl E. Wiegers presents a jargon-free introduction to the best practices in requirements discovery, verification and validation.
First Edition (Microsoft Press August 26, 1999)

$36 Mastering the Requirements Process (Addison-Wesley August 12, 1999) by Suzanne & James Robertson

$45 Effective Requirements Practices (Addison-Wesley arch 8, 2001) by Ralph R. Young

$35 Software Requirements (Addison-Wesley, January 16, 2002) by Soren Lauesen

Visual-paradigm's Online Tutorial

UML Use Case diagram of the RUP Testing Discipline

Use cases define the context of a system. Use cases identify the intent satisfying the role assumed by external “actors" interacting with the “system under discussion/test”. A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance to satisfy a goal.

Use cases are useful for several reasons throughout the development life cycle:

In the planning stage, the process of defining important use cases helps to clarify the most important goals of the system. Use cases helps to narrow the scope of the project. They can surface often unspoken assumptions about the desired behavior of the system.
Roles add a level of abstraction to object-based constructs. A role is an instance of an encapsulated set of properties and behavior, but is described and used in a way that is totally independent of the object(s) that may implement it.
This definition is just a technical narrowing of the most common everyday sense of the word role. For example, we can talk about the role of Hamlet in a particular performance, without reference to the actor(s) playing this role. The decision about who actually plays this role on stage is a separate “casting” decision. Normally we'd like to pick the single actor providing the highest “quality of service”. But we would also like the freedom to swap in a designated “second” if the original actor gets sick, or perhaps even to use two children, one on the other's shoulders and together dressed to look like a single adult actor.
In the execution stage, use cases provide developers key parts of the specification. Some systems are built entirely with only use case descriptions from sponsors.

Use cases can be presented graphically in a diagram or in prose form, somewhat structured and highly structured.

Types of Use Case Activities

Activities performed in a use case may be categorized this way:

Activites that Assign Responsibility, determine appropriate resources. For example, in a project management system, a person is designated to a defined project task.

Activites that define New Objects, as in a new object aggregate.

Activites that define New Processes, such as an assembly of existing activities.

Use Case Diagrams

Use case diagrams are external view of a system's interactions with the outside world. Therefore, the system under discussion is illustrated as a single entity. Each line represents a channel of dialog between the actor and the system. The oval use case icon encapsulates how the system achieves its goal -- structuring mechanism for interaction diagrams

. The actual software is often structured in a completely different way.

Relationships

Lines in a use case represent more than a transfer of data or command, as in traditional flow chart and UML Activity Diagrams.
Lines in a UML use case between an actor and the system represent a more abstract concept of relationship of communication, acquaintance, or inheritance.

A use case circle can be more than a user invoking an on-demand service that passively waits until called upon.

A Use case circle can be event-driven, which proactively notifies one or more subscribers when specific events occur.

Services that run on their own without formal invocation may be better represented as an (automated) actor rather than as a use case circle.

Uses

The relationship lines labled with the <<uses>> stereotype illustrates how two use cases are combined.

Extends

The relationship line labled <<extends>> illustrates a special case: conditional (optional) or exception behavior.

A sample of a generalization relation is of a business use case "Withdraw Cash". Examples of use cases Subordinate to it would be:

Another sample of a generalization relation is of when different technologies are used to achieve the same ends:

To identify extensions in your application, look through boundary values and states in your data, where a user may, while performing a business use case, optionally:

obtain approval from higher-level management;
request more or less detail; (switching between a list instead of a form, obtain a more detailed report or analysis, map, etc.); requst a reformatted view (alternative sort, another view, etc.);
reach limits (such as the credit limit or the spending example above);
trigger low balance alerts and trigger automatic transfers (such as with stored valued toll accounts);
trigger ratios dynamically calculated reach a specified threshold, trades are placed automatically.

Includes

The relationship line labled with the <<includes>> streotype illustrates where a business use case is a part of the aggravation of many larger business processes. ;) Whoops. I mean the aggregation of a more comprehensive use case. This is why the relationship arrow point into the aggregate (higher level) use case.

"View Cart" includes to a part of "Choose shipping and payment methods".

Boundaries

A box defines the boundaries of related use cases. Lines from a box point to lower-level entities -- subdivision -- subgoals.

This sample use case diagram is from the Professional version of Microsoft Visio 2002 software. It's called a “Jacobson use case model” because use cases were popularized by Ivar Jacobson, one of the gurus who joined Rational corporation and defined the Unified Modeling Language (UML). This sample is within the “software” category because it is a widely accepted documentation protocol for Object Oriented design and programming.

A “scenario” results from sequencing interactions. A use case defines a collection of possible scenarios. A use case is a collection of scenarios, each with a different triggering event. The main course is the simplest scenario, the one in which everything goes right and goal is achieved without difficulty — all the subordinate use cases succeed. Alternative courses (and there can be any number of them) describe deviations from that basic course.

Use cases are one aspect of a complete design, described in this graphic from a pdf file named “Structure and Style in Use Cases for User Interface Design” at Larry Constantine's website:

Use cases should not assume or specify a particular user interface object, such as “push the start button” or “press the screen”.

Use Case Prose

There is no industry standard to describe use cases using sentences, but here is a typical example:

System under discussion: the insurance company
Primary Actor: me, the claimant
Goal: I get paid for my car accident
Conditions: Everything is in order
Outcome: Insurance company pays claim
Scenario:
1. Claimant submits claim with substantiating data.
2. Insurance company verifies claimant owns a valid policy (failure here probably means goal failure)
3. Insurance company assigns agent to examine case.
4. Agent verifies all details are within policy guidelines. (an interaction between the agent and secondary actors)
5. Insurance company pays claimant (implies all preceding goals managed to pass)

More Structured Use Case Prose

Alistair Cockburn suggests a general form of prose using a event/response pair :

<time or sequence factor> <actor> <action> <constraints>

Convert to active voice the verbs listed in Sample Action Verbs

Thus, typical sentences might look like:

At any time after the clerk gets the quote, he may cancel the sale.

Structured Use Case Prose

Various authors have proposed methods to better structure use case writeups.

Alistair Cockburn's template provides space for information that is filled out over several passes during the life of the project. An example is descriptions for failed Extensions to the use case.

Use Case Attributes

Attribute Description Example

Goal in Context a longer statement of the goal in context if needed> Buyer issues request directly to our company, expects goods shipped and to be billed.

USE CASE # a unique identifier assigned sequentially. 5

USE CASE NAME the goal as a short active verb phrase> Buy Goods

Scope & Level what system is being considered black box under design> <one of : Summary, Primary Task, Subfunction> Company / Summary

Preconditions Conditions assumed to be true before execution of the UC. We know Buyer, their address, etc.

Primary Actors a role name or description for the primary actors who invoke the use case. Buyer, any agent (or computer) acting for the customer

Triggers the action upon the system that starts the use case. purchase request arrives.

Frequency of occurrence load demands from the UC. 150 daily

Special Requirements The qualities and constrants of the UC. -

Secondary Actors other systems relied upon to accomplish use case. credit card company, bank, shipping service

Stakeholders and their Interests the implications, side-effects of the use case. -

Failed End Condition the state of the world if goal abandoned. We have not sent the goods, Buyer has not spent the money.

Success End Condition the state of the world upon successful completion. Buyer has goods, we have money for the goods.

Open Issues Any unresolved item. -

Attribute	Description	Example
Goal in Context	a longer statement of the goal in context if needed>	Buyer issues request directly to our company, expects goods shipped and to be billed.
USE CASE #	a unique identifier assigned sequentially.	5
USE CASE NAME	the goal as a short active verb phrase>	Buy Goods
Scope & Level	what system is being considered black box under design> <one of : Summary, Primary Task, Subfunction>	Company / Summary
Preconditions	Conditions assumed to be true before execution of the UC.	We know Buyer, their address, etc.
Primary Actors	a role name or description for the primary actors who invoke the use case.	Buyer, any agent (or computer) acting for the customer
Triggers	the action upon the system that starts the use case.	purchase request arrives.
Frequency of occurrence	load demands from the UC.	150 daily
Special Requirements	The qualities and constrants of the UC.	-
Secondary Actors	other systems relied upon to accomplish use case.	credit card company, bank, shipping service
Stakeholders and their Interests	the implications, side-effects of the use case.	-
Failed End Condition	the state of the world if goal abandoned.	We have not sent the goods, Buyer has not spent the money.
Success End Condition	the state of the world upon successful completion.	Buyer has goods, we have money for the goods.
Open Issues	Any unresolved item.	-

Related information to use cases:

Attribute Description Example

DESCRIPTION Steps and Action Steps sequentially numbered, each with an Action description MAIN SUCCESS SCENARIO
1. Buyer calls in with a purchase request.
2. Company captures buyer's name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

EXTENSIONS Steps and Branching Action Steps sequentially numbered, each with an Action description 3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)

SUB-VARIATIONS Branching Actions 1. Buyer may use phone in, fax in, use web order form, electronic interchange
7. Buyer may pay by cash or money order check credit card

Priority how critical to your system / organization> top

Performance the amount of time this use case should take> 5 minutes for order, 45 days until paid

Frequency how often it is expected to happen> 200/day

Channels to actors e.g. interactive, static files, database, timeouts> ?

OPEN ISSUES list of issues awaiting decision affecting a use case> What happens if we have part of the order? What happens if credit card is stolen?

SCHEDULE: Due Date: date or release needed> release 1.0

Superordinate Use Cases: Optional: name of use case(s) that includes this one> Manage customer relationship (use case 2)

Subordinates Optional: depending on tools, links to sub.use cases> Create order (use case 15)
Take payment by credit card (use case 44)

Attribute	Description	Example
DESCRIPTION Steps and Action	Steps sequentially numbered, each with an Action description	MAIN SUCCESS SCENARIO 1. Buyer calls in with a purchase request. 2. Company captures buyer's name, address, requested goods, etc. 3. Company gives buyer information on goods, prices, delivery dates, etc. 4. Buyer signs for order. 5. Company creates order, ships order to buyer. 6. Company ships invoice to buyer. 7. Buyers pays invoice.
EXTENSIONS Steps and Branching Action	Steps sequentially numbered, each with an Action description	3a. Company is out of one of the ordered items: 3a1. Renegotiate order. 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods: 7a. Handle returned goods (use case 105)
SUB-VARIATIONS Branching Actions		1. Buyer may use phone in, fax in, use web order form, electronic interchange 7. Buyer may pay by cash or money order check credit card
Priority	how critical to your system / organization>	top
Performance	the amount of time this use case should take>	5 minutes for order, 45 days until paid
Frequency	how often it is expected to happen>	200/day
Channels to actors	e.g. interactive, static files, database, timeouts>	?
OPEN ISSUES	list of issues awaiting decision affecting a use case>	What happens if we have part of the order? What happens if credit card is stolen?
SCHEDULE: Due Date:	date or release needed>	release 1.0
Superordinate Use Cases:	Optional: name of use case(s) that includes this one>	Manage customer relationship (use case 2)
Subordinates	Optional: depending on tools, links to sub.use cases>	Create order (use case 15) Take payment by credit card (use case 44)

Use Case Rankings

by business process volumetrics
- Transaction mix
- Average Sustained Rate which the use case is executed (per day/week/month/quarter/year).
- Peak Rate (per day / week / month / year) when maximum throughput will occur.
- Allowed completion Time (seconds/minutes/hours) SLA
- Bytes being moved through the scenario.
by business impact (critical, important, etc.)
by perceived complexity (high, medium, low, etc.)

Last updated

Your rating of this page:
Low High

Your comments on this topic, please:

Publish this comment publicly

Your first name:

Your family name:

Your location (city, country):

Your Email address:

Email me updates

Top of Page

Thank you!