Use Cases:

The Good, The Bad, and The Ugly

(and what you can do about it)

Hadar Ziv
[email protected]

In cooperation with:
Debra Richardson Thomas Alspaugh Thomas Standish And the ROSATEA group at UCI

Hadar Ziv / [email protected]

Presentation Outline

Use cases are good

Quantum leap in software requirements specification (in principle)

Use cases are bad

Difficult, time-consuming, and error-prone (in practice)

Use cases can get ugly

Use case mistakes, misuse, and even abuse cases

What you can do about it

Review Top Ten lists (practical advice) Consider Goals, Scenarios, Episodes, Concerns, and Aspects (research work in progress)

Hadar Ziv / [email protected]

Use Cases: The Good

Use cases are a simple and powerful way to define requirements for software behavior

Bank customer

Withdraw money

Kiosk User

Order tickets

Actor

Use Case

Actor

Use Case
Hadar Ziv / [email protected]

The Use-Case Model

A use-case model illustrates
The systems intended functions (use cases) Its surroundings (actors) Relationships between use cases and actors (use case diagram)

The same use-case model used in requirements

Is used in analysis, design, and test Serves as a unifying thread throughout system development

The most important role of a use-case model is to communicate The most important role of a use-case model is to communicate the systems functionality and behavior to the customer or end user the systems functionality and behavior to the customer or end user
Hadar Ziv / [email protected]

A Simple ATM Use Case Model

ATM
Withdraw Money Deposit Money Transfer Money (Between Accounts)

Bank Customer

Bank System

Hadar Ziv / [email protected]

Use Case Details

A use case is a textual or graphical description of

Major functions the system will perform for its actors Goals the system achieves for its actors along the way

A use case description should contain

Use case name Basic course or path of action Alternative paths and error/exception conditions

Scenarios
Describe typical uses of the system as narrative Correspond to a single path or flow through a use case A use case is an abstraction or container of a set of related scenarios

Hadar Ziv / [email protected]

Use Cases: The Bad and The Ugly

If you dont fully understand the ins and outs of use cases
It is easy to misuse them or turn them into abuse cases

Ellen Gottesdiener
Top Ten Ways Project Teams Misuse Use Cases and How to Correct Them. The Rational Edge, June 2002 (Part I), July 2002 (Part II).

Martin Fowler
Use and Abuse Cases. Distributed Computing, April 1998.

Doug Rosenberg
Top Ten Use Case Mistakes. Software Development, February 2001.

Susan Lilly
How to Avoid Use Case Pitfalls. Software Development, January 2000.

Kulak and Guiney

Use Cases: Requirements in Context. Second Edition, Addison-Wesley 2003.

Hadar Ziv / [email protected]

Ten Misguided Guidelines (Gottesdiener)

Dont bother with any other requirements representations

Use cases are the only requirements model youll need! Name use cases obtusely using vague verbs such as do or process There will be scope creep anyway, so you can refactor your use cases later

Stump readers about the goal of your use case

Be ambiguous about the scope of your use cases

Include nonfunctional requirements and UI details in your usecase text Use lots of extends and includes in your initial use-case diagrams
This allows you to decompose use cases into itty bitty units of work

Hadar Ziv / [email protected]

Ten Misguided Guidelines (Contd)

Dont be concerned with defining business rules

youll probably remember some of them when you design and code

Dont involve subject matter experts in creating, reviewing, or verifying use cases
Theyll only raise questions!

If you involve users at all in use case definition, just do it

Why bother to prepare for meetings with the users?

Write your first and only use case draft in excruciating detail
Why bother iterating with end users when they dont even know what they want

Dont validate or verify your use cases

That will only cause you to make revisions and do more rework!

Hadar Ziv / [email protected]

Top Use Case Mistakes (Rosenberg)

Dont write functional requirements instead of usage scenario text

Requirements are generally stated in terms of what the system shall do Usage scenarios are user actions and corresponding system responses

Dont describe attributes and methods rather than usage

Dont include too many presentation details Dont detail data-entry fields on user screen

Dont write the use cases too tersely

Must describe user actions and system responses in detail Err on the side of too much detail in user documentation

Dont completely ignore the user interface

Discuss features that allow the user to tell the system to do something

Dont avoid explicit names for boundary objects

Name boundary objects explicitly in the use case text

Hadar Ziv / [email protected]

Top Use Case Mistakes (Contd)

Dont write in a passive or not the users voice

Should be written from the users perspective Present-tense verb phrases in active voice

Dont ignore system behavior

Include what the system does in response to user actions
Creates new objects Validates user input Generates error messages

Dont omit text for alternative courses of action

Basic course of action easier to identify and write But alternate courses are critical for correctness and completeness; robustness

Dont focus on things outside the use case

Such as how you get there or what happens afterwards Watch out for long form use case templates!

Dont spend a month deciding whether to use includes or extends

Hadar Ziv / [email protected]

What Can Be Done About It?

Question everything, even the basic definitions of relationships between
Use cases to Goals (1:1?) Use cases to Scenarios (1:m?) Goals to Scenarios? All of the above to design and implementation???

Hadar Ziv / [email protected]

Use Cases and Goals

Use cases correspond to goals

A goal is a desired state of affairs (Schank/Wilensky)

Goals have nontrivial structure and relationships

At least hierarchical but could be more complex We need better understanding and analysis of goals

ATM example
High-level stakeholder goals
Increase the banks business success Increase market share Provide greater access to banking services

Low-level goals
Terminate a users session Authenticate a users ATM card and PIN Withdraw $200 cash from users account

Hadar Ziv / [email protected]

(Partial) Requirements Goal Graph

