第4讲需求获取

1、需求获取需求获取教材教材P83 P83 第第4 4章章先思考几个问题？先思考几个问题？需求如何划分？（需求如何划分？（回顾回顾）需求工程的过程模型？（需求工程的过程模型？（回顾回顾）需求如何获取？需求如何获取？2022-6-52带着问题听课？带着问题听课？需求的初始表示方法？需求的初始表示方法？UMLUML？需求获取的过程模型？需求获取的过程模型？2022-6-53主要内容主要内容4.1 4.1 软件需求的初始表示软件需求的初始表示4.2 4.2 需求获取的过程模型需求获取的过程模型4.3 4.3 定义软件问题定义软件问题4.4 4.4 创建框架用例创建框架用例4.5 4.5 精化用例精化用例

2、4.6 4.6 评审用例模型评审用例模型2022-6-54需求获取需求获取目标：目标：收集、整理需求，业务语言阐述，收集、整理需求，业务语言阐述，形成文档。形成文档。地位地位：需求工程中后续活动的基础；需求工程中后续活动的基础；需求工程又是后续软件开发活动的基础。需求工程又是后续软件开发活动的基础。作用作用：软件项目的成败具有决定性影响软件项目的成败具有决定性影响。参与者参与者 = = 需求工程师需求工程师 + + 其他参与者其他参与者（委托方，投资方的客户、用户、项目软委托方，投资方的客户、用户、项目软件经理、质量保证工程师件经理、质量保证工程师）2022-6-55需求获取需求获取输入：输入

3、：u有关项目目标、范围及价值的有关项目目标、范围及价值的概述性文档概述性文档u项目项目合同合同或任务书或任务书u经评审通过的本次需求工程迭代的经评审通过的本次需求工程迭代的工作计划工作计划。输出：输出：u描述软件需求的描述软件需求的初步的初步的需求模型需求模型。该模型经过需求分析后将进化为正式的需求模型并该模型经过需求分析后将进化为正式的需求模型并成为成为需求规约需求规约的的主要组成部分主要组成部分。2022-6-564.1 4.1 软件需求的初始表示软件需求的初始表示2022-6-574.1.1 4.1.1 用例用例（一）用例的概念（一）用例的概念从外部用户的视角看，一个从外部用户的视角看，

4、一个用例（用例（use caseuse case）是是执行者执行者(actor)(actor)与目标软件系统之间一次典型的交与目标软件系统之间一次典型的交互作用，其效果就是互作用，其效果就是执行者在软件系统的帮助下执行者在软件系统的帮助下完成了某项业务功能完成了某项业务功能，或达成了某项业务目标。，或达成了某项业务目标。从软件系统内部的视角出发，一个用例代表着系从软件系统内部的视角出发，一个用例代表着系统执行的统执行的一系列动作一系列动作，动作执行的结果能够被外，动作执行的结果能够被外部的执行者所察觉。部的执行者所察觉。2022-6-58用例用例执行者执行者是指外部用户或外部实体在系统的交互过

5、是指外部用户或外部实体在系统的交互过程中扮演的角色，它与软件系统交换信息并使用程中扮演的角色，它与软件系统交换信息并使用软件系统的功能。软件系统的功能。p如果多个用户在使用目标软件系统时扮演同一角色，如果多个用户在使用目标软件系统时扮演同一角色，这些用户用单一执行者表示。这些用户用单一执行者表示。p如果一个用户扮演多种角色，则需要用多个执行者来如果一个用户扮演多种角色，则需要用多个执行者来表示同一用户。表示同一用户。p执行者可以是一类用户，也可以是其他软件系统或物执行者可以是一类用户，也可以是其他软件系统或物理设备。理设备。2022-6-59用例用例想一想课程注册管理系统的想一想课程注册管理系

6、统的执行者执行者有哪些？有哪些？2022-6-510用例用例想一想课程注册管理系统的想一想课程注册管理系统的用例用例有有哪些？哪些？2022-6-5114.1.2 4.1.2 用例图用例图UMLUML的用例模型的用例模型由由一到多幅一到多幅用例图用例图构成，它构成，它们表示从软件系统的们表示从软件系统的外部使用者外部使用者的角度看的角度看到的到的各项系统功能各项系统功能，并清晰地说明，并清晰地说明软件系软件系统的边界统的边界，即，用例图中的所有用例的集，即，用例图中的所有用例的集合构成目标软件系统应该提供的功能，除合构成目标软件系统应该提供的功能，除此之外软件系统不再承诺其他功能。此之外软件系

