Chapter 3: Use Cases · Ahmet Çelik

Source files used: Lecture 3 - Use Cases; textbook (applying-uml-and-patterns.pdf) Chapter 6 as support.

A focused guide to use cases for the COMP302 Midterm 1. It covers what a use case is, actor types, the three formats, the sections of a fully dressed use case, how to find and size use cases, and use case diagrams. Guide 2 said the Use-Case Model holds the functional requirements; this guide shows how to write it.

Roadmap: 1 OOA/D and UP → 2 Inception and Requirements → 3 Use Cases → 4 Domain Models → 5 SSDs and Contracts → 6 Logical Architecture → 7 Interaction Diagrams

What Use Cases Are

Stories of Using a System

A use case is a text story of some actor using a system to achieve a goal. Use cases are used to discover and record requirements (mostly functional, the F of FURPS+), and they serve as input to later work. They emphasize user goals and perspective, not system implementation choices.

A brief-format example from the lecture:

Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items.

Three Definitions

Actor: something with behavior: a person (user), a computer system, or an organization.
Scenario: a specific sequence of actions and interactions between actors and the system. It is also called a use case instance: one particular story of using the system, one path through the use case.
Use case: a collection of related success and failure scenarios that describe an actor using a system to achieve a goal.

The Use-Case Model

Use-Case Model = the set of all written use cases + UML use case diagrams. It belongs to the Requirements discipline and models the system’s functionality and environment.
Use cases are text documents, not diagrams. Use-case modeling is primarily an act of writing.
There is nothing object-oriented about use cases; writing them is not OO analysis.
The Use-Case Model is not the only requirements artifact (see the Supplementary Specification, Glossary, Vision, and Business Rules in Guide 2).

Why Use Cases?

They capture goals and involve users; lack of user involvement is among the top reasons projects fail.
They emphasize user goals and perspective.
They are a good way of keeping things simple.

How Use Cases Feed Other Artifacts

The lecture’s UP artifact figure shows use case text as the hub:

use case text --(conceptual classes, attributes, associations)--> Domain Model
use case text --(terms, attributes, validation)-----------------> Glossary
use case text --(scope, goals, actors, features)----------------> Vision
use case text --(non-functional reqs, quality attributes)-------> Supp. Spec.
use case text --(system events)--> SSDs --(system operations)--> Operation Contracts

Exam Trap #1: Saying “use cases are diagrams.” Use cases are text; the use case diagram is auxiliary and secondary.

Actors

Primary, Supporting, Offstage

An actor is anything with behavior, including the system under discussion (SuD) itself. Primary and supporting actors appear in the action steps of the use case text.

Actor type	Definition	Example	Why identify it
Primary	has user goals fulfilled through using services of the system	Cashier	to find user goals, which drive the use cases
Supporting	provides a service (for example, information) to the system; often a computer system	automated payment authorization service	to clarify external interfaces and protocols
Offstage	has an interest in the behavior, but is not primary or supporting	government tax agency	to make sure all necessary interests are identified and satisfied

The Primary Actor Depends on the System Boundary

Is the cashier or the customer the primary actor of Process Sale? It depends on the boundary:

If the enterprise and checkout service together are the system, the customer is a primary actor (goal: get goods or services and leave).
From the viewpoint of just the POS system, the system serves the cashier’s goal to process the sale.

Use Case Formats

Brief, Casual, Fully Dressed

Format	Description	Lecture example
brief	terse one-paragraph summary, usually of the main success scenario	Process Sale (above)
casual	informal paragraph format; multiple paragraphs that cover various scenarios	Handle Returns
fully dressed	the most elaborate; all steps and variations in detail, with supporting sections such as preconditions and success guarantees	UC1: Process Sale

The casual example, abbreviated:

Handle Returns

Main Success Scenario: A customer arrives at a checkout with items to return.
The cashier uses the POS system to record each returned item ...

Alternate Scenarios:
If the credit authorization is rejected, inform the customer and ask for an
alternate payment method.
If the item identifier is not found in the system, notify the Cashier and
suggest manual entry of the identifier code (perhaps it is corrupted).
If the system detects failure to communicate with the external tax
calculator system, ...

