一、理解需求
什么是需求？客户可接受的、系统必须满足的条件或具备的能力——由用户提出
二、从业务模型获取需求
3个步骤：
-
寻找业务改进点——从业务用例模型中寻找系统改进点；
-
定义项目远景——结合系统远景，获取系统用例来表达需求；
-
导出系统需求——采用需求启发技术，从涉众中获得
实例分析：
旅店系统开发远景:
-
随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间
-
然而，随着预订的增多、预订周期的拉长，前台服务员工作压力也日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉带来不好的影响
-
为此，旅店老板想到了用计算机来管理——希望能够通过计算机来自动管理这些预订业务，但由于目前资金的问题，目前只开发一个单机版的系统，不提供网上业务；并且旅店方面的其它业务暂不考虑信息化问题
-
旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合作事宜
远景：酒店预订系统
-
A很荣幸地成为项目经理，并被要求在两个月之内发布该系统的第一个版本，同时还被要求要为后续的开发提供必备的接口
-
结合现状和老板的要求，考虑到项目可扩展的要求，A首先通过利用业务用例、业务处理活动、业务对象进行了建模
-
之后，A初步定义了项目的远景（项目的目标）
- 方便、快捷、准确地为旅客预订房间
- 旅客可以方便的取消预订的房间
- 旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格
- 及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息
- 预留接口：可为以后的网络版，以及其它业务系统的开发提供支持
三、建立用例模型
3.1、获取需求
需求只能来自涉众(stakeholders)、或相关利益者、或角色等等，但并不是直接从涉众中来，根据远景确定需求。
3.2、识别参与者
从需求中的业务用例模型识别参与者
- 参与者：在系统之外，通过系统边界与系统进行有意义交互的任何事物
要点：
- 任何事物 （参与者用小人表示，但是可以是everything）
参与者的命名：
规范的参与者命名：用能知道其角色的名称来命名
-
例如，学生、订单管理员、维护部门…
-
即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的
参与者之间的关系：泛化（继承）
泛化实例：
3.3、识别用例
关键词：提供的价值——业务功能
用例的特征：
-
用例实例是系统执行的一系列动作(执行过程)，这些动作将生成特定参与者可观测的结果值
-
一个用例定义一组用例实例（场景）
用例：参与者使用系统达到某个目标
用例的命名：
参与者（执行者）视角：动宾结构
用例粒度：指的是系统中某个用例所包含的系统服务或功能单元的多少。
-
用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。
-
最常犯错误：①粒度过细，陷入功能分解 ②把步骤当用例 ③把系统活动当用例 ④CRUD会掩盖业务，锐变成关系数据库的建模
采用管理用例解决CRUD问题：
-
多数的基本数据管理业务都可以用一个用例表示
-
-
可以把包含复杂交互的路径独立出去形成用例——用例扩展关系的利用
3.4、构建用例图
用例图：表达参与者与用例关系的图形
实例分析：旅游业务申请系统
四、编写用例文档
用例文档：更进一步对用例进行详细说明
- 需求规格说明书的核心，而用例图作为用例文档的索引图（也称软件功能总图）
- 有层次的文档
- 文档中每一句话都有其价值
用例文档的组成：
-
用例标识(UC)、名称、描述
-
涉及的参与者、涉及的用例
-
涉众利益——参与者的利益关系
-
前置条件 PreConditions（在用例开始前系统的状态）、后置条件 PostConditions（用例执行后系统的状态）
-
事件流
- 基本路径Flow of events
- 备选路径Alternate flow
-
补充约束
- 字段列表、业务规则
- 非功能需求、设计约束
-
待解决问题
-
相关图(用例图、活动图、类图)
事件流描述-用例交互四部曲：
事件流描述要点：
- ①使用业务语言，而非技术语言
- ②以参与者或系统为主语
- ③避免出现过细的GUI描述
- ④用例的重点在于描述功能需求
用例文档案例：记录时间 ，UC01：“Record Time”
| 用例标识 | UC01 |
|---|---|
| 用例名称 | Record Time |
| 涉及的参与者 | 雇员、系统管理员 |
| 描述 | 雇员利用“Record Time”用例来登记他们的工时，系统管理员用这个用例为任何雇员登记时间 |
| 前置条件 | 用户必须已经登录到这个系统 |
| 后置条件 | 系统将雇员的工时正确的记录到数据库中 |
| 正常事件流（雇员记录时间） | 1.雇员查看当前时间之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并在以后的视图中看到这个数据。 |
| 备选事件流（雇员更改时间） | 1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目；3.雇员改变工时；4.系统在视图中更新这个信息，并在以后的视图中都可以看到。 |
| 非功能需求 | 无 |
| 设计约束 | 无 |
| 部署约束 | 用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙 |
| 未解决的问题 | ①雇员是否可以在以前的考勤卡上输入和更改时间？②雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？ |
| 相关图 | 用活动图来描述该用例的执行过程，即：场景（用户可以按照场景的描述来验证系统是否达到了预期目标——验证用例的有效性。） |
活动图-简述用例流程：
五、重构用例模型
利用用例建模的高级技术重构用例模型：
- 用例关系——可降低用例的复杂度
- 用例分级——可寻找重要的用例
- 用例分包——可按应用来组织管理用例
5.1、用例关系
5.1.1、扩展
某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示某个用例的功能被扩展
扩展使用带有 <<extend>> 的虚线表示。箭头由扩展的用例指向基用例，通过扩展点指明在基用例中的扩展位置
基用例路径本身是完整的，可能是一条被扩展的路径。其特点主要表现为：
-
扩展路径步骤多
-
扩展路径内部还有扩展点——扩展之扩展
扩展点必须是系统能感知的:
5.1.2、包含
某个用例中包含了其他用例的行为
用带有<<include>>的虚线来表示。箭头由原用例指向被包含部分的用例——用例的复用
何时运用包含：
-
某些步骤在多个用例中重复出现，且能单独形成价值
-
另外，用例步骤较多时，可用Include简化（慎用，会增加用例模型的复杂性）
5.1.3、扩展vs包含
包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能，离开用例B就无法工作
扩展：由用例B连向用例A。用例A描述了一项基本需求，用例B则描述了该基本需求的特殊处理情况，即一种功能扩展
案例：网络购物系统
5.1.4、泛化
泛化：表示子用例继承了父用例
用途：
- 一个用例可以特化另一个普通用例（普通用例泛化特殊用例）
用例泛化关系：
是指一种从子用例到父用例（比较抽象）的关系，它指定了子用例如何特化父用例的所有行为和特征。
5.1.5、扩展vs泛化
扩展用例只是对基用例进行功能扩展，而泛化用例是完全可以取代基用例的功能，并添加新的行为
5.2、用例分包
作用：
- 让用例图更为清晰地表现出系统的业务逻辑关系和层次
- 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式
分包方式：
-
按参与者分包
-
按主题分包
-
按开发团队分包
-
按发布情况分包
分包经验：先按主题分包，主题内再按参与者、开发团队和发布情况分包
案例：申请业务审查系统顶层用例包图
5.3、用例分级
用例和迭代开发的关系：
- 迭代开发中开发周期是围绕用例的需求来组织的
- 一个迭代周期需要被指派一个到多个用例。如果某个用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本和完整版本的用例，分阶段来完成。如图所示：
用例分级原则：寻找高级别用例（5种途径）
-
对架构设计有重要影响的用例，如：在领域层中包含多个类的用例、或者需要持久化（数据存储）的用例
-
不需要花费很多努力就可以从中获得重要信息和线索的那些用例，即代表主要的在线业务流程的用例
-
含有开发风险、时间紧迫或功能复杂的用例
-
涉及到重要技术研究或者新技术和高风险的用例
-
能产生直接经济效益或者降低成本的用例
用例分级实施策略：
- 可以使用一个简单的但是有些不精确的经验分类方法，如将用例划分成高、中、低三个等级
- 依照上述影响用例级别的特性(5种途径)给用例打分（特性也可能带有权值）
六、企业进、存、销管理系统案例分析
6.1、需求分析
（1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。
（2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。
（3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。
（4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。
（5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。
6.2、识别参与者
（1）销售员：为客户客提供销售产品的服务。
（2）仓库管理员：负责库存产品的管理活动。
（3）采购员：负责企业生产原料的订购。
（4）会计（统计人员）：负责企业经营状况的统计。
（5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。
6.3、销售员用例图
销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，获取商品信息，然后将销售信息更新，最后对客户进行商品销售。
6.4、仓库管理员用例图
仓库管理员能够通过该系统进行如下活动：
1、处理盘点，每天需要对库存产品信息进行盘点。
2、产品入库。当产品生产后，将产品进行入库。
3、产品出库。当产品销售发货后，进行出库处理。
4、管理设置。仓库管理员负责供应商信息、产品基本信息的管理设置。
6.5、采购员用例图
采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。
6.6、会计用例图
会计负责产品的统计分析管理，它能够通过该系统进行如下活动：
1、查询基本信息。会计能够查询产品的基本信息，根据产品的基本信息，制定出相应的方案。
2、查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。
3、查询供应商信息。会计能够查询供应商信息。
4、查询缺货信息。会计能够查询缺货信息。
5、查询报损信息。会计能够查询报损信息。
6.7、系统管理员用例图
系统管理员能够通过该系统进行如下活动：
1、维护员工信息。系统管理员能够维护企业员工的信息，如添加员工、删除员工和修改员工信息等。
2、维护供应商信息。系统管理员能够维护供应商的信息，如添加供应商、删除供应商和修改供应商信息等。
3、系统设置。系统管理员能够根据一些需要进行必要的系统设置。
