第四章 需求分析，用例分析法

---

一：需求分析的几种主流方法

原型法（反复迭代）

原型法是指在 获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。 反复进行这个过程，直到用户满意为止的一种方法。

先有成品，反复迭代

用例图

用例图(Use Case Diagram)是 由软件需求分析到最终实现的第一步 ，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员实现这些元素。用例图最常用来描述系统及子系统。

二：域建模：以OO思想构建术语表

在实际项目中，原始需求的描述形式可能是文字、活动图、序列图或其它形式，不管使用哪种形式，术语不统一的现象非常常见。

域建模

为项目创建一个术语表。确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域。

1. 域建模比普通的项目术语表优良的地方体现在：以图的方式清晰地显示出不同术语间的关系（减少理解偏差）。
2. 描述业务中涉及到的实体及其相互之间的关系，是帮助系统分析人员、用户认识现实业务的工具。
3. 域模型图将通过不断修正完善逐步演化为最终的静态类图。
   

域建模的步骤

示例：基于文字需求进行域建模

取款
银行客户将储蓄卡插入自助银行系统，系统提示用户输入密码。用户输入正确的密码，系统验证成功后，提示用户选择业务类型，用户选择“取款” 。系统提示用户输入取款金额，用户输入取款金额后，系统变更用户账户金额，然后给用户输出相应的钱。用户如果选择“打印凭条”，系统会为用户打印出凭证单。用户选择“退卡”，系统退出用户的银行卡。

第一步：提取名词或名词短语

取款：

1. 银行客户将储蓄卡插入自助银行系统，系统提示用户输入密码。
2. 用户输入正确的密码，系统验证成功后，提示用户选择业务类型，用户选择“取款” 。
3. 系统提示用户输入取款金额，用户输入取款金额后，系统变更用户账户金额，然后给
   用户输出相应的钱。
4. 用户如果选择“打印凭条”，系统会为用户打印出凭证单。
5. 用户选择“退卡”，系统退出用户的银行卡。

第二步：排除重复、相似

第三步：排除系统范围外和系统本身

第四步：画出第一版域模型图

第五步：整理第一版域模型

下面的空白是老版本的属性，现在操作的话不要求；

域模型之间的关系

== 泛化==[Generalization]，一般元素和特殊元素的关系。
关联[Association]，两个类之间存在着某种语义上的联系。

示例：基于模型图进行域建模

高级话题：域模型的迭代

预建模是系统分析时候做的。由系统分析人员制作。
数据模型是在设计的时候做的。

预建模的原则

三：用例分析：系统功能性需求分析的好工具

系统用例建模的意义

系统需求分析的目的是把视角从业务组织转向新系统，站在最终用户及其它干系人的角度看问题。

系统用例是对（新）系统为系统执行者提供的价值的建模。

业务用例 vs 系统用例

系统用例建模步骤

1. 绘制系统用例图

1. 确定系统边界

系统边界，即系统包含的功能与不包含的功能之间的界限。

通俗来说就是分割出系统内和系统外。

Ø系统内，需要我们投入大量的精力进行建设。
Ø系统外，需要我们考虑与它们的接口。

2. 识别系统执行者

执行者[actor]是在系统之外，透过系统边界，与系统进行有意义交互的任何事物。

识别执行者的方法(思考+头脑风暴)

• 谁使用该系统？
• 谁改变系统的数据？
• 谁从系统获取信息？
• 谁负责维护、管理并保持系统正常运行？
• 系统需要应付哪些硬件设备？
• 系统需要和哪些外部系统交互？
• 谁对系统运行产生的结果感兴趣？
• 有没有自动发生的事件？

--------------------------------------------------------------------


某汽车制造厂需要一套物料管理系统，该系统实现的部分功能如下：
Ø 工人领取物料，库存操作员交付物料给工人并在系统中记录物料变更情况；
Ø 工人退还余料给库房，库存操作员接收物料并在系统中记录物料变更情况；
Ø 库房管理员定期盘点库存；
	ü 缺货时，库房管理员通过系统通知供应商系统供货；
	ü 对积存的货物，库房管理员通过系统向供货商系统申请退货；
Ø 每日晚11点系统自动备份数据；
Ø 系统管理员负责维护系统正常运行；



----------------------------------------------------

• 谁使用该系统？
• 谁改变系统的数据？
• 谁从系统获取信息？
• 谁负责维护、管理并保持系统正常运行？
• 系统需要应付哪些硬件设备？
• 系统需要和哪些外部系统交互？
• 谁对系统运行产生的结果感兴趣？
• 有没有自动发生的事件？

库存操作员，库房管理员
库存操作员，库房管理员
库存操作员，库房管理员
系统管理员
xxx
供应商系统
库存操作员，库房管理员，供应商系统
时间
-----------------------------------------------------------

3. 识别系统用例

再谈用例（注意：这里是指系统用例，关注点由业务组织转向系统）

Ø系统用例是系统执行的一系列动作，这些动作可以生成“执行者”可观测的有价值的结果。
Ø通俗讲：系统用例是执行者通过系统可以达到的某个目标。

必须从执行者角度考虑:

• 这个用例有价值吗？
• 能达到什么目标？

