Fully Dressed Use Case Template (Cockburn)
One actor goal: scope, level, stakeholders and interests, guarantees, main scenario, lettered extensions, variations
Cách dùng: Use it to specify one user goal in depth when edge cases and failure handling matter. Write the main success scenario first, then brainstorm extensions for every step. The main pitfall is putting user interface detail and if-branches in the main scenario.
Xem trước
Use Case: UC-[nn] [Verb phrase goal, for example Withdraw cash]
Fully dressed use case specification following the format described by Alistair Cockburn in Writing Effective Use Cases. It records one actor's goal, every stakeholder's interest, the main success scenario and all extensions. Replace every
[bracketed]value and every line marked Example.
| Field | Value |
|---|---|
| Use case ID | UC-[nn] |
| Version | [0.1] |
| Status | [Draft / Reviewed / Approved] |
| Author | [@name] |
| Last updated | YYYY-MM-DD |
| Related use cases | [UC-nn includes / extends UC-nn] |
| Source requirements | [BR-nnn, STK-UR-nnn] |
1. Goal in context
[Longer statement of the goal and the situation in which it arises.]
Example: A bank customer wants to withdraw cash from their current account at an ATM, quickly and without errors, and leave with the right amount, their card and a correct balance.
2. Scope and level
| Attribute | Value |
|---|---|
| Scope | [System under design, for example ATM network system, black box] |
| Level | [User goal / Summary / Subfunction] |
| Primary actor | [Actor with the goal, for example Account holder] |
| Supporting actors | [Bank core system, card network] |
3. Stakeholders and interests
| Stakeholder | Interest |
|---|---|
| Example: Account holder | Gets the requested cash quickly; account debited exactly once and only if cash is dispensed |
| Example: Bank | Withdrawal is authorised, limits enforced, every transaction is auditable |
| Example: Card network | Message formats followed; fees recorded |
| Example: Regulator | Customer data protected; disputes can be resolved from records |
| [Stakeholder] | [Interest] |
4. Conditions and trigger
| Item | Statement |
|---|---|
| Preconditions | Example: ATM is in service and has a connection to the bank. |
| Minimal guarantee | Example: Every attempt is logged; the account is never debited for cash not dispensed; the card is returned or retained with a record. |
| Success guarantee | Example: Customer has cash, card and receipt; account debited by the amount; ATM cash balance reduced. |
| Trigger | Example: Customer inserts a card. |
5. Main success scenario
- Customer inserts card.
- System reads the card and asks for the PIN.
- Customer enters the PIN.
- System validates the PIN with the bank and presents transaction options.
- Customer selects "Withdraw" and enters an amount.
- System checks the amount against the account balance, daily limit and cash available, and requests authorisation from the bank.
- Bank authorises and debits the account.
- System returns the card, dispenses the cash and prints a receipt.
- Customer takes card, cash and receipt.
- System logs the transaction and returns to the welcome screen.
6. Extensions
| ID | Condition | Handling |
|---|---|---|
| *a | Customer cancels at any step before 7 | 1. System returns the card. 2. Use case ends; nothing debited. |
| *b | Power failure | 1. System completes or reverses any in-flight bank transaction on restart. 2. Use case ends with minimal guarantee. |
| 2a | Card unreadable | 1. System returns card and shows "Card could not be read". 2. Use case ends. |
| 2b | Card reported stolen | 1. System retains card and logs event. 2. Use case ends. |
| 4a | Wrong PIN, fewer than 3 attempts | 1. System shows remaining attempts. 2. Return to step 3. |
| 4b | Wrong PIN, third attempt | 1. System retains card and notifies the bank. 2. Use case ends. |
| 5a | Amount not a multiple of available notes | 1. System suggests nearest valid amounts. 2. Return to step 5. |
| 6a | Amount exceeds balance or daily limit | 1. System shows the maximum allowed. 2. Return to step 5. |
| 6b | Bank does not respond within 30 s | 1. System returns card with "Service unavailable". 2. Use case ends; nothing debited. |
| 8a | Dispenser jams after debit | 1. System reverses the debit with the bank. 2. ATM goes out of service and alerts operations. 3. Use case ends with minimal guarantee. |
| 9a | Customer does not take cash within 30 s | 1. System retracts cash and reverses the debit. 2. Use case ends. |
| [n][x] | [Condition] | [Handling steps and rejoin point] |
7. Technology and data variations
| Step | Variation |
|---|---|
| 1 | Example: Contactless card or mobile wallet instead of inserted card |
| 3 | Example: Biometric verification where the bank supports it |
| 8 | Example: Receipt sent to the banking app instead of printed |
| [n] | [Variation] |
8. Related information
| Item | Value |
|---|---|
| Frequency of occurrence | Example: About 400 per ATM per day; peaks Friday 17:00 to 19:00 |
| Priority | [Must / Should / Could] |
| Performance target | Example: Steps 6 to 8 complete within 10 s at p95 |
| Channels | [ATM, branch kiosk] |
| Superordinate use case | [UC-nn, summary level] |
| Subordinate use cases | [UC-nn Validate PIN, UC-nn Print receipt] |
9. Use case diagram
The diagram shows this use case with its actors and the related use cases it includes or is extended by.
10. Open issues
| ID | Issue | Owner | Due | Resolution |
|---|---|---|---|---|
| OI-01 | Example: Should the daily limit be shown before the amount is entered? | [@product-owner] | YYYY-MM-DD | [Open] |
| OI-02 | Example: Confirm retraction rules with the cash handling vendor | [@ops-lead] | YYYY-MM-DD | [Open] |
| [OI-nn] | [Issue] | [@name] | YYYY-MM-DD | [Resolution] |
11. Review checklist
- The name is an active verb phrase stating the primary actor's goal.
- Every stakeholder interest is protected by a step, guarantee or extension.
- The main success scenario has 3 to 9 steps without "if".
- Every step can fail; failures are listed as extensions or justified as impossible.
- No user interface detail appears in steps.
- Preconditions are not re-checked in the scenario.
Standard and licence note
Based on the fully dressed use case format described by Alistair Cockburn in Writing Effective Use Cases (Addison-Wesley, 2001). The structure is a widely used convention; this template is original text written for this collection and reproduces no text from the book. Template licence: MIT.
Template liên quan
Functional Specification Document (FSD) Template
Roles and permissions matrix, per-feature flows, business rules, validation, messages, data fields, reports, notifications
Yêu cầu & Phân tíchBusiness Requirements Specification (BRS) Template
Business purpose, measurable objectives, processes, rules, business requirements with attributes, success metrics (BRS/BRD)
Yêu cầu & Phân tíchConcept of Operations (ConOps) Template
Current situation, justification for change, proposed operations, step-by-step scenarios, impacts and alternatives