Use Case¶

Represent required externally observable system behavior as an actor pursuing a goal across a system boundary through a main interaction flow plus declared alternatives, exceptions, preconditions, and outcomes.

Version: v2 · 2026-09-06 · History
Domain-specific #: 3047
Origin domain: engineering
Subdomain: requirements engineering
Aliases: Usage case

Core Idea¶

A use case is a requirements representation of how a subject system provides behavior of value to an external actor. UML defines the subject as the system under consideration, actors as external roles or systems that interact with it, and use cases as specifications of required behavior according to actor needs.^[1] The identity therefore couples an external role, a goal, a system boundary, and a behavior contract; a mere example of how a product might be used is too weak.

A developed textual use case commonly states a trigger or precondition, a main success flow, alternate and exception flows, and postconditions or success guarantees. Each step assigns responsibility to actor or subject and remains at the level of externally observable behavior unless design detail is necessary for a contractual reason. Jacobson and colleagues made this goal-and-interaction representation the organizing device of a use-case-driven software-engineering method.^[2] A use-case type describes a family of conforming occurrences; one concrete execution is a use-case instance or scenario. A use-case diagram can summarize actors and relationships, but the oval-and-line picture does not by itself contain the behavioral contract.

Use cases organize functional requirements and validation because stakeholders can ask whether the described goal and outcomes are correct before an implementation is fixed. They are not universal substitutes for quality requirements, data models, state machines, hazards, interface specifications, or algorithms. ISO/IEC/IEEE 29148 places requirements in a broader lifecycle of elicitation, analysis, verification, validation, communication, and management; the use case is one structured information form inside that work.^[3]

Structural Signature¶

The subject. A named system or system-of-interest owns the required behavior.
The boundary. Inside responsibilities are separated from external actors and neighboring systems.
The primary actor. An external role initiates or benefits from the interaction.
The stakeholder goal. A result of value gives the interaction a completion criterion.
The trigger and preconditions. Initial events and valid starting state bound when the behavior applies.
The main success flow. Ordered actor-subject interactions reach the goal under normal conditions.
The alternate and exception flows. Variants and failures are attached to explicit conditions or extension points.
The observable outcome. Postconditions state what the subject guarantees or leaves true after completion.
The abstraction level. The account specifies required behavior without needlessly choosing internal design.
The traceability role. The use case connects stakeholder need to requirements, tests, design elements, and validation evidence.

What It Is Not¶

Not an informal usage example. Engineering use cases require a system boundary, actor role, goal, and behavioral contract.
Not a use-case diagram alone. The diagram shows relationships but usually omits the full flow and guarantees.
Not a user story. A short value statement can seed work but does not normally specify complete interaction flows.
Not a test case. A test selects inputs and expected observations for verification; a use case specifies required behavior.
Not a sequence diagram. Sequence diagrams show message ordering among participants and may realize one scenario.
Not an implementation procedure. Internal classes, algorithms, and screens are excluded unless contractually observable.

Scope of Application¶

The construct is literal in software and systems requirements work where externally initiated, goal-directed behavior must be represented and validated.

Requirements elicitation. Turning stakeholder goals and interactions into reviewable behavior descriptions.
System scoping. Locating actors and responsibilities across a declared boundary.
Functional decomposition. Organizing related required behaviors without prematurely choosing components.
Acceptance planning. Deriving scenarios and observable outcomes for validation.
Architecture dialogue. Exposing cross-system interactions and service responsibilities to designers.
Change impact. Tracing a modified actor goal or flow to requirements, tests, and affected interfaces.

Clarity¶

Give the use case a goal-oriented verb phrase, name the subject and primary actor, state stakeholder interest, preconditions, trigger, main success flow, alternatives, exceptions, and postconditions. Number steps so extensions have explicit attachment points. Write interactions in observable terms and identify which side acts. Do not encode a screen sequence as though it were the requirement unless the interface itself is constrained. Separate reusable subordinate behavior from optional extensions and use UML include/extend relations only with their formal direction and semantics. State the level—business, system, or software—because the same label can otherwise move the boundary silently. Link requirements and tests without claiming that the use case alone exhausts nonfunctional concerns.

Manages Complexity¶

A use case compresses many stakeholder statements into a bounded interaction contract. The actor and goal select relevant behavior; the system boundary assigns responsibility; the main flow shows the ordinary path; and alternate flows keep exception detail attached rather than scattering it across prose. This makes omissions visible: a goal without a success outcome, an actor without a permitted interaction, or an exception without a recovery state can be challenged directly. The representation also supports staged refinement from brief summaries to fully dressed cases and then to tests or sequence realizations. Its compression can fail in two opposite directions. A use case that is too vague becomes marketing language, while one written as click-by-click interface choreography freezes design and misses the underlying intent. Large systems can produce a tangled network of include and extend relationships that is harder to understand than the source requirements. The solution is not maximum detail but disciplined levels, stable goals, explicit boundary decisions, and traceability to complementary models.

Abstract Reasoning¶