识别用例的方法(思考+头脑风暴)

• 执行者想要从系统获得什么有价值的功能？
• 系统存储信息吗？哪些执行者将建立、读取、更新或删除这些信息？
• 当系统内部状态有变化时，系统需要通知参与者吗？
• 系统需要定期执行什么操作吗？
• 当发生了某些外部事件时，系统需要自动执行什么操作吗？
----------------------------------------------------------------


某汽车制造厂需要一套物料管理系统，该系统实现的部分功能如下：
Ø 工人领取物料，库存操作员交付物料给工人并在系统中记录物料变更情况；
Ø 工人退还余料给库房，库存操作员接收物料并在系统中记录物料变更情况；
Ø 库房管理员定期盘点库存；
	ü 缺货时，库房管理员通过系统通知供应商系统供货；
	ü 对积存的货物，库房管理员通过系统向供货商系统申请退货；
Ø 每日晚11点系统自动备份数据；
Ø 系统管理员负责维护系统正常运行。





• 工人领取物料，库存操作员交付物料给工人并在系统中记录物料变更情况；
• 工人退还余料给库房，库存操作员接收物料并在系统中记录物料变更情况；
• 库房管理员定期盘点库存；
	Ø 缺货时，库房管理员通过系统通知供应商系统供货；
	Ø 对积存的货物，库房管理员通过系统向供货商系统申请退货；
• 每日晚11点系统自动备份数据；
• 系统管理员负责维护系统正常运行。

4. 确定用例间的关系

• 用例之间的关系：

• 泛化[Generalize]。
• 包含[Include]。
• 扩展[Extend]。

思想：从现有的用例中抽取出公共的那部分信息，作为一个单独的用例。然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

包含关系：使用包含用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基用例复用。

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使基用例行为更简练和目标更集中。

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。

EA中系统用例建模

先发现执行者还是先发现用例？

• 执行者比用例明显。
• 执行者的个数远比用例的个数少。
• 找到一个执行者，就可以找到一堆用例。
• 执行者是系统外部人物的代表，所以当然是要先找到执行者，才能够从执行者的角度去寻找用例。

执行者与重要性无关

‘时间’执行者

时间是特殊的系统执行者

用例的命名

• 用例名称必须是动宾短语。（打电话，提交电话单）

• 采用域建模中的名词术语。（统一术语）

• 慎用弱动词弱名词——会掩盖真正的业务。（语义不明确）

  • 弱动词：进行、使用、复制、加载、生成……
  • 弱名词：数据、报表、表格、表单、系统……

用例≠功能

描述一个事物的三个出发点
	 这个事物是什么？——结构
	 这个事物能做什么？——功能
	 人们能够用这个事物做什么？——价值

用例≠步骤

用例是执行者对系统的一个愿望。

完成这个愿望可能需要经过很多步骤，但任何步骤不能够完整的反映执行者的目标。

怎么处理登录

系统用例里出现了非价值用例，目的是重用。
下面与右面都对，但是建议右面那个。

用例的“四轮马车”

用例与愿景目标

所有用例应该都能追溯到愿景目标。（满足当时期望）
所有的愿景目标都应有对应的用例实现。

用例分包

当存在大量用例时可以对用例进行分包

• 按执行者分包（主要）
• 按主题分包
• 按开发团队分包
• 按发布情况分包

不要滥用用例关系

2. 编写系统用例描述

3. 更新域模型

四：非功能性需求分析及需求定义与评审

需求评审

三种相对正式的评审

三种相对不正式的评审

1. 结对编程（/需求分析/设计/测试）。 一般是两个人，实践证明效率高
2. 轮查：交叉交换文档产物，互相提出意见。 互相交换，互相评审
3. 临时评审：在日常沟通中做回顾确认。例如和用户沟通时，对沟通内容做总结， 请用户确认理解是否一致。

需求审查：主要阶段

1. 规划：谁参加？评审什么

列席参与人主要是技术人员，一般不可以发言。

2. 总体会议（会前会）：

召集参加评审会的所有成员开一个简短的会议，讨论、 明确要评审的内容、评审的要点、评审时所需的资料、缺陷检查表

3. 准备：

评审人员提前阅读和准备，才能提出有价值的建议

4. 审查会议：

暴露问题、讨论问题，待审查文档应该符合：

1. 遵循标准模板，统一模板易于阅读和评审；
2. 已进行了拼写检查，减少文字错误带来的问题
3. 已检查了排版错误
4. 所有未解决问题提前标记好，避免大家浪费精力于还存在问题的地方

5. 返工：

评审中发现的错误必须得到重视和回应。

6. 跟踪

1. 解决问题：对评审提出的问题进行解决
2. 避免问题再次出现：对问题进行分类、因果分析，找到问题的深层次原因

需求规格说明书的检查要点

• 正确性； • 必要性；
• 优先级； • 明确性；
• 可测性； • 完整性；
• 一致性； • 可修改性

小结

• 需求分析就是确定新系统的目的、范围、定义和功能； 
• 域建模用来生成统一的关键术语表； 
• 用例建模用来定义系统的功能性需求； 
• 系统的非功能性需求通常包括RUPS； 
• 需求评审确认需求分析结果，然后才能进入设计阶段。