预定酒店的用例与业务建模

本文主要对某年代意大利某线上酒店预订网站，以及去哪网的订旅馆业务做了用例与业务建模分析，下面是相关的文档和网址：
https://download.csdn.net/download/qq_33559972/10366961
https://www.qunar.com/

用例建模

a. 根据上面给出的文档和文档内 Task1 的要求，我使用工具 UMLet 绘制了如下用例图：

有以下几点要做一个说明：
1.三个外部服务都属于支付系统，文档中详细描述了支付的过程，特此把它分开来写清楚，可以看作是支付系统提供的不同子服务；
2.添加了管理basket的子用例，也能在文档中找到依据；
3.老师上课有画GIS API的外部系统，但原文档中没有体现，文档中给的网站也已经打不开了，因此我认为去掉会合适一些，这样一来search也就没有必要拓展出子用例了。

b. 对比地绘制了去哪网的用例图，其中粉色为相对于老网站的创新用例，黄色为有创新的外部系统和服务：

c. 对比与总结
对比这两个时代、不同地区产品的用例图，我们发现用户在订旅馆的核心流程上是不变的：搜索、（选择）预约、支付。因此主用例没什么变化，但在选择和预约的界限上，两个系统的划分有些不同。下面对两个系统的不同点，尤其是去哪网相对以前的老系统做出的创新进行分析：
1.去哪网在搜索时提供境内/境外的选项，这可能是系统的功能性需求，对用户来说只是对目的地选择范围的一种细化；
2.提供“酒店名、地标、商圈组合搜索”，这应当属于扩展用例，可以辅助用户更好地搜索；
3.地图搜索（国外不支持），能够在地图上搜索到已选目的地范围内的酒店；
4.可以选择根据酒店级别和连锁品牌进行筛选，更好地照顾用户的需求，也使得系统看起来更加人性化；
5.没有添加购物篮这一步，但登录后应该是能够看到历史订单的，也一定能通过线上线下的方式取消订单，这应该不算在订旅馆的用例中。

还有更多细节上的不同，这里就不一一列举。我们可以发现，两个系统的信息丰富度是不一样的，这很大程度上可以归结为当代信息技术的进步和普及。点开去哪网的旅店详情页，可以看到非常多的指标和描述，还有一些服务也是随着时代进步发展出来的，比如有早/无早（是否提供早点）、WiFi、接机服务等等。
去哪网的收银系统我不甚明了，毕竟我不会真的去付款订个酒店。但可以肯定的是现代系统的支付方式更多了，似乎也更简便了，它不会要求通过验证银行卡绑定地址的方式保证支付安全，一般也不会有邮件确认的步骤——而老网站是这样的，并且只能用银行卡，详见文档。
总的来说，去哪网包含的信息更丰富了，功能模块的划分也更加清晰了，对用户操作的定义更加符合现代人的习惯，提供了更大程度上的便利。

我们如何在项目早期发现创新的思路与方法呢？
首先，要找准用户的需求痛点：比如原始的系统缺乏对酒店的介绍和描述，用户如果不是特别熟悉那家酒店可能就不敢预定了；而现代系统加入足够多的信息描述，包括居住环境的照片，还有点评打分系统，让住客更加安心。
其次，可以结合更好更新的技术：比如这里支付方式的改进。

d. 根据SCRUM 方法，在去哪网用例图的基础上，尝试编制了去哪网开发的需求，即 product backlog

编号	用例名	重要性	估计(人日)	如何展示	备注
1	选旅馆	30		能够以列表的形式看到我的备选旅馆的基本信息，选中后跳转到该旅馆的详情页	详情页目前可以只是个demo
2	预约	30		选择日期和房型，生成订单	展示出来的房型都是在选择日期下可用的
3	支付	30		选择支付方式，输入账号和密码，支付账号扣款，商家收款	接入主流支付系统API，重要性高但可以晚点完成
4	查看酒店详情	20		选中某个旅馆后点击跳转到该页，显示相关信息
5	直接搜索	20		输入或选择目的地后，搜索得到该目的地范围内的酒店列表	结合地标、商圈等的搜索暂时不做
6	筛选	10		输入或选择筛选条件后，得到符合条件的酒店列表
7	排序	10		选择某种顺序排序后，得到排序后的酒店列表
8	在地图上搜索	5		根据输入的目的地，地图上定位到相应范围，用图标把酒店标注出来，点击酒店可跳转到对应详情	该需求有待补充和细化

我给出上面重要性评估的理由是：前三个用例为支撑订酒店这个完整流程必不可少的故事点，因此重要性最高；接下来两点是为系统的易用性服务的，没有这两个用例用户体验会很糟糕；筛选和排序则是提供更多样化的服务；而地图搜索是打开了一种全新的搜索模式，但这个点是可以由直接搜索替代的，只是方式上的不同照顾到了不同的需求场景，因此可以放到系统主要部分完成之后再做，重要性最低。

参考：《硝烟中的scrum和xp》

业务建模

a. 在去哪网用例图的基础上，用活动图对找酒店用例建模：

该图包含了从填写搜索条件到得出搜索结果的流程，在上面的用例模型中，找酒店的流程至此结束，接下来是选酒店的问题。
流程图的建立能够辅助发现子用例，通过仔细梳理每个步骤和流程，你会知道什么是扩展或可选的步骤，谁是谁的必要前提。比如这里的目的地范围——境内或境外，就是一个子用例，它完全是一个可以忽略的操作，加入你的输入是境外这个目的地范围也会做自动匹配。同时你可以明确什么需求点的重要性。

b. ATM取款业务流程的流程图

c. 使用多泳道图分析淘宝退货业务

其中，客户要完成退货业务，在淘宝网上需要实现的系统用例有：创建退货表单、退款单状态管理、审核退货处理、审核退款处理。

用例文本编写

只有一个用例图自然是不能准确传达出需求的，因此要辅以文字性的描述，这就是用例文本。形式上，它有摘要、非正式、详述三种，详略程度不同。
这里给出我们团队项目中一个食客线上下单的详述版用例：https://github.com/Baoleme/Dashboard/blob/master/doc_usecases/make_order.md
这个用例是按照详述的格式完成的，只不过目前系统设计的对象和流程比较简单，亦或是我们目前对这个业务的了解还不够深入，所以它看起来也比较简短。目前都是针对核心需求做了这样的分析，得出这样的用例也是经历了两轮线上线下的需求讨论才定下，其他两种格式就还没有用到，都在我们的讨论当中啦！

三种风格的用例文本都各有特点，这里做一个简单的对比：

风格	优点	缺点	适用场景
摘要	简洁，使人快速了解主题和范围，可以快速完成	不够明确	早期需求分析
非正式	段落的格式，已经开始有所补充	仍然不够完善和完整，是摘要和详述的折中	同摘要
详述	包含所有步骤及各种变化，有前置条件和成功保证	编写有难度	确定并以摘要形式编写了大量用例后