COMPUTING SCIENCE 220
Software Engineering and Human-Computer Interfaces

Use-Case Model

Definitions

use cases

stories of using a system to meet stakeholder goals

introduced by Ivar Jacobson, 1986

Use Case Model

the set of all use cases (a UP artifact within the Requirements discipline)

actor

something with behavior, such as a person (identified by role), computer system, or organization

primary actor

has user goals fulfilled through using the services of the system

may be an external computer system

supporting actor

provides a service (information) to the system

offstage actor

has an interest in some behavior of the system, but is not primary or supporting

The system itself may be an actor when it calls on the services of other systems.

scenario

a specific sequence of actions and interactions between actors and the system under discussion that yields an observable result of value to a particular actor; a use case instance

main success scenario (basic flow): the main flow of events leading to a successful outcome
extensions (alternative flows): different flows of events that may or may not lead to success

use case

a collection of related success and failure scenarios that describe actors using a system to support a goal; a set of use-case instances

black-box use cases

use cases that describe the system as having responsibilities, specifying what the system must do (functional requirements)

white-box use cases

use cases that describe the internal workings of the system, its components or design, specifying how the system will work

Goals and Scope of a Use Case

Focus on the question, "How can using the system provide observable value to the user, or fulfill their goals?" rather than thinking of the system requirements as a list of features or functions.
Focus on use cases at the level of the elementary business process (EBP):
- a task performed by one person in one place at one time
- in response to a business event
- adds measurable business value
- leaves the data in a consistent state
Define one EBP-level use case for each user goal, and name the use case after the goal, starting with a verb (e.g., "Process Sale").
Exceptions:
- A subtask that occurs in several base use cases can be factored out into its own use case to avoid duplication.
- Collapse CRUD goals - create, retrieve, update, delete - goals into a single use case, named "Manage X".

Identifying Use Cases

Choose the system boundary: what is internal and what is external?
Identify the primary actors and their EBP-level user goals.

See the list of questions to help identify actors and goals on pp. 83–84.
It may help to identify external events and group them into EBP-level goals.

Define use cases that satisfy user goals.

Formality Types

brief: a terse, one-paragraph summary, usually of the main success scenario (see p. 63)
casual: informal, multi-paragraph format, covering various scenarios (see pp. 63–64)
fully dressed: an elaborate format, with all steps and variations written in detail (see pp. 67–72)

Style

essential: narrative is expressed at the level of the user's intentions and the system's responsibilities, without reference to technology and mechanism details (especially the UI)
concrete: user interface decisions are embedded in the use case text as an aid to detailed GUI design work