Use Case

Definition

In business and enterprise architecture, a use case is a bounded description of an interaction between an actor — a user, role, system, or external party — and a capability, process, or application, structured around a specific goal and the sequence of steps (including alternate and exception paths) needed to reach it. A well-formed use case names the actor, states the trigger or precondition, walks through the primary flow, and documents what 'success' and 'failure' look like from that actor's perspective. Use cases sit at a specific altitude in the architecture stack: below strategy and capabilities, but above low-level system logic. They are the connective tissue between what an organization is capable of doing (capabilities) and how that capability gets exercised in a real scenario by a real actor. This makes them indispensable for requirements gathering, solution design, testing, and training — but architects should resist the temptation to treat every use case as an architectural artifact. A use case is a scenario, not a structural building block; it doesn't belong in the same category as a capability map or an operating model, though it draws on both. A critical boundary: use cases are actor-centric and goal-oriented, whereas processes are activity-centric and end-to-end. A single business process may be exercised through several distinct use cases (one per actor type or channel), and a single use case may touch multiple processes or capabilities. Architects who blur this distinction end up with documentation that duplicates process models without adding decision value — the hallmark of a use case done right is that it clarifies a specific interaction that a process model, on its own, leaves implicit.

Origin & Context

The use case originated in software engineering, formalized by Ivar Jacobson in the late 1980s and later incorporated into the Unified Modeling Language (UML) as a diagramming and specification technique for capturing functional requirements. Enterprise and business architects adopted the concept from systems analysis practice, and it now appears in the Business Architecture Guild's BIZBOK Guide and in TOGAF-based requirements management as a bridge between business capability and solution requirement. Its migration from a purely software artifact to a business architecture tool reflects the broader shift toward requirements traceability from strategy through to system design.

Why It Matters

Business architects use use cases to validate that capability and process models actually hold up when exercised by real actors — a capability map can look complete on paper and still fail the moment a specific customer, regulator, or partner interaction is worked through. Solution architects and CIOs rely on well-documented use cases to scope system requirements accurately, reducing costly rework and scope creep during implementation. Compliance and risk teams use use cases to demonstrate that regulatory scenarios (a specific type of claim, a specific disclosure trigger) are explicitly covered, not assumed. Poorly defined use cases are a leading cause of requirements gaps that surface late in testing or, worse, in production.

Common Misconceptions

Myth: A use case is the same thing as a business process.

Reality: A process describes an end-to-end sequence of activities that produce a business outcome, regardless of who performs each step. A use case describes one actor's specific interaction and goal within (or across) one or more processes. Mapping a single process may require several use cases to cover different actors, channels, or exception scenarios.

Myth: Use cases are a technology/software concern and don't belong in business architecture.

Reality: While the term originated in software engineering, business architects use use cases to validate capabilities and value streams against real-world scenarios before solutions are designed. Skipping this step in business architecture often means requirements gaps only surface after IT has already built something.

Myth: Writing more use cases produces better requirements.

Reality: Value comes from covering the actors and scenarios that matter most — including edge cases with real business or regulatory consequence — not from volume. Architects should prioritize use cases tied to high-risk, high-frequency, or high-variability interactions rather than documenting every conceivable path.

Practical Example

A regional bank's business architecture team was mapping the 'Originate Loan' capability ahead of a core banking replacement. The capability map alone didn't reveal why loan officers kept escalating exceptions to underwriting. The team documented a use case for 'Branch Loan Officer Submits Application for a Self-Employed Applicant,' detailing the trigger, the additional income-verification steps, alternate paths for incomplete documentation, and the exception flow to manual underwriting. This surfaced a gap: the target system's standard workflow assumed salaried applicants only. The solution architect used the use case directly in requirements documentation, and the vendor configuration was adjusted before build rather than after user acceptance testing — avoiding a rework cycle that would have delayed the branch rollout.

Industry Applications

Financial Services

Used to document channel-specific and regulatory scenarios (e.g., KYC verification for a high-risk customer segment) that a generic process model would otherwise gloss over.

Healthcare

Applied to capture provider, payer, and patient interactions with capabilities like Prior Authorization, ensuring system requirements account for urgent versus standard care pathways.

Insurance

Used to define distinct claims-handling scenarios (first-notice-of-loss by phone versus mobile app versus agent) that share a capability but require different system and process support.

Related Terms

• Business Capability: the underlying ability that a use case demonstrates being exercised in a scenario