第4章建立用例模型资料讲解
软件工程之用例模型总结
软件工程之用例模型总结一、用例模型1.用例概念用例：使用系统时发现的功能性需求，不应过于复杂，简单的来说就是你希望系统能够有什么功能，能够增加系统的价值。
用例模型包括用例描述和用例图，我们主要把中心放在用例描述上。
用例模型包含参与者和场景，场景包括成功场景和失败场景。
因此用例模型中有多个场景；每个场景是一个用例。
用例必须注重为用户提供可观察的返回值，就是系统触发了一个用例之后能够给用户带来什么。
一般用例都是黑盒用例，即不考虑如何实现。
e Case Description每个用例都有一个描述。
怎样确定用例？(1)确定一个功能；(2)写一个用例；(1)主要参与者：调用系统服务完成目标的人。
(2)次要参与者：为系统提供服务的人。
(3)写出每个项目相关人员的理想需求，从中分析功能。
(4)PreCondition:执行到这个用例之前必须为真的情况，比如必须已成功登录或通过验证。
(5)PostCondition:成功执行完此用例后的情况，比如登录用例的后置条件是成功登录（不考虑其他失败情况）。
(6)main flow：将最理想的步骤列出。
一般main flow步骤如下：(1)参与者发生动作。
(2)系统验证。
(3)返回结果。
(7)extension flow：扩展步骤,通常格式为：(1)系统检测到**有问题;在main flow中的第一步扩展，则用1a,1b,1c;3.如何确保正确的用例EBP原则:一般用例都需要遵守这个规则，即确定主要用例。
用例中的主要用例是一些重复做但是有意义的事，比如收银员收钱，重复多次是有意义的，因为钱收得多了；但是像登录系统，这种做100次却没有意义的用例，不能被称为主要用例；(1)EBP（基本业务过程）原则的用例写入；(2)如果要写编辑A，删除A，添加A，可以合并成“管理A”；4.用例图每个用例描述都是一个用例，左边是主要参与者（希望系统为他提供服务）和次要参与者（提供给系统服务的人）；在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据库的；关系：(1)泛化关系，在参与者和用例中都能泛化。
UML用例建模基本知识讲解
本节和大家一起学习一下UML用例建模的一些基本知识，主要包括基本文档，用例模型，用例规约和补充规约等内容，相信通过本节的学习你对UML用例建模一定会有所了解。
下面就让我们一起来看一下详细介绍吧。
UML用例建模基本知识基本文档：用例模型：记录功能性需求用例图：描述参与者和用例之间的关系用例规约：描述每一个用例的细节信息补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等词汇表：记录一些系统需求相关的术语------------------------------用例模型：用例图比较简单，主要有参与者和用例组成；参与者之间可以有泛化(Generalization)关系用例之间有包含(include)、扩展(extend)和泛化(generalization)关系。
包含是子函数，扩展是备选流泛化比较少用，也是备选流；UML用例建模中用例规约：简要说明(BriefDescription)简要介绍该用例的作用和目的。
事件流(FlowofEvent)包括基本流和备选流，事件流应该表示出所有的场景。
用例场景(Use-CaseScenario)包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
特殊需求(SpecialRequirement)描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
前置条件(Pre-Condition)执行用例之前系统必须所处的状态。
后置条件(Post-Condition)用例执行完毕后系统可能处于的一组状态。
UML用例建模的补充规约补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。
功能性功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。
有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。
第四章 用例建模
第四章用例建模什么是需求？需求包括哪几个方面？需求：客户可接受的、系统必须满足的条件或具备的能力需求包括：功能性、使用性、可靠性、性能、可支持性五大方面。
2、什么是需求分析?需求分析有何重要意思？需求分析可以分为哪几个步骤？答："需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输“做什么”。
意义：需求分析是一个重要的一个阶段。
软件需求分析的质量对软件开发的影响是深远的、全局性的，质量需求对软件开发往往起到事半功倍的效果，所谓“磨刀不误砍柴功。
在后续阶段改正需求分析阶段产生的错误将付出高昂的代价需求分析大致可分为以下步骤：绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
同时它也明确了通过接口的信息流和物质流。
2）创建开发原型：创建用户接口原型。
当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。
用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
注意要找出需求文档与原型之间所有的冲突之处。
3）分析可行性：分析需求可行性。
在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
4）确定需求优先级：确定软件工程需求的优先级别。
应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。
以优先级为基础确定产品版本将包括哪些特性或哪类需求。
当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5）为需求建立模型：为需求建立模型。
需求的图形分析模型是软件需求规格说明极好的补充说明。
它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6）编写数据字典：创建数据字典。
oolecture4
五．用例模型（Use-Case Model）⒈内容概述用例模型是以专门术语描述实际系统功能需求的原型。
在用例模型中，一个实际系统功能需求被表示为一个到多个系统行为（System Behavior）。
为便于描述系统行为的动态过程，在用例模型中还使用活动图（Activity Diagram）来描述系统内部状态的变化过程（还配套状态图和事件流图）。
激发一个系统行为的第一信息来源和目标被称为角色（Actor），而当系统行为发生后会对第一信息来源产生反应。
角色只能在系统边界以外，用例模型实际上表现了系统内外的作用与反作用的信息交流过程。
UML中的用例模型分别用表示实际系统功能和与其相关的环境的图形符号体系所构成。
角色是与系统信息交互的源点与终点。
用例是系统与角色交互的一个系统行为的总和，与其他系统行为不同的是用例要特别描述出与其相关的角色、作用约束、响应性能等重要的系统数据。
在用例模型中用带有简要文字说明的箭头将用例和角色连接到一起。
可视化建模语言UML由五类模型视图和九种图所组成。
⒉创建步骤转DEV475_02_Requirements.PDF文档，直到DEV475_05_Requirements.PDF讲后返回本文档。
⒊问题的陈述的结构陈述的主要内容·问题的范围；·分别陈述要求解的必须部分的问题内容和可选择部分的问题内容；·叙述应用的背景情况；要注意下述问题：–不要涉及系统内部的内容；–阐明系统应用背景的各种假设前提；–阐明系统应用的性能要求；⒋建立用例模型的步骤①内容与目的依据问题的陈述而描述出现实世界中的对象类极其相互间的关系。
②建立用例模型所需的必要信息材料·问题的陈述；·应用领域内的专业经验和知识；·对现实生活的广泛了解和多门类的经验；·多多的交流；③建立用例模型的步骤·标记对象与类；·制作数据字典；·标记对象间的关联关系和包容关系；·标记对象的属性和连接；·提取对象间的继承关系；·测试对象间的访问路径；·反复审核用例模型并归纳同类对象；·在模型中使用类组；上述步骤可由下图体现：⒌通过用例模型标记对象与类这一步由下述步骤组成：·从问题陈述中抽取名词；·生成静态系统交互图；·用静态系统交互图修改初始化表；·依据应用领域内的专业经验和知识可能提交扩展的问题陈述；·标记附加的对象；在本步的应用中应注意下面两点：⑴生成静态系统交互图（Context Diagrams）静态系统交互图（在UML中称为用例图）用来描绘系统的范围。
第4章__面向对象需求分析
• 在确定事件轨迹后，所有事件可以汇总成输入对象的事件 集和从对象输出的事件集。事件流图就是用于标记所有流入和 流出某对象的事件。
•
例：打印机对象—行为模型示例。
• 状态转换图表示了打印机的状态转换。图中的每个箭头代 表了从对象的一个状态到另一个状态的转变，箭头上标记的是 触发转变的事件。有时需要增加保护条件来满足对象的变迁， 例如，上图中打印机在故障状态时，故障修复事件只有在打印 队列不破坏的情况下才能使打印机进入打印状态，否则即使修 复也只能进入就绪状态。
工人
1..*
经理 管理
（1）关联
•限定关联 • 限定关联通常用在一对多或多对多的关联关系中，可以把 模型中的重数从一对多变成一对一，或从多对多简化成多对一。 在类图中把限定词放在关联关系末端的一个小方框内。 • 例如，某操作系统中一个目录下有许多文件，一个文件仅 属于一个目录，在一个目录内文件名确定了惟一一个文件。利 用限定词“文件名”表示了目录与文件之间的关系，可见，利 用限定词把一对多关系简化成了一对一关系。
（1）关联
•关联类 • 为了说明关联的性质可能需要一些附加信息。可以引入 一个关联类来记录这些信息。关联类也有属性、操作和其他 关联。
个人
0..*
授权
0..*
个人
授权 优先权 特权
用户和工作站的授权关联的关联类
3.对象-关系图
• （2）聚集
• 聚集也称为聚合，是关联的特例。聚集表示一类对象与 另一类对象之间的关系，是整体与部分的关系。
• 一.面向对象分析模型的组成结构 • 二.面向对象分析模型描述工具 • 三.面向对象分析的基本过程
• 四. 面向对象分析方法
• 五. 小结
一.面向对象分析模型的组成结构
05-建立用例模型模型实验
1.实验环境及设备要求⑴每人需要有可接入Internet的计算机一台，并可登录网络化实验管理域跟踪系统。
⑵计算机安装有Microsoft Visio 2003。
2.实验目的⑴掌握用例模型的设计与创建方法。
⑵掌握如何使用Microsoft Visio 2003建立用例图模型。
3. 实验（设计）任务某汽车配件公司，向顾客供应汽车配件，顾客是汽车用户或是汽车修配厂，配件公司的货源来自各种不同的配件制造工厂或批发商。
顾客可以当时购买，也可以预先订货，公司负责托运。
汽车配件公司管理系统由销售、采购和会计三个系统组成。
系统的主要逻辑功能和基本目标如下：⑴顾客的订货要求有三种形式，一是邮寄订货单，二是打电话，三是直接到汽车配件公司营业部来办理。
⑵不管用哪种方式，都以一种标准的订货单格式输入到系统内。
⑶对每一张订货单必须首先加以验证，是否填写正确。
验证的内容包括汽车配件名称、规格、编号、顾客名称、地址、电话、开户银行、帐号等信息。
⑷如果正确无误才能给以处理。
⑸如果有错误、应当输出错误信息，通知业务人员加以纠正。
⑹按订货项目检索配件库存，确定是否能够满足顾客的要求。
⑺如果当前的库存量能够完全满足顾客的要求，销售子系统开出发货单给顾客提货，并记入应收款明细帐以备会计收款，同时记入，销售历史存档，还要修改该配件库存量。
⑻如果这项配件的当前库存量不能全部满足顾客的订货要求，只能暂时提供一部分，那么对这部分配件办理销售业务(同第7条)；同时还要把暂时不能满足的部分记录到暂存订货单文件中，通知采购子系统向供应商订货。
⑼如果这项配件现在一件也没有，就要把这张订货单记录到暂存订货单文件中，并通知采购子系统向供应商订货。
⑽采购子系统根据要求，按订货配件汇总，再按供应商汇总，分别填写向供应商的订货单，一式两联。
第一联寄给供应商，第二联保存，以便到货后核对。
⑾当收到来自供应商的发货单(即配件已经到货)以后，采购子系统要根据订货单核对验收。
第4章 建立用例模型
学习内容
用例模型概述 系统用例模型 业务用例模型 用例描述文档规范
用例模型概述
用例的模型元素 用例图建模分析步骤 寻找用例的方法
用例模型概述
用例模型：主要用来描述系统和系统外部环境 的关系，直接影响着其他模型。 用例：是一组系统使用场景的集合，每个场景 又是由一些事件序列构成，发起这个事件的用 户就是系统使用的参与者。 用例图：是系统的高层描述，角色和用例，在 实现阶段则变成了对象和接口这样的底层描述。
系统用例模型
（4） 右击展开导航树上的“需求定义“节点，在弹出菜单中 选择”新建框图“，再在”新建框图“菜单下选择”用例图“ 。则在该包上增加了一个节点，一个名称以”usecasediagram“ 开头的节点，它代表这个用例图全局属性，可在属性选项卡中 修改该节点名称为“会议管理系统用例图”。
用例模型概述
1. 用例的模型元素
用例的表示：用例的表示符号为一个椭圆，下面是用例的名称 （也可以放在椭圆中间）。
取款 取款 图 4.3用例的表示法
用例模型概述
1. 用例的模型元素
（4） 关系：关系反应了参与者和用例之间,用例和用例之间
以及参与者和参与者之间的相互作用，用例和参与者之间是关 联关系，一般角色为用例的启动者，用单向关联，否则为双向 关联。 用例之间的关系有三种： 包含、扩展、泛化
系统用例模型
2.会议管理系统用例图模型元素识别结果
（4）系统：经过前面分析，未来系统将要实现 的需求特征包含：编辑会议申请、编辑会议 纪要、获取会议通知、分配会议室资源、发 送会议通知，这些元素属于系统内，其余在 系统外，属于系统环境 。
第4章 面向对象系统分析与对象类建模 2
⑶ 类的操作
其语法如下： [方向]名称：类型[ = 默认值] [direction] name：type [= default value] 方向可以取下述值之一： in输入参数，不能对它进行修改。 out输出参数，为了向调用者传送信息可以对它进 行修改。 inout输入参数，为了向调用者传送信息可以对它 进行修改。
第4章 面向对象系统分 析与对象类建模
教学目的
⑴ 掌握面向对象系统分析的过程 ⑵ 掌握系统用例模型的设计方法
⑶ 了解类和对象的概念、类与对象的关系等
⑷ 重点掌握系统用例模型的设计和对象与类图 的设计
4.1 面向对象系统分析
面向对象分析，就是抽取和整理用户需求并 建立问题域精确模型的过程。 面向对象分析过程从分析陈述用户需求的文 件开始 可能由用户（包括出资开发该软件的业主代 表及最终用户）单方面写出需求陈述，也可 能由系统分析员配合用户，共同写出需求陈 述 当软件项目采用招标方式确定开发单位时，
关联可以有方向，即导航。 一般不作说明的时候，导航是双向的，不需要在线上标出箭头。 大部分情况下导航是单向的，可以加一个箭头表示。 导航性描述的是一个对象通过链（关联的实例）进行导航访问另 一个对象，即对一个关联端点设置导航属性意味着本端的对象可 以被另一端的对象访问。 可以在关联关系上加箭头表示导航方向。 只在一个方向上可以导航的关联称为单向关联，用一条带箭头的 实线来表示。 在两个方向上都可以导航的关联称为双向关联，用一条没有箭头 的实线来表示。
关联的多重性是指有多少对象可以参与该关联，多重性可 以用来表达一个取值范围、特定值、无限定的范围或一组 离散值。 将多重性写成一个表示取值范围的表达式，其最大值和最 小值可以相同，用两个圆点把它们分开。 多重性说明对于关联另一端的类的每个对象，本端的类可 能有多少个对象出现，对象的数目必须是在给定的范围内。 可以精确地表示多重性为：一个（1）；多个（0..*）；一 个或多个（1..*）；整数范围，
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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) 提取出核心、主要、急迫的业务，明晰业 务流程