Use Cases

Object Oriented Analysis & Design

Use-Cases: an Example

Object Oriented Analysis & Design

Using use cases to describe requirements

Use cases can show the sets of possible interactions between the system and the people who use it Use cases can also show interactions between computer systems Use cases can also be used at the subsystem level (to show interactions between subsystems)

Example use case diagram

Student

My system
register

Administrator
create new course

Instructor

delete offering

actors

use cases

Object Oriented Analysis & Design

What is a Use Case?

A Use Case captures a contract between the stakeholders of a system about its behavior. Use cases describes the systems behavior under various conditions as the system responds to requests from its users (actors) specifying how the actors goals get delivered or fail. A use case is:
a set of scenarios that describe the behavior of the system and its users at a high level of detail with sunny-day and rainy-day scenarios being defined

A use case gathers the scenarios related to the (primary) actors goal Actors are the people and/or computer systems that are outside the system under development (SuD)and interact with it:
Primary actor a stakeholder who requests that the system deliver a goal Supporting/secondary actor an external system against which the SuD has a goal

Scenarios are dialogs between actors and the system

Object Oriented Analysis & Design

What is a Use Case (cont)?

A Use Case is the set of scenarios that provides positive value to one or more external actors actors are the people and/or computer systems that are outside the system under development scenarios are dialogs between actors and the system no information about the internal design

Object Oriented Analysis & Design

More about Use-Cases

A use-case is a set of activities within a system presented from the point of view of the associated actors leading to an externally visible result a (simplified) part of a business process model

A use defines WHAT is the system supposed to do

not for functional decomposition simplified and limited graphical notation other diagrams and text templates used to support it combined with prototypes

Object Oriented Analysis & Design

Actors
An actor is an entity that is outside of the system Actors will interact with the system: an actor will often request the system to perform some actions on behalf of the actor an actor may also receive responses from the system An actor plays a role in the use of the system the name given to an actor is usually the role name: for example, an actor who is a Person will usually be called a User, Operator, Administrator, or something like that each role might be treated as a different actor in the use cases

Object Oriented Analysis & Design

Communication between actors and the system

In each use case, a primary actor starts things off: that actor initiates an interaction with the system The system will then respond to messages and might send messages of its own to other actors In a use case, the primary actor is trying to achieve a specific goal: the use case consists of all the possible interactions that take place in the attempt to reach the goal there may be many scenarios in a use case - each scenario shows an alternative course that is based on the success or failure of some of the intermediate steps the goal might not be reached (because of some of the failures)
Object Oriented Analysis & Design

Goals
A goal is a result that one of the actors wants to achieve Example goals: An administrator wants to add a new user to the system A pilot wants to land a plane A customer wants to file a claim on an insurance policy A service person wants to file a trouble report

Object Oriented Analysis & Design

Scenarios
A scenario is a little story it is an outline of some expected sequence of events A scenario is used to convey the fundamentals of how things work It usually includes at least one actor Each actor can make requests of the system or respond to system activity

I would like a book of stamps, please. OK. Will that be all?

Yes.
That will be $7.40. Here is $10. Thanks. Here are your stamps and your change.

Object Oriented Analysis & Design

Identifying actors
An Automated Teller Machine (ATM) permits customers to withdraw money from their accounts, make deposits, and check their account balances. The ATM machine communicates with a computer system in the banks central office to validate passwords and account information. The ATM is serviced on a regular basis by bank employees, to collect deposit envelopes and to load in more cash and receipt paper. Question: who are the actors in this system?

Object Oriented Analysis & Design

Creating a simple scenario

Draw a sequence diagram for one of the scenarios in the ATM system. One prominent use case in this system is customer performs an ATM transaction, and one scenario in that use case is customer withdraws money. Assume we are in the sunny-day scenario.
Customer
1. Customer inserts card ???

ATM

Object Oriented Analysis & Design

