系统分析与设计 HW4

1、用例建模

a. 阅读 Asg_RH 文档，绘制用例图。按 Task1 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸

b. 选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：
- 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例
- 尽可能识别外部系统，并用色彩标注新的外部系统和服务

c. 对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法

在项目早期，可先参考过往的需求类似的产品的用例图，然后以它们的核心用例为基础进行一定的修改。在修改过程中需要考虑当前时代与地区的文化，将一些不符合当前文化的用例删去，并增加一些符合当前文化的创新用例。

d. 请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求（backlog）

ID	Name	Imp	Est (week)	How to preview	Note
000	登陆	50	12	进入网站，点击登陆按钮；或提交订单前，获得一个弹出的登陆窗口。	若用户没有账号，提供注册功能，注册需填写个人资料。
010	微信登陆	30	6	在登陆窗口上可以找到微信登陆选项，点击使用微信登陆网站。	若用户没有已绑定微信的账号，使用微信号注册新账号。
100	寻找酒店	50	15	进入网站，选择城市、日期、关键字，点击搜索	提供一定的筛选功能。
110	使用地图寻找酒店	30	18	输入目的地后，点击地图浏览，可以看见目的地的地图，在地图上可以选择不同的地段。	使用 MapBox API。
120	获得酒店推荐	20	12	进入网站，在首页获得根据用户搜索记录或用户评分得到的酒店推荐。	无需在前期迭代中实现
200	预订酒店	50	12	在酒店列表点击选择酒店，进入详情页，查看酒店信息，选择日期、房型后，点击预订。完成订单后，用户可对酒店进行评论。	若用户选择的房间不可用，显示相应的提醒，允许用户在订单中对酒店方提出特别需求。
300	付款	50	6	选择完酒店后，点击付款按钮，填写完付款方式后点击完成预订按钮提交订单。	仅支持信用卡支付。
400	获得奖励	20	3	进入网站，在首页上可以找到优惠信息，点击优惠信息后完成指定操作获得奖励	仅支持已登陆用户使用该功能。

2、业务建模

a. 在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法。

利用流程图，可以把一个用例的业务流程清晰地展现出来，从中寻找可以抽象、复用的部分，并把它们抽象为子用例。

b. 选择你身边的银行 ATM，用活动图描绘取款业务流程

c. 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例

若客户要完成退货业务，在淘宝网上需要实现以下系统用例：提交退货申请、管理退货处理、更改交易状态、管理退款处理

3、用例文本编写

在大作业基础上，分析三种用例文本的优点和缺点

Brief: 提供一段总结，通常关于主要的成功场景。在需求分析的早期阶段，使用它可以快速了解主题和范围。它的优点是可能只需几分钟即可创建，而缺点则是由于可快速编写所导致过于简略。考虑大作业，Brief Use Case 可用于 inception meeting 中，便于我们快速确认点餐系统的基础功能，能让我们在此基础上提出创新功能。

Casual: 非正式的段落格式，多个段落涵盖各种各样的场景。Casual Use Case 同样用于需求分析的早期阶段，与 Brief Use Case 相比具有更多的细节，同时比 Full Use Case 需要更少的编写时间，而其缺点是无法被用作正式的用例文本，需要进行修改才能作为正式的用例文本。考虑大作业，使用 Casual Use Case 能帮助我们在 Brief Use Case 的基础上加入一些与创新元素有关的场景，让我们对产品初步设想的最终效果有一个初步的了解。

Full: 所有的步骤和变化都是详细写出来的，并且有支持部分，例如先决条件和成功保证。在很多用例被识别出来并以简短的格式写成之后，在第一个需求研讨会期间，将详细地写出几个（如10％）体系结构重要和高价值的用例。Full Use Case 的优点为具有很多的细节，且能提供一些依赖信息，在大作业中能帮助我们更好地完成设计阶段的任务，而缺点则是编写耗时长。