Black-Box Style

Write black-box use cases: describe the system’s responsibilities (what), not its internal workings or design (how). The textbook’s contrast:

BLACK-BOX:  The system records the sale.
NOT:        The system writes the sale to a database.
WORSE:      The system generates a SQL INSERT statement for the sale.

The Fully Dressed Use Case

Sections

Section	What goes in it
Scope	the boundary of the system under design
Level	user-goal (for example, buy some stuff and pay) or subfunction (for example, cashier authenticates himself; duplicated steps factored out)
Primary Actor	the actor whose goal the use case fulfills
Stakeholders and Interests	who cares and what they want; functional and non-functional requirements come from these
Preconditions	conditions that must hold before the use case starts; noteworthy assumptions; not tested within the use case (for example, logging in successfully completed)
Success Guarantee (Postconditions)	what is guaranteed to be true on successful completion; should meet the needs of all stakeholders
Main Success Scenario	the basic flow, or happy path: the steps of the success path, with conditions and branching deferred to Extensions
Extensions (Alternate Flows)	all other scenarios or branches, both success and failure; normally most of the text
Special Requirements	non-functional requirements tied to this use case
Technology and Data Variations List	variations in technology or data (input devices, code formats)

A step in the main success scenario is one of three things: an interaction between actors, a validation (usually by the system), or a state change by the system. Some sequences of steps may repeat (“Cashier repeats steps 3-4 until indicates done”).

Extension Rules

An extension of step 3 is labeled 3a, 3b, … An extension that can happen at any step is labeled *a, *b, … The lecture example also uses ranges such as 3-6a.
An extension has two parts: the condition (something the system or an actor can detect) and the handling (the response).
At the end of an extension, flow merges back with the main success scenario, unless the extension says otherwise.
A branch into another use case’s scenario is shown with underlining.

Fully Dressed Example (UC1, Abbreviated)

Use Case UC1: Process Sale
Primary Actor: Cashier
Stakeholders and Interests:
 - Cashier: wants accurate, fast entry and no payment errors.
 - Customer: wants purchase and fast service with minimal effort.
 - Government Tax Agencies: want to collect tax from every sale.
 - Payment Authorization Service: wants requests in the correct format.
Preconditions: Cashier is identified and authenticated.
Success Guarantee: Sale is saved. Tax is correctly calculated. Accounting and
 Inventory are updated. Commissions recorded. Receipt is generated.
Main Success Scenario:
 1. Customer arrives at POS checkout with goods and/or services to purchase.
 2. Cashier starts a new sale.
 3. Cashier enters item identifier.
 4. System records sale line item and presents item description, price,
    and running total.
 Cashier repeats steps 3-4 until indicates done.
 5. System presents total with taxes calculated.
 6. Cashier tells Customer the total, and asks for payment.
 7. Customer pays and System handles payment.
 8. System logs completed sale and sends sale and payment information to
    the external Accounting and Inventory systems.
 9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
Extensions:
 *a. At any time, System fails: (recovery steps)
 3a. Invalid identifier:
     1. System signals error and rejects entry.
 7a. Paying by cash:
     1. Cashier enters the cash amount tendered.
     2. System presents the balance due, and releases the cash drawer.
     3. Cashier deposits cash tendered and returns balance to Customer.
     4. System records the cash payment.
Special Requirements: Credit authorization response within 30 seconds
 90% of the time. Text visible from 1 meter.
Technology and Data Variations List: 3a. Item identifier entered by bar
 code laser scanner or keyboard.
Frequency of Occurrence: Could be nearly continuous.
Open Issues: What are the tax law variations?

Exam Trap #2: Branching inside the main success scenario.

WRONG:   3. Cashier enters item ID. If the ID is invalid, the system shows an error.
CORRECT: 3. Cashier enters item identifier.
         Extensions:
         3a. Invalid identifier:
             1. System signals error and rejects entry.

Exam Trap #3: Treating preconditions as something the use case checks. Preconditions are assumed true and are not tested within the use case.

