Use Case Documentation

用例文档技能

目的

描述用户如何与系统交互以实现特定目标。用例从以用户为中心的角度捕捉功能需求，常用于瀑布式或混合式环境，在这些环境中需要在实施前进行详细规范。

何时使用

• 复杂的事务系统（银行、医疗保健）。
• 需要严格定义特定替代流程和错误处理时。
• 法规合规要求详细文档时。
• 衔接业务需求与技术功能规范。

用例的组成

关键要素

1. 用例名称：动词-名词短语（例如，“取现金”）。
2. ID：唯一标识符（例如，UC-ATM-01）。
3. 参与者：谁会与系统交互？（主要参与者：发起操作；次要参与者：外部系统）。
4. 描述：目标的简要概述。
5. 前置条件：开始之前必须满足什么条件？（例如，“用户已登录”）。
6. 触发条件：什么会启动用例？（例如，“用户点击取款”）。
7. 主要成功场景（基本流程）：“顺利流程”的步骤。
8. 替代流程（扩展）：变化或错误路径。
9. 后置条件：成功完成后满足什么条件？（例如，“余额已更新”）。
10. 业务规则：逻辑关联。

用例模板

示例：在 ATM 取现金

ID：UC-ATM-01 名称：取现金 主要参与者：银行客户 次要参与者：银行系统（后端）

描述：客户通过 ATM 从其支票账户中提取现金。

前置条件：

1. ATM 中有足够的现金。
2. ATM 已联网。
3. 客户持有有效的银行卡和 PIN。

触发条件：客户插入银行卡。

主要成功场景（顺利流程）：

1. 客户插入借记卡。
2. 系统验证卡片是否可读。
3. 系统提示输入 PIN。
4. 客户输入 PIN。
5. 系统向银行系统验证 PIN。
6. 系统显示应用菜单。
7. 客户选择“取现金”。
8. 系统提示输入金额。
9. 客户输入金额（例如，$100）。
10. 系统检查每日限额和账户余额。
11. 系统授权交易。
12. 系统发放现金。
13. 系统打印收据。
14. 系统弹出银行卡。
15. 用例结束。

替代流程：

• A1：PIN 无效（在步骤 5）

  1. 系统显示“PIN 无效”消息。
  2. 系统提示重新输入 PIN。
  3. 客户重新输入 PIN。
  4. 从步骤 5 继续。
  • 约束：如果 PIN 连续输错 3 次，则执行 A2（锁定银行卡）。

• A2：锁定银行卡（来自 A1）

  1. 系统显示“因尝试次数过多，银行卡已锁定”。
  2. 系统保留银行卡。
  3. 用例结束。

• A3：余额不足（在步骤 10）

  1. 系统确定账户余额 < 请求金额。
  2. 系统显示“余额不足”。
  3. 系统提示输入较低金额或取消。
  4. 客户输入新金额。
  5. 从步骤 10 继续。

• A4：ATM 现金不足（在步骤 10）

  1. 系统检查内部现金分配器中的现金是否 > 请求金额。
  2. 系统检测到现金不足。
  3. 系统显示“无法发放全部金额”。
  4. 用例结束。

后置条件：

• 用户账户扣除取款金额。
• 已创建交易日志。
• 现金库存已更新。

用例与用户故事的区别

特征	用例	用户故事
重点	系统交互步骤	用户价值/目标
详细程度	高（流程、错误）	低（用于开启讨论）
格式	文档/结构化文本	卡片/便利贴（谁、什么、为什么）
生命周期	随时间更新/维护	完成后丢弃/归档
适用场景	瀑布式/混合式/复杂场景	敏捷/Scrum

最佳实践

• 使用主动语态：“系统验证 PIN”（而不是“PIN 已通过验证”）。
• 保持界面描述与系统无关：不要说“用户点击右上角的蓝色按钮”，而要说“用户选择选项”。
• 聚焦目标：不要陷入技术细节（例如“系统发送 JSON 数据包”）。
• 关联异常情况：确保处理每条错误路径。

工具

• Lark Docs / MS Word：标准格式设置。
• Visual Paradigm / UML Tools：用于绘制用例图。
• Gherkin：可将用例流程转换为 Gherkin 场景，用于测试。