/use-case-writer

name: use-case-writer
description: Generate Use Case specifications in English Markdown following the IT BA standard 13-field template (Karl Wiegers / IIBA). Use whenever a BA needs to scope, analyze, document, refine, or review a Use Case. Triggers include "write a use case", "draft UC", "use case specification", "analyze UC scope", "split feature into use cases", "review my UC", "write normal course / alternative course / exceptions", "define actors", and Vietnamese equivalents like "viết use case", "viết UC", "đặc tả use case", "phân tích use case", "review UC". Also trigger when user pastes a feature/BRD/PRD and asks to turn it into UCs. Skill enforces Cockburn's guidelines (coffee-break test, goal levels) and runs a 20-point quality checklist. Output is English Markdown with 13 fields (Actor, Description, Pre/Postconditions, Priority, Frequency, Normal/Alternative Courses, Exceptions, Includes, Special Req, Assumptions, Notes). DO NOT use for Agile User Stories, PRD/URD/SRS, or UML diagrams.
author: Phúc NT @ BA Zone
source: https://github.com/ba-zone

Use Case Writer — Skill for IT Business Analysts

> by **Phúc NT** · BA Zone · Digital School

This skill helps IT BAs **scope, analyze, and document Use Cases** in English Markdown following the standard 13-field template (Karl Wiegers / IIBA style), with best practices from Alistair Cockburn's "Writing Effective Use Cases" and the IIBA BABOK Guide.

Developed by **Phúc NT** as part of the **Digital School** training program by **BA Zone** — Vietnam's Business Analyst & Product Owner community.

When to use this skill

Trigger this skill whenever the user needs to:

• Draft a new UC from a feature description, BRD, or PRD
• Refine or review an existing UC (completeness, correctness)
• Split a large feature into multiple smaller UCs (scope identification)
• Write a specific section: Normal Course, Alternative Course, Exceptions
• Validate a UC against the quality checklist

Output rules (non-negotiable)

1. **Language**: English. Even if the user types in Vietnamese, generate the UC document in English. Use Vietnamese only when chatting with the user about the process. 2. **Format**: Markdown (`.md`). Use the 2-column table layout that mirrors the original template. 3. **Mode**: Sequential — generate section by section, **stop and wait for the user to confirm** before moving on. Never dump a full UC in one shot unless the user explicitly says "give me the full UC at once".

---

Workflow: 4 Steps

Step 1: CLASSIFY INPUT     →  identify which mode the user is in
Step 2: SCOPE THE UC       →  apply 4 scoping rules + coffee-break test
Step 3: WRITE THE UC       →  fill the 13 fields ONE SECTION AT A TIME
Step 4: VALIDATE           →  run the 20-point checklist before handover

---

Step 1: Classify input and pick a mode

Before writing anything, identify which mode the user is in:

| Mode | Signals | Action | |------|---------|--------| | **Mode A: Write new from feature** | User pastes a feature description, BRD, PRD, or says "write UC for feature X" | Go to Step 2 (scope) → Step 3 (write sequentially) | | **Mode B: Split large feature into UC list** | User says "split into UC list", "how many UCs does this feature need", uploads a large PRD | Go deep on Step 2 (apply 3 identification techniques), output the **UC List first**, then ask the user which UC to write in detail | | **Mode C: Refine / review existing UC** | User pastes an existing UC and asks "review this", "is it complete", "what's missing" | Skip Step 2, go directly to Step 4 (validate checklist) | | **Mode D: Write a specific section** | User says "write the Normal Course for this UC", "add Exceptions" | Read the UC context, jump to the relevant part of Step 3 |

**Golden rule**: If input is vague (just one line), **ASK before writing** — never make things up. Ask at most 3 questions: 1. Who is the primary actor? (specific role / user class) 2. What is the actor's concrete goal in this UC? 3. Which system / module does this UC belong to?

Communicate with the user in their language (Vietnamese or English), but the UC artifact is always English.

---

Step 2: Scope the Use Case

This is the **most important and most error-prone** part of UC writing. Read carefully.

2.1. Four scoping rules

**Rule 1 - Coffee-break test (Alistair Cockburn)** After completing the UC, can the actor take a coffee break without feeling the task is unfinished? If NO → the UC is too low-level (sub-function), merge it. If YES → scope is right (user-goal level).

**Rule 2 - Goal Level (Cockburn's 3 levels)**

• **Summary level (cloud)**: UC spans multiple sessions. E.g. "Manage course enrollment lifecycle" → too high, DO NOT write as a single UC.
• **User-goal level (sea level)** ✅: 1 actor, 1 session, achieves 1 business goal. E.g. "Enroll in a Digital School course" → right level for a UC.
• **Sub-function level (fish)**: A small step inside another UC. E.g. "Verify OTP" → too low, treat as Includes inside another UC.

**Rule 3 - One Actor, One Goal, One Session** Each UC should have EXACTLY: 1 primary actor + 1 business goal + completion in 1 continuous session. If you see 2 different goals → split into 2 UCs.

**Rule 4 - System Boundary** A UC describes the **interaction** between actor and system, NOT the system's internals. Each step must be one of:

• Actor does something to the system (input)
• System responds to the actor (output)

If a step has neither actor nor UI → it's a design detail, not part of the UC.

2.2. Three techniques to identify UCs (for Mode B)

When splitting a large feature into a UC list:

**Technique 1: Goal-driven (top-down)** List all goals for each actor → each goal = 1 candidate UC.

**Technique 2: Event-driven (external + internal triggers)**

• External events: user actions (click, submit, scheduled time)
• Internal events: system-triggered (cron job, batch process)

Each event produces a system response → candidate UC.

**Technique