一、用例建模
a. 阅读 Asg_RH 文档，绘制用例图。 按 Task1 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸
答：
b.选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：
对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例尽可能识别外部系统，并用色彩标注新的外部系统和服务
去哪儿找酒店截图如下：
根据使用，画出用例图如下：
c.对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法
答：首先，创新一定要建立在已有业务完善之上。研究同类型竞品，做分析，画出各竞品的核心业务用例图。在完善了所有必要的基础核心业务之后，从各竞品的业务中寻找缺点和遗漏点，从而进行改进和创新。
方法则可以基于产品调研，用户调研，数据分析，竞品分析等手段。
d.请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求 （backlog）
答：
二、业务建模
a.在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法
从开始到第一个点击搜索之后的任意一步，都能成为一个子用例。
b.选择你身边的银行 ATM，用活动图描绘取款业务流程
c.查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例
三、用例文本编写
在大作业基础上，分析三种用例文本的优点和缺点
答：
1.简洁的用例文本(Brief)
在大作业中，比如在前几次会议上进行前期需求分析，仅需定下一些核心业务，具体的细节和创新业务都不需要体现。此时用这种摘要式的简介用例文本就很能编写快速，简洁明了。
优点：简介明了，书写速度快
缺点：不够详细，对具体场景描述不够细致，易导致误解或不清晰
2.非正式的用例文本(Casual)
在大作业的中间时段的会议中，具体的业务可能进行多次更改，所以对一些具体场景只做非正式的用例文本，便于修改。并且在简洁的基础上更多了细节的内容，既不会太繁杂，也不会过于简洁
优点：编写相对简洁；比简洁的用例文本更加详细，对问题的阐述更加清晰。
缺点：仍不够正式，仍有细节需要优化
3.详尽的用例文本(Detailed)
在大作业的需求分析基本进入尾声阶段，已经能确定本项目需要的所有具体功能和业务时，采用详尽的用例文本最好。因为需求已经非常明确，此时的用例文本将用于最终实现和编程。
优点：内容详细，细节到位，对所有问题都阐述清晰，不会产生误解。
缺点：编写起来十分复杂，耗时且细致