Writing Guidelines

Four Rules From the Lecture

Keep user interface details out: write the intent (“authenticate oneself”), not the mechanism of a login screen.
Focus on intent: do not specify a mechanism.
Write terse use cases: full sentences are not required.
Write black-box use cases: no internal workings, components, or design; do not make design decisions during requirements.

Exam Trap #4: UI and design details in the steps.

WRONG:   4. Cashier clicks "Add"; system inserts a row into the SALES table.
CORRECT: 4. System records sale line item and presents item description,
            price, and running total.

Finding Use Cases

The Procedure

Choose the system boundary: just the software application, hardware and application as a unit, or the entire organization? Naming the external primary and supporting actors makes the boundary clearer. For example, payment authorization is not inside the POS boundary: there is an external payment authorization service actor.
Find the primary actors and their goals: ask “who uses the system and what are their goals?”, not “what are the tasks?”. Nouns and verbs in informal descriptions help.
Define the use cases: one use case per user goal, named like the goal, starting with a verb (Process Sale).

Right-Sizing: Boss, EBP, and Size Tests

A common mistake is a scope that is too large or too small. The lecture’s rules of thumb:

Boss test: your boss asks “what have you been doing all day?” The answer should be an item of business worth reporting. “Logging in” does not make the boss happy.
EBP test (elementary business process): a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.
Size test: a use case usually contains many steps; fully dressed, it is often 3 to 10 pages.
Exception: subfunction use cases such as “paying by credit” are acceptable. The textbook says they are worth writing when several user-goal use cases repeat them or need them as a precondition.

Applying the tests to the lecture’s examples:

Candidate	Verdict
Negotiate a supplier contract	too large: many sessions over days, beyond one EBP
Handle returns	right size: passes the boss, EBP, and size tests
Log in	too small: fails the boss test; a subfunction
Move piece on game board	too small: a single step; fails the size test

Exam Trap #5: Making “Log In” a user-goal use case. It is a subfunction that serves real goals such as Process Sale or Cash In.

Use Case Diagrams

Notation

A UML use case diagram illustrates the names of use cases and actors and the relationships between them. It is secondary: doing use case work means writing text.

                 +------------- NextGen -------------+
      O          |                                   |      +-----------------+
     /|\  -------|---------( Process Sale )----------|------| «actor»         |
     / \         |                                   |      | Payment         |
   Cashier       |              ( ... )              |      | Authorization   |
                 |                                   |      | Service         |
                 +-----------------------------------+      +-----------------+
 primary actors on the left                         supporting actors on the right

the system boundary is a box labeled with the system name,
use cases are ovals; actors are stick figures,
solid lines show communication between an actor and a use case,
computer-system actors can use a class box with «actor» (or a stick figure with «system») for visual distinction,
put primary actors on the left and supporting actors on the right,
in a use case context diagram, limit the use cases to user-goal level.

The Monopoly example is a single Observer actor with one use case, Play Monopoly Game. Most detail (the domain rules) is deferred to the Supplementary Specification.

Use Cases in Iterative Development

How the UP Uses Them

Functional requirements are recorded in use cases.
Iteration planning chooses use case scenarios or entire use cases as the work of an iteration.
Use cases influence the organization of user manuals, and testing builds on use case scenarios.
Requirements discovery and building parts of the system interleave.

How Much Is Written, When

The lecture’s Table 6.1 (a sample, not a recipe): in inception, a 2-day workshop names most use cases and writes only 10% in detail. By the end of elaboration iterations 1, 2, 3, and 4, about 30%, 50%, 70%, and 80-90% are written in detail. The production core of the system is started when only about 10% of the requirements are detailed.

Key Insight: Starting production-quality development long before all requirements are known is the key difference between iterative development and waterfall.

Exam-Style Practice Problems

Problem 1: Casual Use Case

Question: The Fall 2024 Midterm 1 study sheet: for a computer chess game played by a single player, where you start a new game, you and the computer keep making moves, and the game ends when one side reaches checkmate, write a “Play Game” use case in casual format.

Answer:

Play Game

