1.用例建模
a.
b.
红色为创新用例,绿色为外部系统
c.在考虑功能的时候应当考虑得更加周全,揣摩用户使用产品时的心理和需求究竟是什么,比如在搜索得出的旅馆中选择时,使用排序,除了按照旅馆星级,价格等要素,还应当考虑到用户的省钱的需求,用户期望有优惠活动,可以以更低的价格享受服务,所以在Angoda的排序中能找出有优惠的酒店。
d.
Name | 重要性 | 估算 | How to demo |
搜索功能 | 40 | 8 | 客户输入地点信息广州并通过选项卡做出一些搜索的限制,如指定入住时间和星级就可以点击搜索键进行搜索 |
排序界面 | 30 | 8 | 客户在得到的一堆酒店中点击按热门程度排序,按价格排序等使得结果以客户想要的顺序呈现 |
酒店详情 | 20 | 3 | 点击进入酒店详情,客户可以看到酒店的室内照片和酒店附近的景点,以及酒店提供的服务 |
支付 | 10 | 2 | 在确定要订某个酒店后,客户选择想要的支付方式,比如支付宝,点击支付,跳转到支付宝网关付款 |
2、业务建模
a.
使用流程图时,对每一个状态都思考这个状态下会做什么,如果有多个操作复合起来,那就能发现子用例。
b.
c.
需要多个系统用例:申请退货,通知退货信息,处理退货需求,申请仲裁介入,处理仲裁结果,处理退款。。。
3.
1.Brief
优点:简洁,每个场景只有一段文字,一眼就可以读懂发生了什么。
缺点:缺乏细节,过于简单,不能对所有情况进行说明,只适合最早期的开发
2.Casual
优点:比Brief更加详细,可以有多段文字来表述场景,使用比较随意,比较容易完成。
缺点:比Brief更详细,但并不能用在需要特别详细的用例的场景,可以替换Brief。
3. Fully
优点:非常详细,考虑了大部分情况,有严格的书写格式规范,几乎任何情况都能从中找到对应的描述。
缺点:因为非常详细,所以很难写,难以考虑地非常周全,要完成这样的用例文本,需要耗费大量时间,只适用于一些高要求,复杂的工件来使用。