【系统设计与分析】4

1、 用例建模

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

       

• b. 选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：

• - 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例

• - 尽可能识别外部系统，并用色彩标注新的外部系统和服务

       

        

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

在项目开发早期，可以研究同类型竞品，画出各竞品的核心业务用例图，分析这些产品的基础核心业务是什么，也即用户的基本需求是什么。还可以进行用户调研并分析数据，从而得到用户对产品的新要求，以此进行功能上的创新。

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

2、业务建模

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

       

沿着活动图的起始状态开始，每次遇到分支时都记录下当前选择的路径，直到走到终止状态，这就是一个子用例。

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

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

3、用例文本编写

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

1.简洁的用例文本(Brief) ：
进行前期需求分析时，常用于主场景即核心业务的分析，这种摘要式的简介用例文本就很能编写快速，简洁明了。

优点：简介明了，能快速编写，且有助于快速了解主题和范围
缺点：只有主成功场景，不够细致

2.非正式的用例文本(Casual) ：
多个非正式的段落格式，用几个段落覆盖不同场景。在大作业的中间时段的会议中，具体的业务可能进行多次更改，所以对一些具体场景只做非正式的用例文本，便于修改。与摘要式用例文本相比有更多细节，但仍然需要后期细化。

优点：简洁，段落格式覆盖多个场景，比简洁的用例文本更加详细，对问题的阐述更加清晰。
缺点：仍不够正式，仍有细节需要优化

3.详尽的用例文本(Detailed) ：
详细编写用例的所有步骤和各种变化，同时会有前置条件或成功保证等补充部分。在大作业的需求分析基本进入尾声阶段，已经能确定本项目需要的所有具体功能和业务时，采用详尽的用例文本最好。因为需求已经非常明确，此时的用例文本将用于最终实现和编程。

优点：细节充足，正式且深入，且具有结构性，对所有问题都阐述清晰，不会产生误解。 
缺点：编写十分复杂耗时