文/fasiondog

注：以下用例常见问题来自《编写有效用例》（[美] Alistair Cockburn 著）一书。

没有系统

下面是ATM系统取款用例的一部分：

修改前：

1. 储户插入ATM卡，并输入密码
2. 储户按“取款”按钮，并输入取款数目
3. 储户取走现金、ATM卡并拿走收据
4. 储户离开

修改提示：

用例展示了主执行者（储户）所做的一切，却没有显示系统行为。

修改后：

1. 【储户】插入ATM卡
2. 【ATM系统】从卡上读取银行ID、账号、加密密码、并用主银行系统验证银行ID和账号
3. 【储户】输入密码
4. 【ATM系统】根据步骤2读出的加密密码，验证储户输入了正确的密码
5. 【储户】选择“取款”，并输入取款数量
6. 【ATM系统】输出现金、ATM卡，显示账户余额
7. 【ATM系统】记录事务到日志系统

没有参与人

下面是ATM系统取款用例的一部分：

修改前：

1. 收集ATM卡、密码
2. 收集取款事务类型
3. 收集提前金额
4. 验证账户上是否有足够的余额
5. 输出现金、收据和ATM卡
6. 复位

修改提示：

本用例从系统角度进行编写，显示了ATM系统的所有行为，但没有涉及参与人的行为。

修改后：

同前一节修改后的用例。

过多的用户接口细节

某网上采购系统买东西：

修改前：

1. 【系统】显示输入ID及密码屏幕
2. 【客户】输入ID和密码，然后按“OK”按钮
3. 【系统】验证客户ID及密码，并在屏幕上显示个人信息
4. 【客户】输入姓名、省份、城市、街道地址、邮编、电话号码，然后按“OK”按钮
5. 【系统】验证是否为老客户
6. 【系统】显示可用商品列表
7. 【客户】选取所需购买的商品及数量，完成时按“提交”按钮
8. 【系统】通过库存辅助系统验证购买商品是否有足够的库存

修改提示：

这种错误在用例编写中是最常见的。编写者大量描述用户接口，使得用例变成了用户手册，而不是需求文档。过多的接口细节虽然对用例本身没有什么影响，但这样不利于用例的可读性，使系统需求难以把握。

对用例的修改是：寻找一种描述用户意图的方法，而不是特定的解决方案。这有时需要一些创造性的工作。

修改后：

1. 【客户】使用ID和密码进入系统
2. 【系统】验证客户身份
3. 【客户】提供姓名、地址、电话号码
4. 【系统】验证客户为老客户
5. 【客户】选择购买商品及数量
6. 【系统】由库存系统验证商品有足够的库存

过低的目标层次

某网上采购系统买东西：

修改前：

1. 【客户】使用ID和密码进入系统
2. 【系统】验证客户身份
3. 【客户】提供姓名
4. 【客户】提供地址
5. 【客户】提供电话号码
6. 【客户】选取商品
7. 【客户】确定购买商品数量
8. 【系统】验证客户是否为老客户
9. 【系统】打开到库存系统的连接
10. 【系统】通过【库存系统】请求当前库存量
11. 【库存系统】返回当前库存量
12. 【系统】验证购买商品数量是否足够

修改提示：

显而易见，此用例非常冗长。但和上节用例相比，不能说它对用户接口描述过细。为了缩减此用例，是整个过程更清晰，其缩短步骤如下：

• 对数据项（3~5步）进行合并，将这些分散的步骤放在一步中完成。“如何概括客户提供的信息呢？”。答案是：“个人信息”。在概括信息别名的基础上，明确其字段，或提供其字段详细定义的引用。
• 可以把所有处于同一方向上的信息合并为一步（3~7步），参考准则3。
• 寻找一个更高层次的目标（8~11步）。“系统为什么需要做这些事呢？”那么可以用一句话回答，即“系统试图通过库存系统来验证购买的商品是否有足够的库存。如上所述，如果用这个高层目标来捕获这些需求，则将使用例描述更清晰、更简明。

修改后：

1. 【客户】使用ID和密码进入系统
2. 【系统】验证客户身份
3. 【客户】提供个人信息（包括姓名、地址、电话号码），选择购买的商品及其数量
4. 【系统】验证客户为老客户
5. 【系统】通过库存系统验证商品有足够的库存
6. ……