7、统不再承诺其他功能。2022-6-512图图4.14.1课程注册管理系统的课程注册管理系统的用例图用例图2022-6-513用例之间的关系用例之间的关系用例之间的关系用例之间的关系主要有三种：主要有三种：包含包含（includeinclude）、扩展（）、扩展（extendextend）和继承）和继承 。执行者之间的关系：继承执行者之间的关系：继承上述关系能在图上述关系能在图4.14.1中找出吗？中找出吗？布局规则布局规则针对用例图中的每个用例，给出文档化的针对用例图中的每个用例，给出文档化的描述描述2022-6-5142022-6-5154.1.4 4.1.4 类图类图类图描述面向对象软件系

8、统的类图描述面向对象软件系统的静态结构静态结构。u类图的类图的结点结点表示系统中的类及其表示系统中的类及其属性和操作属性和操作u类图的类图的边边表示类之间的表示类之间的关系关系。在需求获取或业务理解在需求获取或业务理解的过程中，类图可用于的过程中，类图可用于表达表达领域概念模型领域概念模型，即业务领域中的概念及概，即业务领域中的概念及概念之间的关系；念之间的关系；在需求分析阶段在需求分析阶段，类图可用来表示软件需求模，类图可用来表示软件需求模型之型之静态结构静态结构部分；部分；在软件设计和实现阶段在软件设计和实现阶段，类图表示，类图表示软件的结构软件的结构及详细设计及详细设计。l类图的构造在面

9、向对象分析与设计过程中处于类图的构造在面向对象分析与设计过程中处于核心地位核心地位。2022-6-516图图4.2 4.2 课程注册管理系统的类图课程注册管理系统的类图2022-6-517图图4.4 4.4 类间关系的表示图元类间关系的表示图元2022-6-518c）组合关系的表示（d）依赖关系的表示（e）实现关系的表示 （f）继承关系的表示类之间的关系类之间的关系UMLUML将面向对象中的将面向对象中的聚合概念聚合概念区分为（区分为（共享）共享）聚合（聚合（aggregationaggregation）和和组合（组合（compositioncomposition）两种关系两种关系。u在在聚合

10、关系聚合关系下，作为部件类的对象可能是多个整下，作为部件类的对象可能是多个整体类的对象中的组成部分，比如一名学生可以同体类的对象中的组成部分，比如一名学生可以同时参与多个兴趣小组；时参与多个兴趣小组；u在在组合关系组合关系下，一个部件类的对象只能位于一个下，一个部件类的对象只能位于一个整体类的对象之中，一旦整体类对象消亡，其中整体类的对象之中，一旦整体类对象消亡，其中包含的部件类对象也不能苟活。换句话说，整体包含的部件类对象也不能苟活。换句话说，整体类必须具备完整的管理部件类生命周期的职责。类必须具备完整的管理部件类生命周期的职责。例如，根据图例如，根据图4.24.2，如果一门，如果一门“课程

11、课程”被取消，那被取消，那么，其中包含的所有么，其中包含的所有“课程设置课程设置”对象均须删除。对象均须删除。2022-6-519UML表示法表示法UML表示法表示法类之间的关系类之间的关系假如假如A A类的某个方法中，使用了类的某个方法中，使用了B B类，那么类，那么就说就说A A类依赖于类依赖于B B类，它们是依赖关系。类，它们是依赖关系。A A类的某个方法使用类的某个方法使用B B类，可能是方法的参类，可能是方法的参数是数是B B类，也可能是在方法中获得了一个类，也可能是在方法中获得了一个B B类实例。但无论是哪种情况，类实例。但无论是哪种情况，B B类在类在A A类中类中都是以都是以局

