用例分析技术-用例细节
 
当我们在写UC的时候，每个人可能都会有如下疑问：“我们怎样知道用例细化到什么程度是恰当的？”对于这个问题并不存在确定、快速的法则，但有一些指导性方针。当你要确定一个恰当的细节层次时，需要考虑以下几个问题：
1、  谁要阅读并审批这个文档？
2、  谁需要使用这个文档？
3、  我们要这个文档做什么？
以前我们所示的用例都是细化到中等层次——从使用这个系统的执行者的角度来描述这个软件。然而，你也需要别的读者来看这个用例。
以我的工作经历来看，我们很多时候写UC，高层领导其实是不怎么关心具体实现细节的，而我们写的UC，最终读者，其实是软件开发人员和测试人员。所以，我们写UC的时候，要从业务转变为技术的角度去完善UC，做好业务和技术人员的桥梁。还是以最常见的订购货物用例举例：
订购货物用例
1、  客户选择订购货物，用例开始。
2、  客户键入姓名和地址。
3、  如果客户键入邮编，系统提供省份和城市。
4、  客户键入想要订购产品的代码。
5、  对于每一个键入的产品代码
a)       系统提供产品描述和价格。
b)       系统把产品价格加入总量中。
6、  客户键入信用卡支付信息。
7、  客户选择“提交”。
8、  系统检验信息，把该订单作为未完成的交易保存起来，同时向记账系统提供支付信息。
9、  支付确认后，订单被标志为确认，同时返回客户一个订单ID，用例结束。
 
如果从执行者的角度来看，这个用例是没有问题的。但如果这个用例拿给开发者，或是测试人员，他们看了用例就可能有如下疑问：
1、  在第3步，当提供邮编时，系统从什么地方获得省份和城市的名字？是否要建立省份和城市的对应表？这些省份和城市的信息在公司的数据库中吗？是购买一些软件来提供这些信息还是从邮局得到这些信息？
2、  在第5步a中，似乎由库存系统来提供产品描述和价格，但应清楚声明。
3、  在第8步中，“检验信息”是什么意思？会发生什么情况？
4、  在第9步中，“确认信息”是什么意思？又会发生什么情况？
5、  什么时候以什么方式计算税和送货信息？
综上，如果这个用例是将来用于研发，给研发人员和测试人员看的，就应该做以下完善（蓝色加粗字体是进一步补充完善的）：
订购货物用例-开发者角度
1、  客户选择订购货物，用例开始。
2、  客户键入姓名和地址。
3、  如果客户键入邮编，系统使用邮编在线从邮局查询到省份和城市，系统把省份和城市加到订单中去。
4、  客户键入想要订购产品的代码。
5、  对于每一个键入的产品代码
a)       系统使用产品代码查询库存系统，得到产品描述和价格。系统把描述和价格加入到订单中，系统查询客户的产品数量，客户键入产品数量。
b)       系统把产品价格加入总量中。
6、  客户键入信用卡支付信息。
7、  客户选择“提交”。
8、 系统确信所有需要的信息都已经录入，它必须包括一个完整的送货地址、信用卡支付信息和至少一种产品。系统把该订单作为未完成的交易保存起来，向记账系统提供支付信息。
9、  记账系统计算税和送货数量，并返回成功接受支付的信息及订单总量。系统将订单标志为确认，同时返回客户一个订单ID，用例结束。
从我自己这些年的经验来看，UC大多数是给研发看的，所以，我们在写UC的时候，尽量使用第二种用例的写作思路和方法。