Main Success Scenario: The Player starts a new game. The System sets up the
board. The Player makes a move; the System validates it, updates the board,
and makes its own move. Player and System keep alternating moves until one
side reaches checkmate. The System announces the result and ends the game.

Alternate Scenarios:
If the Player enters an illegal move, the System rejects it and asks again.
If the Player resigns, the System ends the game as a loss for the Player.

Problem 2: Use Case Diagram

Question: The study sheet’s taxi fleet scenario has drivers, taxis owned by the company, assignments of drivers to taxis, and whether a taxi is occupied. Draw a use case diagram for the most common use cases (plausible ones are accepted).

Answer: one plausible set:

                    +------------- Taxi Fleet System -------------+
 Fleet Manager -----|---( Assign Driver to Taxi )                 |
 Fleet Manager -----|---( Manage Drivers )                        |
 Fleet Manager -----|---( Manage Taxis )                          |
 Driver ------------|---( Update Taxi Status )  (occupied / free) |
 Dispatcher --------|---( Find Available Taxi )                   |
                    +---------------------------------------------+

Draw each actor once as a stick figure on the left, with one line to each of its use cases.

Problem 3: Name the Actors

Question: In Process Sale, classify the Cashier, the Payment Authorization Service, and the government tax agency.

Answer: Cashier: primary. Payment Authorization Service: supporting. Tax agency: offstage.

Common Exam Traps

1. Use Cases Are Text

WRONG:   "Use case modeling means drawing use case diagrams."
CORRECT: "Use case modeling means writing text; diagrams are secondary."

Why: The slides stress this point on three separate slides.

2. Use Cases Are Not Object-Oriented

WRONG:   "Writing use cases is OO analysis."
CORRECT: "Use cases are stories; OO analysis starts with the domain model."

Why: There is nothing object-oriented about use cases.

3. The Three Formats

WRONG:   formats = black-box, white-box, user-goal
CORRECT: formats = brief, casual, fully dressed

Why: Black-box is a visibility type and user-goal is a level; the study sheet asks for formats.

4. Preconditions Are Not Tested

WRONG:   Main step 1: "System checks that the cashier is logged in."
CORRECT: Preconditions: Cashier is identified and authenticated.

Why: Preconditions are assumptions, usually the result of another use case.

5. No Branching in the Happy Path

WRONG:   "If paying by cash, ... ; if paying by credit, ..." inside step 7
CORRECT: 7a. Paying by cash: ...   7b. Paying by credit: ...

Why: Defer all conditional and branching statements to Extensions.

6. No UI or Design Decisions

WRONG:   "Cashier presses the green Enter key"; "System runs SQL INSERT"
CORRECT: "Cashier enters item identifier"; "System records the sale"

Why: Use cases are black-box and focus on intent.

7. Wrong Scope

WRONG:   use cases named "Log In" or "Move Piece"
CORRECT: use cases at EBP level, such as "Process Sale" or "Play Game"

Why: They fail the boss and size tests.

8. The Primary Actor Depends on the Boundary

WRONG:   "The customer is always the primary actor of Process Sale."
CORRECT: POS system boundary: Cashier; enterprise boundary: Customer

Why: The system boundary decides whose goal the system serves.

9. Supporting vs Offstage

WRONG:   tax agency = supporting actor
CORRECT: tax agency = offstage (interested, but does not interact or serve)

Why: A supporting actor provides a service to the system, such as payment authorization.

Final Tips for the Midterm

Memorize the three definitions: actor, scenario (use case instance), use case.
Know the three formats with one example each: brief (Process Sale), casual (Handle Returns), fully dressed (UC1).
Know the fully dressed section names in order: scope, level, primary actor, stakeholders and interests, preconditions, success guarantee, main success scenario, extensions, special requirements, technology and data variations.
Use extension labels correctly: 3a for step 3, *a for any step, each with a condition and a handling.
Size with the three tests: boss, EBP, size; know which lecture examples fail.
Draw use case diagrams quickly: boundary box, ovals, stick figures, primary left, supporting right.

Good luck on the midterm! You’ve got this.