Scenario - Example
A scenario is a little story It describes one possible course of events:
Customer puts ATM card into machine and types password System validates the card and password System prompts the customer for a transaction type and amount Customer selects withdraw $100 from checking System checks with the central bank make sure customer has sufficient funds System dispenses the cash, returns card, and prints receipt System asks customer if he/she would like another transaction

Object Oriented Analysis & Design

Representing Use cases

Text templates:
Informal text
informal paragraph summary the paragraph will describe who starts the scenario, the key actions by the actors and the system, and how to handle failures numbered list of steps in this format, the main scenario is a list of sentences describing the sequence of actions by each actor and/or the system; failure scenarios can be written as branch scenarios at the end

Tables informal text Structured templates one popular example (A. Cockburn) Structured (semi-formal) DOORS template

Graphical formats:

UML Use Case diagrams capturing the system boundary, use cases(names), actors, channels and use case relationships UML Sequence Diagrams (also known as message sequence charts, MSC) to represent scenarios
Object Oriented Analysis & Design

Showing a scenario in text format

A scenario can be written as a series of sentences: each sentence shows one step of the scenario each step needs to explain
who does the operation what operation is performed when the operation is performed are there any side conditions?

one important thing that is not included in the description of each step of a scenario: how the operation is performed (this is left for the design phase) Important style points: each step in the scenario must have a subject (either the system or an actor is performing the step) no passive or impersonal voice allowed (e.g., the results are displayed)

Object Oriented Analysis & Design

Example of a text format scenario

Customer buys a single item:
1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4. Customer indicates that they dont want anything else 5. Postal clerk determines the price of the requested items and tells the customer 6. Customer pays 7. Postal clerk gives the Customer the items and change

Note: this is not yet a use case, just a single scenario.

Object Oriented Analysis & Design

Showing a scenario in graphical form

Scenarios can be shown in a standard graphical notation this notation has many different names Sequence diagram, Event trace diagram, Interaction diagram, Fence post diagram
Customer
Ask for item Acknowledge request Anything else? No Respond with price Give money Give item and change

Postal clerk

Object Oriented Analysis & Design

Writing a use case

Step 1: Pick one of the potential goals of one of the actors Step 2: Write down the preconditions for that goal Step 3: Write the sunny-day scenario for the interaction between actors and system Step 4: Identify the possible failures at each step - think about the alternative scenarios that might result Step 5: For the main failure situations, either create entire scenarios or create extensions of the main scenario optional step: Find common chunks that occur in several scenarios that can be factored out to make the scenarios simpler

Object Oriented Analysis & Design

Example use case

Use case name: Ticket Buyer buys a lottery ticket Primary actor: Ticket Buyer Precondition: Ticket Buyer has $1 Main scenario: 1. Ticket Buyer tells the system (person or machine) that he/she wants to buy a ticket 2. System asks the Ticket Buyer for his/her choice of lucky number 3. Ticket Buyer chooses a number 4. System asks for $1 5. Ticket Buyer supplies $1 6. System prints a lottery ticket and gives it to the Ticket Buyer Variations: 2. Ticket Buyer chooses a number: 2a. using keypad 2b. fills in circles on card 2c. asks for a quick pick
Object Oriented Analysis & Design

Example use case - scenario

Ticket buyer Ticket machine

Alternative format for a scenario: UML Sequence Diagram (also known as Message sequence chart) Note: the scenario explains what happens but not how it happens (that will be in the design)

Sell me a ticket Prompt for lucky number Number choice Prompt for $1 Insert $1 Dispense ticket

Object Oriented Analysis & Design

Example use case (continued)

The use case isnt finished still need to handle failures go through the steps, list the various ways that they could fail:
Ticket Buyer cant decide on a number, changes his/her mind Ticket Buyer fills in too many circles on the card System cant print a ticket because it is out of ticket paper

from some failures, the system can recover from other failures, the use case will fail

Object Oriented Analysis & Design

Making scenarios more elaborate

There are three ways to create more elaborate scenarios: Variations Extensions Chunks (subfunctions)

Object Oriented Analysis & Design

