推荐

亲身体验,最真实的感受分享,好读的书,好玩的地方,好吃的美食,美好的事物。


使用用例分析技术


用例分析技术-用例细节
 
当我们在写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的时候,尽量使用第二种用例的写作思路和方法。

2016/2/21 19:26:18
阅读:385
0