increase Banks business success increase profitability

increase productivity

increase market share

invest in automation

increase customer satisfaction

automate human teller banking services using Automated Teller Machines (or ATMs)

provide greater access to banking services

minimize total system development and deployment costs

more available hours

more available locations

safe and secure

convenient and easy to use

Hadar Ziv / [email protected]

Use Cases and Scenarios

Use cases contain a family of related scenarios

Within a single use case, scenarios may have nontrivial structure Across use cases, scenarios are often referred to, reused, or linked in nontrivial ways Often, containment becomes confinement!

Scenarios
A sequence of events that corresponds to a purposeful use of a system Purposeful uses are characterized by associated goals

Episodes
Subsequences of events contained within a surrounding scenario Correspond to the pursuit of subgoals Example episodes: Login, Logout, Authenticate

Hadar Ziv / [email protected]

Goals and Scenarios

Software requirements
Involve many goals at many different levels of abstraction/detail
provide goals prevent goals

Goals and Scenarios

A high-level provide goal typically corresponds to a single usage scenario A low-level provide or prevent goal typically corresponds to a single plan of action or episode Therefore, a usage scenario consists of multiple episodes addressing multiple goals!

Hadar Ziv / [email protected]

A Family of ATM Scenarios

Insert ATM Card

Give PIN to Access Your Account

Choose a Transaction

Withdraw Cash

Make Deposit

Find Balance

Log Off

ATM Machine Returns Your ATM Card

Hadar Ziv / [email protected]

A Family of ATM Scenarios (Contd)

1. "Login Episode" 2. The ATM presents, in English, a choice of transactions the customer may perform. 3. Iteration *: 1. Alternatives: 1. Alternative: 1. The customer selects "Withdraw cash". 2. "Withdraw Cash Episode 2. Alternative: 1. The customer selects "Make deposit". 2. "Deposit Funds Episode 3. Alternative: Guard: Customer has more than one account. 1. The customer selects "Transfer funds". 2. "Transfer Funds Episode" 4. Alternative: 1. The customer selects "Balance". 2. "Balance Episode" 2. ATM presents, in French, a choice of transactions the customer may perform. 4. The customer selects "Done". 5. The ATM ejects the ATM card and beeps until the customer withdraw it. 6. The customer withdraws the card.
Hadar Ziv / [email protected]

A Sample Login Episode

1. The customer inserts an ATM card into an ATM. 2. The ATM presents a choice of languages. 3. The customer selects English. 4. The ATM prompts for a PIN. 5. The customer enters the PIN for his/her ATM card.

Hadar Ziv / [email protected]

A Sample Withdraw Cash Episode

1. The customer selects "Withdraw cash". 2. The ATM presents the accounts from which the customer can withdraw. 3. The customer selects "Checking". 4. The ATM prompts for an amount to withdraw. 5. The customer enters $200. 6. The ATM dispenses the requested amount of cash. 7. The ATM prints a receipt. 8. The ATM presents a choice of transactions the customer may perform.
Hadar Ziv / [email protected]

Example of Scenario Goal Analysis:

g2: Use ATM to withdraw $200 cash from your checking account g2a: Get access to ATM banking services in your language g2b: Use ATMs Cash Withdrawal service to withdraw $200 in cash g2c: Finish ATM session properly

g2a1: insert ATM card

g2a2: select French as UI language

g2a3: enter PIN for ATM card

g2c1: choose transaction Done

g2c2: collect ATM card from machine

{1}

{2,3}

{4,5}

{14,15}

{16,17}

g2b1: choose transaction Withdraw Cash

g2b2: designate Checking Account to use for withdrawal

g2b3: specify $200 as amount to withdraw

g2b4: collect cash & receipt dispensed by ATM

{6,7}

{8,9}

{10,11}

{12,13}

Hadar Ziv / [email protected]

ATM AND/OR Goal Analysis

Access and Authorization Goals AND GOAL G1

grant access to qualified users

deny access to unqualified users

Allow users who have been granted access to perform authorized transactions OR

make deposit D GOAL G4 credit deposit D to balance B B B + D, tell customer when B is available for withdrawal

find current account balance B GOAL G2 withdrawal permitted if AND

withdraw cash amount W GOAL G3 debit withdrawal from balance B BB-W

W Balance B

W Banks daily withdrawal limit L

W ATMs cash C available to dispense

Hadar Ziv / [email protected]

Concerns and Aspects

Goals correspond to concerns

provide concerns
Withdraw money, Deposit money, Transfer money

prevent concerns

Aspects correspond to cross-cutting concerns

Typically prevent concerns
User access/authentication, data integrity, transaction integrity

A requirements-level usage-scenario
Will be written as a collection of episodes Will be designed to address multiple concerns Will be implemented using regular code + aspects for the cross cutting concerns
Hadar Ziv / [email protected]

Use Cases and Aspects

According to Jacobson,
All use cases are extensions to the null system

He sees a relationship between use cases and aspects, such that

aspects extensions join points extension points

AOP allows us to
Separate use case extensions all the way down to code Compose back extensions before execution

Thus, AOP supports extensions

Ivar Jacobson, Use cases and aspects Working together.

Hadar Ziv / [email protected]

Summary and Recommendations

Be aware of top ten lists of use case mistakes, misuse, and abuse cases
Beware each article has a different list! Beware articles provide different, sometimes conflicting advice!

Consider goals and scenarios

When writing use cases or instead of writing them Perform goal analysis and goal decomposition Perform scenario analysis and scenario composition (from episodes) Design and implement using concerns and aspects (for cross-cutting concerns)
Hadar Ziv / [email protected]