• Alternative Definitions:
  • An abstract episode or interaction between a system and its environment
  • A description of one or more sequences of actions that a system performs to yield an observable result
  • A way of using a system
  • A dialog that a system and its environment share as they interact
• Uses:
  • A way to describe the requirements/features of a product/system

• Using the house for cooking and eating
• Unloading groceries, storage, placement of appliances, serving meals, ...
• Using the house for entertaining
  • Flow of people, facilitating conversation, ...
• Using the house for sleeping
• Using the house to raise children

• A use case should be an entire transaction
• A withdrawal from an ATM machine
• A telephone call
• The collection of uses cases should entirely characterize the functionality of the system

1. Define the context of the system (i.e., the environment)
2. Identify outside entities that interact with the system (i.e., actors)
3. Consider the behavior that each actor expects/requires the system to provide
4. Identify common behaviors (i.e., use cases)

• Types:
  • Principal actors (e.g., people who use an ATM)
  • Secondary actors (e.g., people who maintain an ATM)
  • External hardware (e.g., the printer in an ATM)
  • Other systems (e.g., the bank network)
• Description:
  • Use at most 3-4 lines of text

• What are the tasks of the actor?
• What information must be created, saved, modified, deleted or read by the actor?
• Will the actors have to notify the system of any external modifications?
• Will the system have to notify the actor of internal conditions?

• The beginning of the use case
• The origin of information
• The exchange of information (chronological)
• The end of the use case

• Types of Flow:
  • Main Flow of Events
  • Exceptional Flow of Events
• Specifying Optional Situations:
  • "The actor chooses one of the following:
    • (a) Cash
    • (b) Credit

    and then..."

• A scenario is a description of a specific interaction involving a particular actor
• A use case abstracts scenarios that are instances of the same kind of interaction

• Definition:
  • The size or scope of a use case
• Examples:
  • Large: "Manage Pharmacist Privileges"
  • Small: "Fill a Prescription"

• Tradeoffs:
  • A large number of simple use cases vs. a small number of complicated use cases
• What to Try For:
  • A collection of use cases at a uniform granularity

• Defined:
  • A schematic representation of actors, use cases, and the relationships between and among them
  • NOT a diagram illustrating the details of a use case
• Actors:
  • Abstractions of agents that interact with a system
  • Names are usually noun phrases (e.g., SalesRep, BillingSystem)
• Use Cases:
  • Abstract episodes or interactions between a system and its environment
  • Names are usually verb phrases (e.g., EnterSale) though not always (e.g., ElectronicFundsTransfer is more meaningful than TransferFundsElectronically)

• Actors:
• Use Cases:
• Relationships:
  • Association
  • Specialization/Generalization

• Actors:
  • "Is a" relationship (e.g., CommercialCustomer extends Customer)
• Use Cases:
  • "Use" relationship (e.g., FundsTransfer uses IdentifyCustomer)
  • "Is a" relationship (e.g., TransferFundsElectronically extends TransferFunds)

A (Non-Atomic) Needs List

Drivers need IVANA to help get them where they want to go.

IVANA should work with the vehicle's location system (e.g., GPS), programmable display, and speech generation system.

IVANA should display a map and vehicle's location on the programmable display.

The user needs to be able to enter a destination.

IVANA should determine a recommended route, display it on the programmable display, and provide spoken turn-by-turn directions.

Use Case Diagram

• Defined:
  • Describe how the actors and systems interact
  • ARE a description of a use case
• Notation:
  • There is no standard notation
  • Natural language is often used

• High Level (i.e., Most Abstract):
  • Often only a few sentences
  • Usually do not include interaction protocols (e.g., user identifies himself/herself to ATM)
• Low Level (i.e., Most Detailed):
  • Provide additional details
• Implementation Level (a.k.a., Real):
  • Include interaction protocols (e.g., user is prompted with ..., must enter a 4-digit PIN, must press...)

• An Observation:
  • There is no standard
• Remember:
  • Clarity is paramount

From an In-Vehicle Navigation System named IVANA

Enter Destination (Actors: Driver)

Actor Action	System Response
0. This use case begins when the Driver chooses to enter a Destination.
	1. The system asks the Driver to select a Destination Type (either an Address or a Location).
2. The Driver selects a Destination Type.
	3. The system asks the Driver to enter a Destination.
4. The Driver enters a Destination.
	5. If the Destination is a Location the system records it. If the Destination is an Address the system attempts to geocode it (i.e., determine a Location). If it can, it records the Location. If it can't, this use case re-starts.

From a Timetable System named Papyrus