首页
笔记
书单
需求
推荐
快讯
书友
短句
发布
新的私信
注册
登录
推荐
亲身体验,最真实的感受分享,好读的书,好玩的地方,好吃的美食,美好的事物。
内容查询
分类查看
全部分类
房产
儿童
购物
家电
家居
健康
教育
旅游
美食
汽车
手机
生活
数码
时尚
文学
育儿
图书
学术
影视
游戏
音乐
推荐数前10的用户
王佳亮
[点此发私信]
顾燕
[点此发私信]
小贝
[点此发私信]
使用用例分析技术
王佳亮
用例分析技术-用例细节
当我们在写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
支持:0
阅读:732
0