12、部变量局部变量的形式存在的。的形式存在的。u依赖关系是有向的依赖关系是有向的2022-6-520类之间的关系类之间的关系实现关系实现关系是一种特殊的是一种特殊的依赖关系依赖关系，它表示，它表示一个类实现了另一个类中定义的对外接口。一个类实现了另一个类中定义的对外接口。2022-6-521类类Circle、Rectangle实现了接口实现了接口Shape的操的操作作Shape+ Draw ()Circle+ Draw ()Rectangle+ Drarw ()布局规则布局规则类图往往是软件模型图中最复杂同时也最关键的一张类图往往是软件模型图中最复杂同时也最关键的一张UMLUML视图。为提高其可理

13、解性，本书推荐以下布局规则：视图。为提高其可理解性，本书推荐以下布局规则：（1 1）尽量沿垂直方向表示继承、实现关系，沿水平方向尽量沿垂直方向表示继承、实现关系，沿水平方向表示关联、聚合、组合、依赖、实现关系表示关联、聚合、组合、依赖、实现关系。在继承关系中，。在继承关系中，父类应位于子类的上方；在单向关联、依赖和实现关系中，父类应位于子类的上方；在单向关联、依赖和实现关系中，方向尽量从左至右；在聚合、组合关系中，整体类一般位方向尽量从左至右；在聚合、组合关系中，整体类一般位于部件类的左面。于部件类的左面。（2 2）在关联边上，多重性、角色名、约束特性等）在关联边上，多重性、角色名、约束特性等

14、应靠近应靠近关联端关联端。（3 3）如果多条边表示相同种类的关系，它们有公共的类）如果多条边表示相同种类的关系，它们有公共的类端点，并且在公共端的标注相同，则汇合这些边。例如，端点，并且在公共端的标注相同，则汇合这些边。例如，图图4.24.2将将“用户用户”与与“教务管理员教务管理员”、“教师教师”和和“学生学生”之间的三条继承边汇合，布局成树形结构。之间的三条继承边汇合，布局成树形结构。2022-6-5224.1.5 4.1.5 活动图活动图活动图活动图描述实体为完成某项功能而执行的描述实体为完成某项功能而执行的操作序列操作序列，其中的某些操作或者操作的子序列可以其中的某些操作或者操作的子序

15、列可以并发和同步并发和同步。活动图适合描述在没有活动图适合描述在没有外部事件触发外部事件触发的情况下的系的情况下的系统内部的逻辑执行过程；否则，状态图更容易描述。统内部的逻辑执行过程；否则，状态图更容易描述。类似于传统意义上的类似于传统意义上的流程图流程图。活动图主要用于：活动图主要用于：u业务建模业务建模时时，用于详述业务用例用于详述业务用例，描述一项业务的执描述一项业务的执行过程；行过程；u设计时设计时，描述操作的流程。描述操作的流程。在描绘对象之间的交互协作方面，活动图不如交互在描绘对象之间的交互协作方面，活动图不如交互图；在描绘对象的行为方面，活动图不如状态图。图；在描绘对象的行为方面

16、，活动图不如状态图。2022-6-523活动图活动图事物事物活动 (ActionState) 动作的执行起点 (InitialState)活动图的开始终点(FinalState) 活动图的终点对象流(ObjectFlowState)活动之间的交换的信息发送信号(signalSending)活动过程中发送事件，触发另一活动流程接收信号(SignalReceipt)活动过程中接收事件，接收到信号的活动流程开始执行泳道(SwimLane)活动的负责者活动图关系活动图关系迁移迁移(transition)活动的完成与新活动的开始活动的完成与新活动的开始分支分支(junction point)根据条件，控

17、制执行方向根据条件，控制执行方向分叉分叉(fork)以下的活动可并发执行以下的活动可并发执行结合结合(join)以上的并发活动再此结合以上的并发活动再此结合图图4.5 “4.5 “制订课表制订课表”用例的活动图用例的活动图2022-6-526需求获取的过程模型需求获取的过程模型用例驱动（用例驱动（use case drivenuse case driven）的需求获取过程，主要步）的需求获取过程，主要步骤（活动）如下：骤（活动）如下： 定义软件问题；定义软件问题； 创建框架用例；创建框架用例； 精化用例；精化用例； 评审用例模型。评审用例模型。这些步骤可按序组织为需求获取工作流。这些步骤可按序

