1 用例建模

1.1 阅读 Asg_RH 文档绘制用例图

image

1.2 选择熟悉的定旅馆在线服务系统（或移动 APP）绘制用例图

这里我选择了 Airbnb 爱彼迎。下图是用 Airbnb 移动 APP 预定旅馆的实际操作图

image

绘制出用例图如下（其中绿色表示创新业务或新的外部系统）

image

1.3 对比总结

Airbnb 是 2010 年左右推出的产品，而第一问中的旅馆订单系统估计是 2000 年推出的系统；同时我是用的 Airbnb 中国区的 App 主要服务对象是中国人，而第一问中的服务对象是澳大利亚人。所以是两个时代的不同地区的产品。

对比两个用例图发现，二者主要有以下不同之处：

1. Airbnb 没有购物车选项，每次下单只能选择一个旅馆（的多个房间或一个房间）
2. Airbnb 可以与房主聊天沟通
3. Airbnb 付款时可以使用优惠券
4. Airbnb 添加个人信息的时候需要接受验证

我们不难发现 Airbnb 提供的服务流程更加简单（省去了去购物车的流程），更加私密化（可以与房主沟通了解房屋细节），更加安全（订房间的人需要通过身份验证系统的验证）；而第一问中在线订旅馆的服务更加全面（考虑到可能一次要定多个房间的需求）

所以总结得到项目早期发现创新的思路和办法有：

1. 多数人优先法。分析现有产品，寻找哪些功能是为了小部分人服务而不是为了大多数人服务，然后针对大多数人进行优化。这并不意味着放弃少数群体，而是提高尽量使所有人的平均体验。例如在订房间这个例子中，大多数人不需要一次性订不同地点的多个房间，或者是大多数人喜欢一个一个房间预定，这样满足多数人需求，省去了不必要的步骤。这个类似于淘宝购物中“直接下单”的选项

2. 紧跟时代法。早期设计的产品中可能有一些不符合当前时代的特性。例如当前时代互联网普及程度较高，人们比较重视互联网服务的安全性问题，所以 Airbnb 及时的提供了身份验证系统，只有通过验证的人可以订房间。在例如说现在的人更青睐定制的、精准的服务，所以 Airbnb 提供了练习房主的选项，让旅客可以获得更加舒适的体验

3. 迁移法。创新的时候可以利用他山之石，应用到当前的服务中。例如在商场中优惠券受大家喜爱，所以订房间可以用到类似的方法/来提升用户黏度

1.4 编制定旅馆开发的需求

ID	Name	Imp	Est	Iter	How to demo
1	搜索旅馆	7	3	1	进入 Airbnb 系统直接搜索
2	旅馆分类	6	4	1	进入 Airbnb 可以分类浏览旅店
3	聊天 API 学习	4	7	1
4	聊天功能	6	6	2	确认订单之前联系旅店老板
5	地图 API 学习	4	6	1
6	在地图上显示旅店位置	4	4	5	旅店地址信息可以在地图上进行展示
7	确认订单	7	6	2	选择旅店后确认订单（review）
8	支付系统学习	8	10	1
9	支付	8	10	3	确认信息后进行支付
10	收藏	6	8	6	选中后点击“收藏”
11	评价	6	8	7	选中后点击“评价”，可以输入文字对旅店进行点评

2 业务建模

2.1 用活动图建模找酒店用例并简述利用流程图发现子用例的方法

task4.png

2.2 用活动图描绘取款业务流程

image

2.3.1 用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程

根据 淘宝开放平台 - 天猫退款退货业务接入说明 绘制如下多泳道图

image

2.3.2 分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例

淘宝网需要实现：生成退款单、管理退款单、同意/不同意退款处理

3 用例文本编写

3.1 在大作业基础分析对比三种用例文本优缺点

1. 摘要用例文本，通常用在主成功场景。在我们点餐系统的Inception阶段，为了在便于在小组会议上讨论主题和范围，进行早期需求的分析，会用到摘要式的用例文本。

   • 优点：快速编写、简洁明了
   • 缺点：不够细致，只用作对问题粗略的认识

2. 非正式用例文本，即多个非正式的段落格式，用几个段落覆盖不同场景，同样用于早期的需求分析过程

   • 优点：编写简便，比起摘要式用例文本要详细一些，有利于进一步认识问题
   • 缺点：不够正式，需要在后续阶段精化。

3. 详述式用例文本，即详细地编写用例所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。详述式用例文本通常用在以摘要形式编写了很多用例以后，详细地编写其中少量具有重要意义和价值的用例中

   • 优点：细节充足，正式且深入，且具有结构性
   • 缺点：编写繁琐费时