Advanced Use Case Lab

Quality Use Cases

What Makes a Good Use Case

A good use case tells a clear, complete story of an actor achieving a goal — written at the right level, focused on observable value, free of design detail, and readable by both business and technical stakeholders.

Readability

High-quality use cases use plain, active language and a consistent step structure so any stakeholder can follow the interaction without specialized knowledge or ambiguity.

Observable Value

Each use case must deliver a result of value to an actor. If a candidate use case produces nothing the actor cares about, it is probably a fragment, a subfunction, or design detail.

Goal Level Discipline

Most use cases should be written at user-goal ('sea') level — what an actor accomplishes in one sitting. Mixing summary and subfunction levels in one use case is a common quality problem.

Essential vs. Concrete Use Cases

Essential use cases describe intent independent of technology (e.g., 'identify self'); concrete ones embed UI/implementation detail (e.g., 'enter PIN'). Keep specifications essential to avoid premature design.

Writing Technique

Step Writing Style

Each step should be a simple subject-verb-object statement describing one interaction, written from a neutral point of view and at a consistent level of detail.

Avoiding UI and Design in Use Cases

Use cases should state what the actor and system do, not how the screen looks or how data is stored. Embedding UI/design detail makes use cases brittle and harder to maintain.

Right Level of Detail

Use cases should be detailed enough to be testable and unambiguous but not so granular they become design specs. Finding this balance is a core advanced skill.

Naming Use Cases

Name use cases with a strong verb-noun phrase that reflects the actor's goal (e.g., 'Withdraw Cash'), making the model's intent immediately clear.

Consistent Point of View

Maintain a single, consistent narrative perspective (typically the actor's interaction with the system as a black box), avoiding shifts that confuse readers and reviewers.

Flows & Structure

Managing Alternate Flows

Organize alternate and exception flows clearly, tying each to the basic-flow step it branches from, so complex behavior remains traceable and complete without overwhelming the reader.

Extension Points

Named locations in a base use case where extending behavior can attach. Using extension points well keeps optional and conditional behavior organized and decoupled.

Using Include Correctly

Apply the include relationship to factor genuinely shared behavior (like 'Authenticate User') out of multiple use cases — not to decompose a single use case into tiny functional steps.

Using Extend Correctly

Apply the extend relationship for truly optional or exceptional behavior that the base use case shouldn't depend on. Overuse of extend fragments the model and reduces readability.

Avoiding Functional Decomposition

A frequent mistake is shredding a use case into many include/extend fragments resembling a function call tree. Use cases should stay goal-oriented stories, not decomposed functions.

Common Mistakes

Common Use Case Mistakes

Typical errors include too much UI detail, wrong goal level, missing alternate flows, vague steps, no clear value to the actor, overuse of include/extend, and CRUD-style fragmentation.

CRUD Use Cases

Splitting trivial Create/Read/Update/Delete operations into separate use cases usually adds noise. These are often better combined into a single 'Manage X' use case unless each truly delivers distinct value.

Use Case vs. Requirement Confusion

Not every requirement is a use case. Quality constraints and rules belong in supplementary specs or as special requirements, not forced into the use-case flow.

Premature Detail

Adding deep detail to every use case before priorities and architecture are known wastes effort. Detail the high-priority, high-risk use cases first.

Inconsistent Granularity

Mixing high-level summary steps with fine-grained subfunction steps in the same flow confuses readers and breaks testability. Keep steps at a uniform altitude.

Patterns

Use Case Patterns

Reusable approaches for recurring requirement situations — such as handling authentication, search, complex business rules, or long-running transactions — that produce consistent, high-quality use cases faster.

Business Rules Handling

A pattern for keeping complex or volatile business rules out of the use-case narrative — referencing them so the flow stays readable and the rules can change independently.

Handling Complex Conditions

Techniques for representing decision-heavy behavior (e.g., separate alternate flows, decision tables, or referenced rules) instead of cramming nested logic into prose steps.

Reuse Through Generalization

Carefully applying actor or use-case generalization to capture shared behavior, used sparingly to improve reuse without obscuring the model.

Reviewing & Improving

Reviewing Use Cases

Systematically inspecting use cases for completeness, correct level, clear value, handled exceptions, and absence of design detail — then revising to raise quality.

Refactoring Use Cases

Restructuring existing use cases to improve clarity and maintainability — merging fragments, removing UI detail, fixing levels, and reorganizing flows — without changing intended behavior.

Testability of Use Cases

Well-written use cases enable test design: each scenario (basic and alternate flows) becomes a test case, and clear pre/postconditions define expected results.

From Use Cases to Test Cases

Deriving test cases by walking each scenario through the use case, covering the basic flow plus alternate and exception flows to achieve thorough functional coverage.

Completeness Checking

Verifying that every step has defined outcomes, every condition is handled, and every actor goal is satisfied, so no behavior is left ambiguous or missing.

Productivity

Writing Use Cases Quickly

Experienced analysts develop high-quality use cases efficiently by starting from goals, drafting the basic flow first, deferring detail, applying patterns, and iterating with reviewers.

Hands-On Lab Approach

This course emphasizes practice over theory — most time is spent revising and writing real use cases and applying techniques, which optimizes retention of the skills taught.

Prerequisite Foundation

The lab assumes prior exposure — ICON's 'Defining & Managing Requirements with Use Cases' or 'Introduction to Use Cases,' or at least two months of hands-on use-case experience.