第4章建立用例模型资料讲解

第29页
2020/10/13
4.5 确定用例
维护人员：
(1) 查询自己的派工单及报告信息 (2) 接受并处理自己的派工单 (3) 填写报告
第30页
2020/10/13
4.5 确定用例
系统管理员：
(1) 管理用户 (2) 维护基础资料 (3) 维护系统
第31页
2020/10/13
4.5 确定用例
(2) 业务处理。包括客户服务人员新增、修改、删除客户咨询信息；维 护人员处理客户问题、填写维护报告；部门领导处理投诉，安排任务等。
(3) 统计查询。包括客户资料查询、客户来电咨询查询、经验库查询、 客户服务系统用户信息查询、回访任务及维护报告查询等。
明确以上信息后，分析系统的参与者。
第23页
(3) 关联 ( Association)
关联用于表示参与者和用例之间的对应关系， 它表示参与者使用了系统中的哪些服务（用 例），或者说系统所提供的服务（用例）是被 哪些参与者所使用的。
第19页
2020/10/13
4.3 用例在需求分析中的使用
以课程注册系统为例，
当参与者是学生时，
学生使用该系统可以
第5页
2020/10/13
4.1 需求获取
3．分析问题
(1) 明确需要获取的信息（What） 通常需求获取需要获取的信息包括三大类：
a. 与问题域相关的背景信息（如业务资料、组织结 构图和业务处理流程等）；
b. 与要求解决的问题直接相关的信息； c. 用户对系统的特别期望与施加的任何约束信息。
(2) 客户服务业务处理模块。包括客户咨询服务处理，故障申报处理， 投诉处理，客户服务人员回访处理，维护人员上门处理，部门领导派 工处理。
(3) 信息查询统计模块。包括基础资料查询统计，客户咨询的查询与统 计，派工单完成情况，回访情况，维护报告查询统计以及相关报表的 查询。
第12页
2020/10/13
第27页
2020/10/13
4.5 确定用例
2. 解答问题
对于每一个参与者，相对应的用例如下：
第28页
2020/10/13
4.5 确定用例
客户服务人员：
(1) 登录系统 (2) 查询客户信息及咨询记录 (3) 查询经验库信息 (4) 查询基础资料信息 (5) 补充完善经验库信息 (6) 维护客户资料 (7) 维护来电记录
部门领导：
(1) 查询客户资料及咨询信息 (2) 查询项目及产品信息 (3) 查询维护人员派工单的执行情况 (4) 安排派工任务
第32页
2020/10/13
4.5 确定用例
3. 分析问题
确定用例主要是看各参与者需要系统提供什么 样的服务，或者说参与者是如何使用系统的， 用例命名往往采用动宾结构。参与者与用例连 起来读，往往是一条通顺的句子，例如：客户 服务人员（参与者）维护客户资料（用例）。
第4章 建立用例模型
4.1 需求获取 4.2 分析需求 4.3 用例在需求分析中的使用 4.4 识别参与者 4.5 确定用例 4.6 用例的粒度 4.7 用例间的关系 4.8 用例描述 4.9 用例建模 总结
第1页
2020/10/13
第4章 建立用例模型
需求分析就是分析软件用户的需求是什么。
第25页
2020/10/13
4.4 识别参与者
注意：
系统参与者一定是与系统有直接联系的事物，这里事物包括 人和其他系统。
在客户服务系统中，客户打电话给客户服务人员反馈问题， 客户服务通过系统对反馈的问题进行处理，在这个业务过程 中，客户并没有直接操作客户服务系统，就没有直接联系， 所以客户不是系统的参与者。
第7页
2020/10/13
4.1 需求获取
获取需求信息的渠道包括：
a. 用户或客户 b. 公司研发管理部门 c. 公司技术管理部门 d. 项目实施部门 e. 营销管理部门 f. 旧有系统的研发项目组 g. 来自项目组内
第8页
2020/10/13
4.1 需求获取
(3) 怎样获取需求（How） 需求获取技术包括但不限于：
2020/10/13
4.4 识别参与者
2. 解答问题
对于这个系统，通过需求陈述文档，可以得到以下一 些信息：
系统管理员维护系统用户帐号和产品项目信息。 客户服务人员维护客户资料、客户咨询以及经验库信息。 维护人员填写维护报告。 部门领导处理投诉。
所以创建以下参与者：系统管理员、客户服务人员、 维护人员、部门领导。
第21页
2020/10/13
4.3 用例在需求分析中的使用
与传统的功能分解方式相比，用例方法完全是从 外部来定义系统的功能，它把需求与设计完全分 离开来。
在面向对象的分析设计方法中，用例模型主要用 于表述系统的功能性需求，系统设计主要由对象 模型来记录描述。另外，用例定义了系统功能的 使用环境与上下文，每一个用例描述的是一个完 整的系统服务。用例方法比传统的SRS更易于被 用户所理解，它可以作为开发人员和用户之间针 对系统需求进行沟通的一个有效手段。
进行登录系统、注册
课程和查看报告的操
作。
学生
登录 注册课程
查看报告
第20页
2020/10/13
4.3 用例在需求分析中的使用
3. 分析问题
用例方法完全站在用户的角度上（从系统的外部）来描述系统 的功能。
在用例方法中，把被定义系统看作是一个黑箱，我们并不关心 系统内部是如何完成它所提供的功能的。
第6页
2020/10/13
4.1 需求获取
(2) 明确所获取信息的来源和渠道（Where） 需求信息的来源通常包括：
a. 来自客户的需求； b. 竞争对手的产品优势与不足； c. 国家政策、业务规则以及相关行业标准； d. 实施产品设计所需满足的需求； e. 执行测试验证工作所需满足的需求； f. 实施系统安装、维护所需满足的需求。
1. 问题引入
规划出了软件的功能模块，只是软件的功能框 架结构，下一步就需要明确描述每个模块的具 体内容。包含什么内容、能做什么操作，每一 个功能点的说明、业务规则、详细功能描述等 等。这些软件需求规格必须描述的内容需要有 个标准的表现方式。
第15页
2020/10/13
4.3 用例在需求分析中的使用
第33页
2020/10/13
4.5 确定用例
寻找用例可以从以下问题入手（针对每一个参与 者）：
(1) 参与者为什么要使用该系统？ (2) 参与者是否会在系统中创建、修改、删除、访问、
4.2 分析需求
3．分析问题
软件系统的需求分析可以由产品工程师或系统分析师 或两者分阶段合作完成全部的需求分析工作。其主要 任务是逐步细化所有的软件功能，找出系统各元素间 的联系、接口特性和设计上的限制，分析它们是否满 足需求，剔除不合理部分，增加需要部分。最后，综 合成系统的解决方案，给出待开发系统的详细逻辑模 型。其主要包括以下几个步骤：
用例方法首先描述了被定义系统有哪些外部使用者（抽象成为 Actor），这些使用者与被定义系统发生交互；针对每一参与者， 用例方法又描述了系统为这些参与者提供了什么样的服务（抽 象成为Use Case），或者说系统是如何被这些参与者使用的。
所以从用例图中，我们可以得到对于被定义系统的一个总体印 象。
第10页
2020/10/13
(4) 应能及时反馈有派工任务的消息给相关技 术工程师，并能保存其处理结果。
(5) 各部门领导应能对投诉的申请给予及时处 理，并能保存处理结果。
(6) 公司领导和部门领导应能及时查询客户的 来电内容，了解产品使用情况及客户服务人员 的售后服务质量等相关业务的综合统计信息。
第22页
2020/10/13
4.4 识别参与者
1. 问题引入
客户服务系统是对公司和客户进行统一管理的系统，根据客户服务 系统案例需求说明书，具体包括以下几个方面：
(1) 基础资料维护。包括系统管理员添加、删除、修改客户服务系统账 户信息，添加、修改、删除公司产品及项目信息；客户服务人员添加、 修改、删除客户资料信息，添加、修改、删除经验库信息等。
以上需求信息需要进行详细的分析、归纳。
第11页
2020/10/13
4.2 分析需求
2．解答问题
经过分析，为满足上述需求的客户服务系统应包括以下几个模块：
(1) 基础资料维护模块。包括客户基础资料录入修改，客户服务系统用 户信息的添加、删除和修改，软件产品的基础资料维护，已上线项目 的基础资料维护以及FAQ经验库的数据维护。
整个软件需求工程研究领域划分为需求开 发和需求管理两部分。
需求工程
需求管理
需求开发
第3页
问题获取
分析
编写规格说明
验证
2020/10/13
4.1 需求获取
2．解答问题
在需求获取过程中，主要需要弄清楚3个问题， 即：
明确需要获取的信息（What） 明确所获取信息的来源和渠道（Where） 怎样获取需求（How）。
第17页
2020/10/13
4.3 用例在需求分析中的使用
(2) 用例 (Use Case)
用例用于表示系统所提供的服务，它 定义了系统是如何被参与者所使用的， 它描述的是参与者为了使用系统所提 供的某一完整功能而与系统之间发生 的一段对话。
第18页
2020/10/13
4.3 用例在需求分析中的使用
a. 用户访谈 b. 用户调查 c. 现场观摩用户的工作流程，观察用户的实际操作 d. 从行业标准、规范中提取需求 e. 文档挖掘 f. 需求讨论会 g. 原型法
第9页
2020/10/13
4.2 分析需求
1．问题引入
通过需求获取，总结出客户服务系统主要功能需 求包括以下几个方面：1) 提取出核心、主要、急迫的业务，明晰业 务流程