Variations
A variation is a way to avoid scenario explosion A variation is a list of alternatives that is tied to a specific line of a scenario Each variation could turn into a lower-level scenario An example variation (for the post office scenario):
1. Item is a. stamps b. postage on an item that the customer is mailing c. postage due on an item that the customer is receiving d. post office box rental e. mugs, t-shirts, and other Postal Service merchandise 6. Payment is a. ______________ b. ______________ c. ______________
Main scenario: 1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4. Customer indicates that they dont want anything else 5. Postal clerk determines the price of the requested items and tells the customer 6. Customer pays 7. Postal clerk gives the Customer the items and change

Object Oriented Analysis & Design

Extensions
An extension is a short scenario that branches off from another scenario Extensions are used to describe recovery actions when something goes wrong extensions might rejoin the main scenario or extensions might just terminate because the goal cant be achieved An example extension (for the post office scenario):
2a. Item is not available: 2a1. Postal clerk looks for an equivalent item 2a2. If an equivalent item is found, the Postal clerk asks customer if the equivalent item is OK
Main scenario: 1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4.

Object Oriented Analysis & Design

Chunks
A chunk is a sub-scenario - a sequence of messages that appears in several scenarios for one or more use cases. A chunk is a scenario that addresses a specific subgoal
for example: logging in, searching for a specific product, etc.

They are the subroutines of the use case family They may express some common user interface subscenarios Alistair Cockburn calls them subfunctions (but we dont want to think of them as associated with low-level code)

Object Oriented Analysis & Design

The UML Use Case Diagram

In UML (Unified Modeling Language), it is possible to show a picture of the system as a group of use cases: each stick figure is an actor each ellipse represents a use case The diagram is deceptively simple behind each ellipse, there might be a whole bunch of scenarios sunny-day, alternatives, failures the diagram is only a summary

withdraw cash Customer

check balance
Bank Employee service ATM

Object Oriented Analysis & Design

A simple format for a use case

Use case 1: Employee opens door
Goal: An Employee wants to unlock a door to pass from one room to another. Preconditions: The Employee has valid identification to open the door. Success end condition: Employee has successfully opened the door. Failed end condition: Door remains closed and the Security Guard on duty is notified. Actors: Employee, Security Guard Main scenario: 1. Employees identification and door identification is sent to system 2. Door is unlocked 3. Employee opens door, passes through the door, and recloses door, SUCCESS Extensions: 2a. Employees identification is not valid 2a1. System notifies Security Guard, FAIL

Office Security System

Employee

open door reset alarm

Security Guard

test alarm

Repair Person

Object Oriented Analysis & Design

More Notations and Examples

Object Oriented Analysis & Design

Use-Case diagrams - actors

Textual stereotype (class)

actor cellular network

Visual stereotypes (classes)

boundary/interface
actor
persons & roles

control

entity
passive objects data stores

Object Oriented Analysis & Design

More on Use-Case diagrams

Show use-cases & actors connected by associations refined by inheritance stereotypes uses
re-use of a set of activities (use-case) partitioning of activities points to the re-used use-case elicit customer needs

extends
make an interview

extends
variation of a use-case points to the standard use-case

uses
produce a SRS

Object Oriented Analysis & Design

Use-Case diagrams: Example

anybody

check travel options uses search for a flight flight db

clerk

actor flight res-sys

traveler

book a flight

uses
clerk extends Pay a bill

pay with cc customer

actor credit-card sys

prepare-travel
Object Oriented Analysis & Design

On Use Case Levels

It is possible to write
business-level use cases
organizational goals (marketing, finance, systems engineering, installation)

or system-level use cases

goals of specific users

or subsystem-level use cases

goals of the other subsystems

Object Oriented Analysis & Design

Levels of scope (A. Cockburn)

Summary-level goals cloud-level Upgrade all customers

Add new service

User goals sea-level usually 2 to 20 minutes

Find list of services

Sub-functions under water not a real user goal: these scenarios describe common suboperations

Object Oriented Analysis & Design

Goals & Sub-goals