18、组织为需求获取工作流。 图图4.6 4.6 需求获取工作流需求获取工作流2022-6-5274.3 4.3 定义软件问题定义软件问题定义软件问题活动的目标是：定义软件问题活动的目标是： 理解软件要解决的主要业务问题、业务背景，尽量理解软件要解决的主要业务问题、业务背景，尽量消除需求工程师与用户之间的交流障碍；明确待开发消除需求工程师与用户之间的交流障碍；明确待开发软件系统的目标、业务价值、范围及边界。软件系统的目标、业务价值、范围及边界。定义软件问题过程如下：定义软件问题过程如下：标识客户和用户；标识客户和用户；理解业务背景；理解业务背景；策划并实施需求调查；策划并实施需求调查；定义软件系统的

19、轮廓，包括其目标、业务价值、定义软件系统的轮廓，包括其目标、业务价值、范围及边界。范围及边界。2022-6-528图图4.7 4.7 家庭保安系统的领域概念模型家庭保安系统的领域概念模型（初步）（初步）2022-6-529图图4.8 4.8 家庭保安系统的家庭保安系统的业务处理流程业务处理流程 局部局部2022-6-5国防科技大学计算机学院304.4 4.4 创建框架用例创建框架用例目的：目的：为了避免需求工程师为了避免需求工程师过早陷入细节过早陷入细节而忽视而忽视全局，先创建框架用例再填充，非一次完全局，先创建框架用例再填充，非一次完成每个用例的所有细节。成每个用例的所有细节。本活动的目标：

20、本活动的目标： 提取框架用例，并通过它们完整地覆盖用提取框架用例，并通过它们完整地覆盖用户需求面。户需求面。2022-6-531创建框架用例创建框架用例创建框架用例的子活动如下：创建框架用例的子活动如下：策划并实施用例调查；策划并实施用例调查；以框架用例记录用例调查的结果；以框架用例记录用例调查的结果；创建用例图；创建用例图；整合并评审框架用例。整合并评审框架用例。 框架用例的框架用例的主要创建者主要创建者是需求工程师（团队）。是需求工程师（团队）。用户和客户是本活动的用户和客户是本活动的重要参与者重要参与者，负责提供相，负责提供相关的信息和咨询，其中至少应有一人能够扮演业关的信息和咨询，其中

21、至少应有一人能够扮演业务领域专家的角色。务领域专家的角色。2022-6-532例例4.5 4.5 框架用例框架用例针对家庭保安系统，其框架用例有针对家庭保安系统，其框架用例有 “命令响应命令响应”和和“传感器监测传感器监测”。 用例名：命令响应。用例名：命令响应。业务目标：响应用户的开关机、复位命令、配置命令及系统运行日志查询业务目标：响应用户的开关机、复位命令、配置命令及系统运行日志查询命令。命令。执行者：用户。执行者：用户。业务规则业务规则1 1：在关机、复位及更改配置数据前必须输入正确的用户密码。：在关机、复位及更改配置数据前必须输入正确的用户密码。业务规则业务规则2 2：处于报警状态时

22、，系统不响应配置命令。：处于报警状态时，系统不响应配置命令。性能需求：用户命令的响应时间小于性能需求：用户命令的响应时间小于1.51.5秒。秒。 用例名：传感器监测。用例名：传感器监测。业务目标：接收并判别来自传感器的数据是否正常，一旦发现异常即报警。业务目标：接收并判别来自传感器的数据是否正常，一旦发现异常即报警。执行者：各类传感器，警报器，报警电话，显示器。执行者：各类传感器，警报器，报警电话，显示器。可靠性需求：误报率小于可靠性需求：误报率小于2%2%，漏报率小于，漏报率小于1%1%。2022-6-533例例4.6 4.6 质量需求清单及调查结果质量需求清单及调查结果类别类别质量需求项名

23、称质量需求项名称需求描述需求描述说明说明性能Req-Performance-001用户命令的响应时间小于1.5秒。Req-Performance-002异常发生与报警之间的时间差不超过3秒。可靠性Req-Reliability-001每周7天、每天24小时可用；在硬件无故障的前提下软件正常运行时间比在99.9%以上。Req-Reliability-002异常误报率小于2%，漏报率小于1%。Req-Reliability-003本软件的任何故障不可导致配置信息和日志数据的丢失。故障后系统在60秒内恢复正常。易用性Req-EasyUse-001用户可自行理解用户手册；通读用户手册后，勿需培训，即可