Choose the system-of-interest and draw its responsibility boundary.
Identify external actor roles and the stakeholder goal each seeks.
Name the trigger, preconditions, and minimum success guarantee.
Write the main actor-subject interaction flow at an observable level.
Attach alternate and exception flows to explicit conditions or steps.
State postconditions for success, failure, and any partial result.
Review the case for hidden design commitments and missing quality constraints.
Trace approved behavior to requirements, tests, interfaces, and validation evidence.

Knowledge Transfer¶

The strict parent is Representation: a use case maps selected aspects of stakeholder goals and system behavior into a textual or model-based medium under an interpretation convention. The use-case residual is the actor–subject boundary, goal, interaction flows, and outcome contract. Scenario Planning is related at a surface level but constructs alternative futures rather than required system behavior.

Examples¶

Canonical¶

For a library self-service system, the primary actor is a registered borrower and the goal is to renew an eligible loan. Preconditions include an authenticated account and an existing loan. The main flow selects the loan, checks policy, extends the due date, and confirms the result. An alternate flow denies renewal when another patron has a hold; a postcondition preserves the original due date and explains the denial. This is a behavior contract, not a prescription for button placement.

Mapped back: external actor + renewal goal → observable system flow → policy exception → explicit success or denial outcome.

Applied / In Practice¶

A spacecraft ground segment models 'uplink an approved command' at system level. Operators and an external authorization service are actors; validation, scheduling, transmission, acknowledgement, timeout, and rejection are flows. The use case reveals responsibilities across the ground-system boundary and seeds end-to-end tests. Cryptographic algorithms, latency budgets, and hazard controls remain linked requirements rather than being assumed complete because the functional flow exists.^[3]

Mapped back: mission goal → system boundary and actors → success/exception behaviors → traced requirements and validation cases.

Structural Tensions¶

Goal orientation vs. procedural detail. Enough sequence is needed to make behavior testable, but internal choreography can freeze design. Diagnostic: Is each step externally meaningful?
Main flow vs. exception completeness. A clean success story is readable while unmodeled failures undermine the contract. Diagnostic: Are foreseeable deviations attached to conditions and outcomes?
Stable boundary vs. changing architecture. Actor status depends on what the subject includes. Diagnostic: Has a boundary change reclassified any participant?
Readable cases vs. relation networks. Include and extend can reduce duplication or create indirection. Diagnostic: Does each relation improve stakeholder comprehension?
Autonomous representation vs. generic Representation. Representations travel; actor, goal, subject, flow, and postcondition define this residual. Diagnostic: Would the artifact still satisfy UML's use-case identity without those roles?

Structural–Framed Character¶

Use cases are mixed structural and framed. Actor, subject, goal, flows, and outcomes supply a stable modeling structure; the selected boundary, stakeholder value, abstraction level, and writing conventions depend on organizational purposes. The construct is domain-specific because it operates inside requirements and systems modeling, not because its diagram notation is proprietary or because every narrative of use qualifies.

Structural Core vs. Domain Accent¶

The portable skeleton is target behavior → representing medium → interpretation and use. The domain accent is a system subject, external actor, stakeholder goal, trigger, main and alternate flows, postconditions, and lifecycle traceability. Removing them leaves Representation or Scenario; retaining them yields a use case.

Representation is the strict parent because the use-case artifact selectively encodes externally required behavior for stakeholder interpretation and downstream operations. Its system-boundary and goal-directed interaction grammar provide the autonomous engineering residual.

The prospective workspace queue contains one strict upward edge to prime:representation. No live DAG mutation is authorized.

Relationships to Other Abstractions¶

Current abstraction Use Case Domain-specific

Parents (1) — more general patterns this builds on

Use Case is a kind of Representation Prime

Representation is the strict parent because the use-case artifact selectively encodes externally required behavior for stakeholder interpretation and downstream operations.

Hierarchy path (1) — routes to 1 parentless root

Use Case → Representation → Abstraction

Neighborhood in Abstraction Space¶

Use Case sits in a sparse region of the domain-specific corpus (92^nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Use-case diagram. A graphical overview of actors, cases, and relationships, not the full case contract.
Scenario. One particular path or occurrence through a use case.
User story. A compact agile planning statement of role, capability, and value.
Functional requirement. A shall-statement that may be traced to one or more use-case steps.
Activity diagram. A behavioral flow model with token/control semantics rather than actor-goal identity.
Business process. A broader organizational workflow that may contain multiple systems and goals.

References¶

[1] Object Management Group, OMG Unified Modeling Language (OMG UML), Version 2.5.1, formal/2017-12-05, section 18, https://www.omg.org/spec/UML/2.5.1/PDF. registry ↩

[2] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering: A Use Case Driven Approach (Addison-Wesley, 1992), ISBN 978-0-201-54435-0. registry ↩

[3] ISO/IEC/IEEE 29148:2018, Systems and Software Engineering—Life Cycle Processes—Requirements Engineering, 2^nd ed., https://www.iso.org/standard/72089.html. registry ↩a ↩b