Each use case represents a goal of one of the actors
the use case is the set of all scenarios that might happen in trying to reach that goal success or failure scenarios each scenario is a series of smaller sub-goals
if you can succeed in each step, you will reach the goal if a step fails, then there might be an alternative series of steps that get to the goal the substeps might be lower-level use cases, or they might just be things implemented in the design

Object Oriented Analysis & Design

Use- Case diagrams: Hiearachies

diagram name: anything

uc-1
uc-2 uc-3 uc-4

Use Case diagram decomposition

Diagram name: anything-level2-for-uc4

uc-4.1 uc-4.2
Object Oriented Analysis & Design

Use Case Process

Step 1: Create a list of Actors Step 3: Write simple use cases with only sunny-day scenarios
UC1: Customer downloads a song Precondition: Song file is on a server Main scenario: 1. Customer chooses song 2. System checks availability and price; prompts Customer for payment 3. Customer enters credit card info 4. System sends credit card transaction to Bank 5. Bank returns transaction number 6. System transmits the song to Customers computer

Customer

Support hotline person

Administrator

Repair person

Step 2: Create a list of Goals

Web-based music distribution system:
UC1: Customer downloads a song UC2: Customer searches music directory UC3: Administrator adds a new user UC4: Administrator updates directory UC5: Support hotline person investigates a Customer problem UC6: Support hotline person authorizes Customer refund UC7: Repair person runs diagnostics

Step 4: Review the use cases with customer (or customer surrogate)

Object Oriented Analysis & Design

Use Case Process (Cont.)

Step 5: Identify failure conditions
2a. Song is not available 3a. Customer quits without entering credit card info 4a. Link to Bank is down 5a. Credit card is rejected by Bank 6a. Server fails during transmission 6b. Customer cancels during transmission

Step 7: Internal review review the scenarios and failure branches with testers, developers, project managers Ongoing: make links to other requirements, update use case model as needed define the business rules and non-functional requirements (in text documents, with links to the use case model) add new use cases and new scenarios for new actors and goals; new variations for existing use cases
Object Oriented Analysis & Design

Step 6: Write a selected set of failure scenarios and alternatives

5a. Credit card is rejected by Bank: 5a1. System reports failure to the Customer, prompts Customer for a different credit card 5a2. Customer enters card info 5a3. go to step 4

How many use cases is enough?

It depends
make sure you cover the major goals of each actor dont forget OA&M administrative use cases usually include initialization, running backups, diagnosing problems, and reporting current status to another system some systems might need 100-200 use cases, but most only have 20-40 do some abstraction to reduce the number of scenarios
Object Oriented Analysis & Design

Use Cases contribute to agility

It is important to be agile Requirements
get direct customer involvement in documenting the requirements using scenarios and use cases

Architecture
make better architectural decisions use the high-runner, high-priority scenarios to assess candidate architectures

Project management
use cases can help to plan an iterative development process

Test
update the tests as the requirements change
Object Oriented Analysis & Design

Scenarios and use cases in design, coding, and test

The use cases are a very useful form of requirements they attempt to describe the externally visible behavior of the system they are concise enough for everyone to read (customers, developers, testers) Use cases can be kept under change control Design-level and code-level comments ought to refer to individual use cases, so that individual design decisions can be revisited when the use cases are changed System-level tests will use the information from use cases

Object Oriented Analysis & Design

Impact of Use Cases on Software Teams

Systems engineers: improve communication with development team
SEs will write the key functional requirements as use cases (typically, 20 to 200 use cases for a system) the set of system-level use cases (a subset of the overall requirements) can be constructed and reviewed quickly customers can validate the main scenarios

Architects: benefit from using the most important failure scenarios to evaluate the architecture Development managers: iterative and incremental development can start with the high-priority use cases focus on the scenarios that deliver the maximum value to customers Developers: code inspections can narrow the focus on the most important scenarios Testers: integration and system tests are guided by the use cases
Object Oriented Analysis & Design

Use cases and requirements

Use cases are requirements
a use case will specify the essential behavior that the system must deliver

