Now Reading: 使用用例详述的全面指南：关键概念、方法与实例
-
01
使用用例详述的全面指南：关键概念、方法与实例
使用用例详述的全面指南：关键概念、方法与实例
引言
用例详述是软件开发生命周期中的一个关键阶段，尤其是在需求工程和面向对象分析与设计的背景下。它弥合了高层用例与详细系统规范之间的差距，使开发人员、分析师和利益相关者能够理解 如何系统如何响应特定的用户目标。
本指南提供了对 用例详述的全面概述，包括其目的、关键概念、分步方法、最佳实践以及实际案例。
1. 什么是用例详述？
用例详述是将高层用例细化为系统行为的详细、可操作描述的过程。它将用户交互的简单叙述转化为精确、可测试且可实现的规范。
✅ 目标：定义 什么系统应该做什么， 如何它应该如何执行，以及 在何种条件下，详细到足以支持开发和测试。
2. 为什么用例详述很重要
-
减少歧义：防止对需求的误解。
-
提高可追溯性：将需求与设计、代码和测试用例联系起来。
-
支持设计与实现：为类图、时序图和数据库设计提供基础。
-
支持测试：促进测试场景和验收标准的创建。
-
增强协作确保利益相关者、开发人员和测试人员之间的共同理解。
3. 用例细化中的关键概念
3.1 用例（UC）
用例描述了系统为某个参与者（用户或外部系统）产生有价值结果而执行的一系列操作。
示例：“取现”从一台自动取款机中。
3.2 参与者
与系统交互的外部实体。可以是人类用户、另一个系统，或时间触发器。
示例：客户、ATM 机、支付网关。
3.3 主要参与者和次要参与者
-
主要参与者：启动用例。
-
次要参与者：支持主要参与者（例如银行服务器）。
3.4 前提条件
用例开始前必须为真的条件。
示例：用户必须持有有效卡片和正确的密码。
3.5 后置条件
用例完成后必须为真的条件。
示例：现金被发放，账户余额已更新。
3.6 主成功场景（基本流程）
导致成功的用例中最常见的路径。
示例：插入卡片 → 输入密码 → 选择取款 → 输入金额 → 领取现金。
3.7 替代流程（异常流程）
用于处理异常、错误或变化的用例分支。
示例：密码错误 → 重试或取消。
3.8 扩展
主流程中可以插入替代行为的点（例如，在UML中通过“<>”表示）。
示例：“<>：通知银行可疑活动。”
3.9 非功能需求（NFRs）
对系统行为的约束（例如，性能、安全性和可用性）。
示例：“交易必须在3秒内完成。”
4. 用例细化过程（逐步说明）
步骤1：识别用例
从一个高层次的用例开始（例如，“下单”）。
使用模板：
用例名称：下单
主要参与者：客户
利益相关者：客户，订单管理系统，支付网关
步骤2：定义前置条件
列出用例开始前必须满足的所有条件。
客户已登录。
购物车中至少包含一件商品。
支付方式已保存。
步骤3：定义后置条件
说明用例完成后必须为真的内容。
订单已在系统中创建。
库存已更新。
支付已处理。
已发送确认邮件。
步骤4：编写主成功场景（基本流程）
详细描述理想且成功的流程。
客户从购物车中选择“去结算”。
系统显示订单摘要。
客户确认收货地址。
客户选择支付方式。
系统处理支付。
支付已确认。
系统创建订单并生成确认信息。
显示确认信息并发送电子邮件。
步骤5：识别替代流程（异常流程）
列出可能偏离主流程的情况。
替代流程A：库存不足
系统检查库存。
商品缺货。
系统显示消息：“商品不可用。”
客户可以移除该商品或选择不包含该商品继续操作。
替代流程B：支付被拒绝
支付被拒绝。
系统显示错误信息：“支付被拒绝。”
客户可以重试或选择其他支付方式。
替代流程C：无效的配送地址
系统验证地址。
地址无效。
系统提示客户进行修正。
步骤6：定义扩展（<> 关系）
使用UML风格的扩展来表示可选行为。
<>：通知库存系统
触发条件：在结账过程中商品缺货时。
目的：通知仓库补货。
<>：应用折扣优惠券
触发条件：客户输入有效的优惠券代码。
目的：降低总成本。
步骤7：添加非功能性需求（NFRs）
包含系统约束条件。
订单必须在5秒内处理完毕。
支付必须使用TLS 1.3进行加密。
系统必须支持10,000个并发用户。
步骤8：审查与验证
与利益相关者协作，确保完整性和准确性。
问：“这是否涵盖了所有用户目标？”
问：“所有边缘情况都考虑到了吗？”
问：“开发者能否据此进行开发？”
5. 详细说明的工具与技术
| 工具/技术 | 目的 |
|---|---|
| 用例图（UML） | 可视化参与者和用例。 |
| 顺序图 | 展示用例过程中对象之间的消息传递。 |
| 活动图 | 建模复杂的流程和决策点。 |
| 用户故事地图 | 将用例与用户旅程和优先级关联起来。 |
| 决策表 | 澄清复杂逻辑（例如折扣规则）。 |
6. 最佳实践
-
保持用例以用户为中心：关注用户目标，而非系统功能。
-
使用一致的命名：使用动词-名词格式（例如“更新个人资料”）。
-
避免使用技术术语：为非技术利益相关者撰写。
-
使用简洁语言：表达清晰且简洁。
-
迭代: 随着理解的加深，不断优化用例。
-
链接到其他工件: 将用例与类图、测试用例和用户故事关联起来。
-
优先排序: 首先关注高价值或高风险的用例。
7. 现实世界示例：网上银行 – 转账
用例: 转账
主要参与者: 客户
次要参与者: 银行服务器，欺诈检测系统
前置条件
-
客户已登录。
-
源账户有足够的资金。
-
未超过转账限额。
后置条件
-
资金已从源账户转至目标账户。
-
交易已在两个账户中记录。
-
已向双方发送通知。
主成功场景
-
客户从仪表板中选择“转账”。
-
系统显示转账表单。
-
客户输入目标账户和金额。
-
系统验证账户和金额。
-
客户确认转账。
-
系统检查欺诈检测规则。
-
交易已获批准并执行。
-
显示确认消息。
备用流程
-
A1：资金不足
→ 系统显示：“资金不足。”
→ 客户可以取消或调整金额。 -
A2：检测到欺诈
→ 系统阻止转账并发送警报。
→ 客户必须通过双重身份验证确认或联系客服。 -
A3：无效的收款账户
→ 系统显示：“账户未找到。”
→ 客户可以重新输入或使用账户查询功能。
扩展
-
<>：向收款人发送通知
-
触发条件：转账完成。
-
目的：通知收款人。
-
-
<>：收取转账费用
-
触发条件：转账金额 > 1000美元。
-
目的：扣除5美元费用。
-
非功能性需求
-
所有转账必须记录并可审计。
-
响应时间 ≤ 2秒。
-
数据在传输中和存储时均需加密。
8. 常见陷阱及避免方法
| 陷阱 | 解决方案 |
|---|---|
| 过于模糊（例如：“系统应处理订单”） | 使用具体且可衡量的动作。 |
| 语言过于技术化 | 使用自然语言；避免使用代码或数据库术语。 |
| 遗漏异常路径 | 使用备用流程来覆盖失败情况。 |
| 没有明确的成功标准 | 清晰地定义后置条件。 |
| 未进行利益相关者评审 | 让用户、测试人员和业务分析师参与进来。 |
9. 结论
用例细化不仅仅是一项文档工作——它是一项战略过程，确保系统能够清晰、精确且完整地满足真实用户的需求。通过系统地将高层次的用例扩展为详细且可操作的规范，团队可以降低风险、改善沟通，并为成功的软件交付奠定坚实基础。
✅ 最后提示：将用例细化视为一个迭代式对话，而非一次性任务。随着你对系统及其用户了解的加深，不断对其进行完善。
附录：用例细化模板
# 用例名称：[例如：更新个人资料]
**主要参与者**：[例如：客户]
**次要参与者**：[例如：数据库，邮件服务]
**利益相关者**：[例如：客户，支持团队]
### 前置条件
- [列出条件]
### 后置条件
- [列出结果]
### 主成功场景（基本流程）
1. [步骤1]
2. [步骤2]
...
### 备选流程
- **A1：[名称]**
1. [步骤]
2. [步骤]
- **A2：[名称]**
...
### 扩展（<<extend>>）
- **<<extend>>：[名称]**
- 触发条件：[何时]
- 目的：[为何]
### 非功能性需求
- [性能、安全、可用性等]
### 备注
- [额外的上下文或假设]
遵循本指南，团队可以掌握用例细化的艺术，构建出不仅功能完备，而且真正符合用户期望的系统。
附录 – ATM取现用例描述：
用例名称
取现
主要参与者
客户（银行账户持有者）
次要参与者
-
ATM机
-
银行服务器（核心银行系统）
-
支付网关（用于交易处理）
-
欺诈检测系统
-
打印机（用于生成凭条）
利益相关者及利益
-
客户：希望安全且高效地取现。
-
银行：确保交易完整性、防欺诈以及账户信息的准确更新。
-
ATM运营商：确保设备可用性和现金库存。
-
安全团队: 监控可疑行为并防止欺诈。
前置条件
-
客户已将有效的银行卡插入ATM。
-
客户已成功验证身份（输入了正确的PIN）。
-
客户的账户处于激活状态且未被锁定。
-
ATM的保险箱中有足够的现金。
-
客户的账户有足够的可用余额。
-
每日取款限额尚未超过。
后置条件
-
向客户发放了请求的现金金额。
-
客户的账户余额减少所取金额。
-
银行系统中创建了交易记录。
-
打印收据（如果客户要求）。
-
ATM记录该交易以供审计和对账。
主成功场景（基本流程）
| 步骤 | 系统动作 | 参与者响应 |
|---|---|---|
| 1 | ATM提示：“请输入您的PIN。” | 客户输入PIN。 |
| 2 | ATM与银行服务器验证PIN。 | 系统确认PIN正确。 |
| 3 | ATM显示主菜单：“取现、查询余额、转账、退出。” | 客户选择“取现”。 |
| 4 | ATM提示：“请输入取款金额。” | 客户输入金额（例如：100美元）。 |
| 5 | ATM验证： |
-
金额在每日限额内。
-
账户有足够的资金。
-
ATM有足够的现金。|系统确认有效性。|
| 6 | ATM向银行服务器请求授权。|银行服务器批准交易。|
| 7 | ATM从保险库中发放现金。|客户收到现金。|
| 8 | ATM提示：“您需要收据吗？”|客户选择“是”或“否”。|
| 9 | 如果选择“是”：ATM打印收据，内容包括： -
日期/时间
-
取款金额
-
剩余余额
-
交易编号 |客户领取收据。|
| 10 | ATM显示：“谢谢。请取出您的卡片。”|客户取出卡片。|
| 11 | ATM返回空闲状态。|系统重置。|
✅ 成功结果：客户收到现金（并可选收据）。账户已更新。
替代流程（异常情况）
A1：输入无效PIN（3次尝试）
-
触发条件：客户连续三次输入错误的PIN。
-
系统操作：ATM锁定卡片并显示：“卡片已锁定。请联系您的银行。”
-
用户操作：客户离开并联系银行。
-
后置条件：卡片暂时被锁定；交易已被记录。
⚠️ 注意：这是防止未经授权访问的安全措施。
A2：余额不足
-
触发条件：客户输入的金额超过可用余额。
-
系统操作：ATM显示：“余额不足。当前余额：$X。”
-
用户操作：客户选择“取消”或输入更低的金额。
-
后置条件：未发放现金；账户无变化。
A3：ATM现金不足
-
触发条件：客户输入有效金额，但ATM保险箱为空或低于最低限额。
-
系统操作：ATM显示：“现金不可用。请稍后再试。”
-
用户操作：客户取消或稍后返回。
-
后置条件：交易未处理；账户无变化。
A4：取款金额超过每日限额
-
触发条件：客户尝试提取超过每日限额的金额（例如，$1,000）。
-
系统操作：ATM显示：“超过每日取款限额。请尝试较小金额。”
-
用户操作：客户减少金额或取消。
-
后置条件：交易未处理。
A5：银行服务器拒绝交易
-
触发条件: 银行服务器拒绝交易（例如，由于欺诈警报、账户冻结）。
-
系统操作: ATM 显示：“交易被拒绝。请联络您的银行。”
-
参与者操作: 客户取消并联系银行。
-
后置条件: 未发放现金；账户无变化。
扩展（<> 关系）
| 扩展 | 触发条件 | 目的 |
|---|---|---|
| <>: 通知欺诈检测系统 | 当在外国进行取款或超出正常行为时 | 标记可疑活动以供审查 |
| <>: 向客户发送短信警报 | 成功取款后 | 通知客户交易信息（增强安全性） |
| <>: 收取取款费用 | 针对非主要账户持有者或特定账户类型 | 对特定服务收取费用 |
| <>: 打印交易记录 | 如果客户在菜单中选择“打印历史” | 提供最近交易的打印摘要 |
非功能需求（NFRs）
| 类别 | 需求 |
|---|---|
| 性能 | 交易必须在3秒内处理完成。 |
| 安全 | 所有通信均加密（TLS 1.3）。PIN 永远不会以明文形式存储或传输。 |
| 可靠性 | ATM在银行服务器确认授权之前不得发放现金。 |
| 易用性 | 界面必须可访问（例如，大按钮、为视障人士提供语音引导）。 |
| 可用性 | ATM必须在99.9%的时间内保持运行。 |
| 审计与合规 | 所有交易必须记录并可追溯7年（根据银行监管规定）。 |
备注
-
ATM必须定期维护，以确保现金供应和硬件可靠性。
-
如果在交易完成后30秒内未取出卡片，系统将自动保留卡片（防盗功能）。
-
系统支持多种货币及汇率计算（如适用）。
用例图（UML摘要）
[客户] --(取款)--> [ATM]
[ATM] --(验证PIN)--> [银行服务器]
[ATM] --(检查资金)--> [银行服务器]
[ATM] --(发放现金)--> [现金库]
[ATM] --(打印凭条)--> [打印机]
[ATM] --(通知欺诈系统)--> [欺诈检测系统]
（注：在完整的UML图中，用例关系如<>和<>将被显示。）
✅ 总结
此详细用例“取款”的详细用例提供了一个清晰、结构化且可测试的规范，其特点包括：
-
捕捉用户目标和系统行为。
-
处理现实世界中的异常情况。
-
支持安全性、合规性和易用性。
-
为设计、测试和实现提供基础。
适用于敏捷冲刺、系统设计文档或正式需求规格说明。
📘 下一步:
-
将其转换为顺序图 用于展示对象之间的交互。
-
创建 测试用例 基于每个流程（主流程和备选流程）。
-
链接到 类图 （例如，
账户,交易,ATM,欺诈检测器).
- 什么是用例图？——UML建模完整指南：本指南深入解释了用例图，涵盖其目的、组成部分以及建模软件需求的最佳实践。
- 逐步用例图教程——从入门到精通：此全面资源引导用户完成创建有效用例图的过程，从基本概念到高级建模技术。
- Visual Paradigm——用例描述功能：本文探讨了Visual Paradigm中可用于精确记录用户交互和系统行为的特定功能。
- Visual Paradigm的AI用例描述生成器：此页面详细介绍了由人工智能驱动的工具，可从用户输入自动生成详细的用例描述，显著加快文档编制过程。
- 在Visual Paradigm中利用AI自动化用例开发：本文解释了AI驱动的生成器如何在软件开发生命周期中减少人工工作量并提高一致性。
- Visual Paradigm用例描述生成器教程：逐步教程，演示如何从您的图表直接自动生成结构化、详细的用例文档。
- 在Visual Paradigm中记录用例：用户指南：此官方用户指南解释了如何在建模环境中使用既定模板和最佳实践来有效记录需求。
- 在Visual Paradigm中生成用例描述：本技术指南提供了使用软件内置工具为系统需求创建正式描述的说明。
- 揭开用例、场景和事件流程的神秘面纱：此深入资源解释了用例、场景以及为准确文档化所需事件流程之间的关键关系。
- 如何编写有效的用例？——Visual Paradigm：本教程强调，用例建模的主要目的是通过清晰识别用户需求来建立稳固的系统基础。