24、使用本软件。Req-EasyUse-002用户在通读安装手册后，勿需培训，通过安装向导即可成功安装本软件。2022-6-534质量需求清单及调查结果质量需求清单及调查结果类别类别质量需求项名称质量需求项名称需求描述需求描述说明说明安全性认证需求Req-Authentication-001在通过密码验证后方可使用本软件。权限控制需求Req-Authorization-001在关机、复位、更改配置数据及查看系统运行日志前必须输入正确的用户密码。审计性需求Req-Audit-001本软件需记录系统运行日志，日志信息包括开、关机、复位时间，配置命令执行情况，发生的异常事件，以供审计。兼容性与相关标准的

25、兼容性Req-Compatibility-001遵循数字家居领域的相关业界标准，包括版本兼容性Req-Compatibility-002版本升级时新版本完全兼容旧版本。2022-6-535质量需求清单及调查结果质量需求清单及调查结果类别类别质量需求项名称质量需求项名称需求描述需求描述说明说明可配置性Req-Config-001设定传感器的数量、类型、安装位置，门窗传感器的灵敏度、烟雾浓度阈值以及报警电话号码等配置参数均可定制；支持不同品牌门窗传感器和烟雾传感器可扩展性Req-Extend-001未来可能的扩展：系统接入Internet，用户可远程发送命令、查看安全状态；扩展视频监控功能。可伸缩

26、性Req-Scalability-001目前最多支持50个传感器；以后增至500个支持楼宇安全监控，要求软件系统不需修改即可适应传感器数量的增大。互操作性暂无要求。本地化与国际化Req-Intl-001支持中文和英文两种界面，用户可在任一界面进行语言切换。可移植性本软件将来需移植至环境运行。2022-6-5国防科技大学计算机学院364.4.3 4.4.3 创建用例图创建用例图UMLUML用例图可以用来表示用例图可以用来表示执行者与用例之间的执行者与用例之间的关系关系、用例之间的关系用例之间的关系、执行者之间的关系执行者之间的关系。需求工程师主要关注需求工程师主要关注执行者与用例之间的执行者与用

27、例之间的关系，关系，待后面适当的时机再对这里创建的初步的用例待后面适当的时机再对这里创建的初步的用例图进行精化。图进行精化。例例4.7 4.7 用例图用例图例例4.54.5，家庭保安系统的用例有，家庭保安系统的用例有“命令响应命令响应”和和“传感器监测传感器监测”，其执行者有，其执行者有“用户用户”、“传感器传感器”、“控制面板控制面板”、“警报器警报器”和和“报警电话报警电话”。前两类执行者为主动执行者，后三类为被动执前两类执行者为主动执行者，后三类为被动执行者。见图行者。见图4.94.9。2022-6-537图图4.9 4.9 家庭保安系统的（初步）用例图家庭保安系统的（初步）用例图202

28、2-6-5384.4.4 4.4.4 整合并评审框架用例整合并评审框架用例整合和评审的目的：整合和评审的目的：u检查所有的框架用例联合起来是否足以覆盖利益相关检查所有的框架用例联合起来是否足以覆盖利益相关方的所有功能需求，是否遗漏重要的非功能需求。方的所有功能需求，是否遗漏重要的非功能需求。完整覆盖的标准：完整覆盖的标准：u假设所有用例和非功能需求全部实现，目标软件系统假设所有用例和非功能需求全部实现，目标软件系统的业务目标和价值是否得以实现？的业务目标和价值是否得以实现？u是否遗漏了位于目标软件系统的范围之内的功能？是否遗漏了位于目标软件系统的范围之内的功能？2022-6-5394.5 4.

