use-case-2.0

What this skill does

# Use Case 2.0

A modern, lightweight approach to use case modeling that integrates with agile practices while preserving the benefits of structured requirements.

## When to Use This Skill

**Keywords:** use case, use case 2.0, Ivar Jacobson, use case slice, narrative, basic flow, alternate flow, exception, actor, goal, scenario, precondition, postcondition, trigger, user story from use case

**Use this skill when:**

- Modeling system behavior from user perspective
- Deriving user stories from use cases
- Planning releases using use case slices
- Documenting complex interactions with multiple paths
- Understanding actor goals and system responses
- Creating testable requirements from narratives

## What is Use Case 2.0?

Use Case 2.0 modernizes classic use cases for agile contexts while retaining their power for:

- Capturing functional requirements comprehensively
- Understanding system boundaries and actors
- Identifying all paths through a scenario (happy path + alternatives + exceptions)
- Creating traceable, testable specifications

### Key Principles

| Principle | Description |
|-----------|-------------|
| **Slice-based** | Use cases are implemented in slices, not all at once |
| **Lightweight** | Start simple, add detail only when needed |
| **Story-compatible** | User stories can be derived from use case slices |
| **Test-first** | Each slice is testable before implementation |
| **Value-driven** | Slices prioritized by business value |

## Use Case 2.0 Lifecycle

```text
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   FIND       │ →  │   SLICE      │ →  │   PREPARE    │
│ Use Cases    │    │ Use Cases    │    │ Use Case     │
│              │    │              │    │ Slices       │
└──────────────┘    └──────────────┘    └──────────────┘
                                               │
                    ┌──────────────┐    ┌──────┴───────┐
                    │   INSPECT    │ ←  │   ANALYZE    │
                    │   & ADAPT    │    │   Slices     │
                    └──────────────┘    └──────────────┘
```

### Phase Details

```yaml
use_case_lifecycle:
  find:
    purpose: "Identify use cases from goals and actors"
    activities:
      - "Identify actors (primary, supporting, offstage)"
      - "Capture actor goals"
      - "Name use cases (verb-noun)"
      - "Create use case diagram"
    output: "Use case model (diagram + brief descriptions)"

  slice:
    purpose: "Break use cases into implementable slices"
    activities:
      - "Identify basic flow (happy path)"
      - "Identify alternative flows"
      - "Identify exception flows"
      - "Group flows into slices"
    output: "Sliced use cases with prioritization"

  prepare:
    purpose: "Detail slices for implementation"
    activities:
      - "Write narrative for selected slice"
      - "Define test cases"
      - "Identify special requirements"
    output: "Ready-for-development slice"

  analyze:
    purpose: "Verify slice is implementable"
    activities:
      - "Review with stakeholders"
      - "Validate test cases"
      - "Confirm acceptance criteria"
    output: "Validated slice"

  inspect_adapt:
    purpose: "Learn and improve"
    activities:
      - "Review implemented slices"
      - "Update use case model"
      - "Refine remaining slices"
    output: "Updated backlog"
```

## Use Case Elements

### Actor Types

```yaml
actor_types:
  primary_actor:
    definition: "Actor whose goal the use case satisfies"
    examples:
      - "Customer placing an order"
      - "Administrator managing users"
    notation: "Stick figure connected to use case"

  supporting_actor:
    definition: "Actor that provides a service to the system"
    examples:
      - "Payment Gateway processing payment"
      - "Email Service sending notifications"
    notation: "Stick figure connected to use case (labeled)"

  offstage_actor:
    definition: "Actor with interest but no direct interaction"
    examples:
      - "Auditor requiring transaction logs"
      - "Regulator requiring compliance"
    notation: "Listed in stakeholders section"
```

### Use Case Brief

Lightweight initial documentation:

```yaml
use_case_brief:
  template:
    id: "UC-{domain}-{number}"
    name: "{Verb} {Noun}"
    primary_actor: "{Actor name}"
    goal: "{What the actor wants to achieve}"
    brief_description: "{1-2 sentences}"

  example:
    id: "UC-ORD-001"
    name: "Place Order"
    primary_actor: "Customer"
    goal: "Purchase products from the catalog"
    brief_description: "Customer selects products, provides shipping and payment information, and submits order for processing."
```

### Use Case Narrative

Full documentation format:

```markdown
## Use Case: {Name}

**ID:** UC-{XXX}-{NNN}
**Version:** {N.N}

### Overview

| Element | Description |
|---------|-------------|
| **Primary Actor** | {Actor name} |
| **Goal** | {What the actor wants to achieve} |
| **Scope** | {System boundary} |
| **Level** | {User goal / Subfunction / Summary} |
| **Trigger** | {What starts the use case} |

### Stakeholders and Interests

- **{Stakeholder 1}**: {Interest/concern}
- **{Stakeholder 2}**: {Interest/concern}

### Preconditions

- {Condition that must be true before use case can start}
- {Another precondition}

### Success Guarantee (Postconditions)

- {Condition guaranteed to be true after successful completion}
- {Another postcondition}

### Basic Flow (Main Success Scenario)

1. {Actor} {action}
2. System {response}
3. {Actor} {action}
4. System {response}
5. ...
6. System {final response indicating success}

### Alternative Flows

#### {Alternative Name} (at step {N})

**Condition:** {When this alternative applies}

{N}a. {Alternative action}
{N}b. System {alternative response}
{N}c. Return to step {M} / Use case ends

#### {Another Alternative} (at step {N})

...

### Exception Flows

#### {Exception Name} (at step {N})

**Condition:** {When this exception occurs}

{N}a. System {error detection}
{N}b. System {error handling}
{N}c. Use case ends in failure / Return to step {M}

### Special Requirements

- {Non-functional requirement affecting this use case}
- {Performance, security, usability requirement}

### Technology and Data Variations

- {Step N}: {Variation in technology or data format}

### Related Information

- **Frequency:** {How often this use case occurs}
- **Related Use Cases:** {Links to included/extended use cases}
- **Business Rules:** {BR-xxx, BR-yyy}
```

## Use Case Slicing

### What is a Slice?

```yaml
use_case_slice:
  definition: "A subset of a use case that delivers value and is independently testable"

  characteristics:
    - "Implements part of use case flows"
    - "Can be developed in one iteration"
    - "Has clear acceptance criteria"
    - "Delivers incremental value"

  slice_types:
    basic_flow_slice:
      description: "Happy path only (simplest implementation)"
      example: "Place Order - basic checkout with existing customer"

    flow_variation_slice:
      description: "Basic flow + one alternative"
      example: "Place Order - with new customer registration"

    exception_slice:
      description: "Basic flow + exception handling"
      example: "Place Order - payment declined handling"

    complete_slice:
      description: "Full use case with all paths"
      example: "Place Order - complete implementation"
```

### Slicing Strategies

```yaml
slicing_strategies:
  by_actor:
    description: "Different slices for different actors"
    example: "Customer checkout vs. Admin override checkout"

  by_data_variation:
    description: "Different data types or volumes"
    example: "Single item order vs. bulk order"

  by_business_rule:
    description: "Different rules applied"
    example: "Standard pricing vs. promotional pricing"

  by_interface:
    description: "Different UI or integration points"
    example: "Web checkout vs. API checkout"

  by_quality:
    description: "Different quality attributes"
    example: "Basic validat