Use cases are usually about 1/3 of the total volume of requirements The use cases are supplemented by other kinds of requirements information
Business Rules: conditions, policies, and conventions Operational Profiles: how many scenarios Architectural Requirements: -ilities (reliability, usability, performance)
Business Rules BR1. Each employee has a unique identification number. BR2. Each open-door request is logged. Operational Profiles OP1. During the busy hour (8-9am), the system should be able to handle 500 open-door requests (UC1 sunny-day). OP2. The test alarm use case will be executed every weekend. Architectural Requirements AR1. Maximum time to process an open-door request is 15 seconds. AR2. No more than 5 minutes downtime per year.

Object Oriented Analysis & Design

Why use cases?

Why write use cases instead of normal functional requirements? Use cases hold functional requirements in an easy-to-read, easy-to-track format Each use case gives information on how the system will deliver a goal to one of the users of the system
a use case explains how a goal succeeds/fails using scenarios the scenarios provide context traditional requirements are often too ambiguous If you have a requirement that doesnt help meet any of the users goals, why do you have the requirement in the system? also need to look at the goals of the stakeholders

Use cases show only the Functional requirements

the use cases are a framework to attach non-functional requirements and other project details
Object Oriented Analysis & Design

After the use cases are written, what next?

Jumpstart the OOAD CRC and models use cases describe the externally-visible behavior of the system an object model describes the internal behavior Design decisions can be linked back to a use case Jumpstart test cases Scenarios provide excellent start for early testing Test planning RTP and RSTP DOORS-based traceability Use the Use Case list to manage your project Use cases provide excellent basis for structuring and monitoring your project iterations It is important to be agile
Object Oriented Analysis & Design

Iteration management with use cases

A use case model can be very useful in a project with rapid iteration
for each iteration, identify which use cases are in the iteration that is, will some or all of the use cases scenarios work? track progress by counting scenarios (with priority weighting) typical iteration scheme: first iteration: highest priority use cases, sunny-day scenarios only second iteration: add a few second-tier use cases, start implementing the failure scenarios that fail completely later iterations: add a few more use cases, start filling in the recovery scenarios you might choose certain use cases as high-priority because they help validate key parts of the architecture

Object Oriented Analysis & Design

References
Books:
Alistair Cockburn, Writing Effective Use Cases Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in Context Steve Adolph and Paul Bramble, Patterns for Effective Use Cases Kurt Bittner and Ian Spence, Use Case Modeling

Web sites:
http://www.usecases.org http://agilealliance.org http://members.aol.com/acockburn http://members.aol.com/acockburn/papers/usecases.htm

Object Oriented Analysis & Design

Extra ...
Summary

Object Oriented Analysis & Design

Better Requirements and Product Quality through Use Cases (UC)

Summary of Characteristics and Benefits

UCs capture a contract between the stakeholders of a system about its behavior UCs specify systems behavior under various conditions (success & failure modes) in a way that is concise and easy to understand, track, and validate UCs are collections of scenarios; scenarios provide context traditional requirements are often too ambiguous UCs are a key to the creation/ generation of quality test cases and system verification

Industry data:

Use cases improved developer productivity by 40% (DaimlerChrysler) 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases

Object Oriented Analysis & Design

Vocabulary in this section

use case: collection of scenarios related to a goal goal: what the actor is trying to accomplish when using the system (this might succeed or fail) scenario: a sequence of interactions sunny-day scenario: a scenario where everything works failure scenario: a scenario that explains what happens when something goes wrong variation: a set of choices for a single scenario step extension: a branch scenario that starts with an extension condition actor: a person or system outside of the system under development precondition: one of the conditions that must be true when a scenario of the use case is triggered chunk or subfunction: a set of scenario steps that are repeated in several different use cases business rule: one of the rules that describes how the business is run operational profile: description of which use cases will be run at the same time

Object Oriented Analysis & Design

Useful books
Writing Effective Use Cases by Alistair Cockburn Patterns for Effective Use Cases by Steve Adolph and Paul Bramble Use Case Modeling by Kurt Bittner and Ian Spence

Object Oriented Analysis & Design