29、5 精化用例精化用例本活动的目标是：本活动的目标是：将框架用例精化为严谨、将框架用例精化为严谨、完整的用例，精化用例图，在此过程中根完整的用例，精化用例图，在此过程中根据需要适当补充新的业务规则和非功能需据需要适当补充新的业务规则和非功能需求。求。精化框架用例的主要工作是：精化框架用例的主要工作是：确定每个框确定每个框架用例中的交互动作序列。架用例中的交互动作序列。2022-6-540精化用例精化用例精化用例子活动包括：精化用例子活动包括： 分解或合并用例分解或合并用例 构建完整用例构建完整用例 精化用例图精化用例图 精化业务规则及非功能需求精化业务规则及非功能需求以上子活动之间不存在严格的时

30、序关系。以上子活动之间不存在严格的时序关系。2022-6-541分解或合并用例分解或合并用例如，在课程注册管理系统中，如，在课程注册管理系统中，“制订课表制订课表”、“制订选课制订选课计划计划”、 “ “查询选课学生信息查询选课学生信息”等用例均需验证用户身等用例均需验证用户身份，所以，可设置公共的份，所以，可设置公共的“用户身份验证用户身份验证”子用例。子用例。当系统中用例数量很多时，可以按照以下原则适当地合并当系统中用例数量很多时，可以按照以下原则适当地合并一些粒度较小的用例。一些粒度较小的用例。合并业务上关系比较密切的多个用例。合并业务上关系比较密切的多个用例。例如，针对课程注册管理系统

31、，可以将例如，针对课程注册管理系统，可以将“注册课程注册课程”、“撤销注册撤销注册”两个用例合并为两个用例合并为“制订选课计划制订选课计划”用例。用例。在同一业务范围内，合并功能上相似的用例。在同一业务范围内，合并功能上相似的用例。例如，在家庭保安系统中，例如，在家庭保安系统中，“门窗监测门窗监测”和和“烟雾监测烟雾监测”两个用例基本相似，但略有不同。两个用例基本相似，但略有不同。可以考虑合并它们，在交互动作序列的表述中体现它们之可以考虑合并它们，在交互动作序列的表述中体现它们之间的差异。间的差异。2022-6-542构建完整用例构建完整用例重新研究用例名称、用例目标或功能描述重新研究用例名称

32、、用例目标或功能描述标识触发和前置条件标识触发和前置条件描述或精化原有的基本交互动作序列描述或精化原有的基本交互动作序列提炼并描述扩展的交互动作序列提炼并描述扩展的交互动作序列描述用户与软件系统交互过程中传递的信描述用户与软件系统交互过程中传递的信息项的主要内容息项的主要内容标识后置条件标识后置条件2022-6-5434.5.4 4.5.4 精化用例图精化用例图例例4.9 4.9 用例图的精化（用例图的精化（对比例对比例4.74.7）在图在图4.94.9的基础上，将的基础上，将“命令响应命令响应”用例分解为用例分解为“开关机及复位处理开关机及复位处理”、“日志查询日志查询”和和“系统配系统配置

33、置”三个子用例，因为它们之间的业务差异非常明三个子用例，因为它们之间的业务差异非常明显。显。分解后，原分解后，原“命令响应命令响应”用例再无存在的必要，故用例再无存在的必要，故将其从用例图中删除。将其从用例图中删除。基于基于“传感器监测传感器监测”用例设置其扩展用例用例设置其扩展用例“报警电报警电话未接通话未接通”，该用例专门处理报警时电话未接通的，该用例专门处理报警时电话未接通的特殊情况。特殊情况。由由“命令响应命令响应”分解出来的三个用例均要求验证用分解出来的三个用例均要求验证用户的身份（但开机不需验证用户的身份），所以将户的身份（但开机不需验证用户的身份），所以将它们在这方面的公共子功能表示为它们在这方面的公共子功能表示为“用户身份验证用户身份验证”用例，并在它们与此用例之间建立包含关系。用例，并在它们与此用例之间建立包含关系。2022-6-544图图4.10 4.10 家庭保安系统的用例图家庭保安系统的用例图2022-6-5454.5.5 4.5.5 精化业务规则及非功能需求精化业务规则及非功能需求在精化框架用例的过程中发现的新的业务规则、在精化框架用例的过程中发现的新的业务规则、新的非功能需求应加入至需求获取结果文档的适新的非功能需求应加入至需求获取结果文档的适当位置，还要根据需求获取的不断深入修改原先当位置，还要根据需求获取的不