第四章需求工程（ Requirements Engineering）

4.1 需求工程的定义（Requirements Engineering）

需求工程是指致力于不断理解需求的大量任务和技术。
建立了从设计到构建的桥梁
从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通活动并持续到建模活动
系统需求规约描述了一个基于计算机的系统的功能、性能和约束条件。
分析模型必须实现的三个主要目标：描述客户需要什么；为软件设计奠定基础；定义在软件完成后可以被确认的一组需求。
软件需求规范不包含设计解决方案

4.2 质量功能部署（quality funtion development，QFD）

QFD：将用户要求转换成软件技术需求。

QFD概念可应用于整个软件过程（不仅仅在需求收集中）

三种需求：

常规需求（norma）
预期需求（expected）
兴奋需求（exciting）

四种展开：（development）

功能展开
信息展开
任务展开
价值评估

4.3 E-R图

矩形：实体
菱形：联系
椭圆：属性，加在长方形上

4.4 开发用例（User Case）

用例是从某个特定参与者的角度出发，采用简明的语言描述一个特定的使用场景。
用例：user case，直译：使用的例子
用例表述的是：最终用户如何在一特定环境下和系统交互。
用例表示方法：可以是叙述性的文本、任务或交互的概要、基于模板的说明或图形的表示。
不管形式如何，用例都是从最终用户的角度描述了软件或系统。

开发用例的第一步

第一步：定义“参与者”（ participant ）

参与者是在将要说明的功能和行为环境内使用系统或产品的各类人员（或设备）
参与者是任何与系统或产品通信的事物，且对系统本身而言参与者是外部的。
当使用系统时，每个参与者都有一个或多个目标。
参与者与最终用户并非一回事。
典型的用户可能在使用系统时扮演了许多不同的角色。
参与者表示了一类外部实体（经常是人员，但不限于人员），在用例中他们仅扮演一种角色。
例如，考虑一个机床操作员（一个用户），他和生产车间（其中布置了许多机器人和数控机床）内的某个控制计算机交互。在仔细考察需求后，控制计算机的软件需要四种不同的交互模式（角色）：编程模式、测试模式、检测模式和纠错模式。
4个参与者可定义为：程序员、测试员、监控员和故障检修员。
思考：一个教务管理系统的参与者有哪些？

开发用例

需求获取是一个逐步演化的活动。
第一次迭代，往往只能识别主要的参与者，而对系统了解更多之后，才能识别出次要的参与者。
主要参与者直接且经常使用软件，和他们交互可以获取所需的系统功能并导出系统的预期收益。
次要参与者为系统提供支持，以便主要参与者能够完成他们的工作。
参与者确定后，开发用例可以考虑如下问题：
- 谁是主要参与者、次要参与者？
- 参与者的目标是什么？
- 场景开始前有什么前提条件？
- 参与者完成的主要工作或功能是什么？
- 按照故事所描述的还可能需要考虑什么异常？
- 参与者的交互中有什么可能的变化？
- 参与者必须通知系统外部环境的改变吗？
- 参与者希望从系统获取什么信息？
- 参与者希望得知意料之外的变更吗？

用例的缺点

不是面向对象的，没有主动应用的作用
两个用例间的关系没有严格定义
不显示系统中任何流或者依赖关系，没有表示操作顺序

用例图

在细化之前，往往会首先开发出用例图，包含以下几个内容：

参与者
用例
系统边界
以及参与者和用例直接的关联

4.5 需求工程的步骤

①起始：定义将要解决的问题的范围和性质

②获取：帮助利益相关者定义他们需要什么

③细化：精确定义和修改基本需求

④协商：调解冲突，协商如何定义优先次序？什么是必需的？什么时候需要？

⑤规格说明：可以是一份写好的文档/一套图形化的模型/一个形式化的数学模型等等

⑥确认：对需求工程的工作产品进行质量评估，确保其完整无歧义的说明了所有的系统。

⑦管理：对于需求变更的管理，评估每个建议的变更

4.6 需求分析建模原则（rule of thumb）

关注可见需求，不要陷入细节
增加对软件需求主体的理解
有些非功能的模型可以延后到设计阶段完成
低耦合
确认需求模型对所有利益相关者带来价值
简洁

4.7 实施需求工程时必须避免的三种错误

特性偏好：以功能覆盖率代表系统质量。软件失败的常见原因之一时缺少可使用的质量而不是丢失部分功能。解决方法：关注关键功能，必要的功能是必须交付的。
灵活性偏好：过分强调产品自适应性和配置便利，过分强调灵活性。灵活往往导致复杂。
性能偏好：过分强调性能。性能应和商业需求一致，与其他系统兼容。

4.8 需求建模模型

需求模型中的元素包括：

基于场景的元素
基于类的元素
基于行为的元素
基于数据流的元素

实践中，我们可以选择上述一种进行需求建模，也可以多种结合。

4.8.1 基于场景的建模（scenario-based-modeling，常用用例图、活动图描述）

基于场景的方法从用户的视角描述系统。
用户故事：描述对用户有价值的功能,好的用户故事应该包括角色、功能和商业价值三个要素：
- 角色：谁要使用这个功能。
- 功能：需要完成什么样的功能。
- 价值：为什么需要这个功能，这个功能带来什么样的价值。
基于场景建模步骤：
- 创建初始用例
- 细化用例
- 编写正式用例
例子：

前言：
通过需求收集会议得到，SafeHome住宅监视功能（子系统）由参与者房主执行的功能：
①选择将要查看的摄像机。
②提供所有摄像机的缩略视图。
③在计算机的窗口中显示摄像机视图。
④控制某个特定摄像机的镜头转动和缩放。
⑤可选择地记录摄像机的输出。
⑥回放摄像机的输出。
⑦通过Internet访问摄像机监视功能
随着和利益相关者更多地交谈，需求收集团队为每一个标记的功能开发用例。

创建初始用例：
通常，用例首先用非正式的描述性风格编写。如果需要更正式一些，可以使用结构化的形式重新编写同样的用例。
用例 – 描述性书写（非正式的）
用例：访问摄像头监视设备 —- 显示摄像头视图（ACS – DCV）
参与者：房主
描述：
如果我位于远方，我可以使用任何计算机上的合适的浏览器软件登陆SafeHome产品网站。输入我的用户ID和两级密码，一旦被确认，我可以访问已安装的SafeHome系统的所有功能。为取得某个摄像头视图，从显示的主功能按钮中选择”监视“，然后选择”选取摄像头“，将会显示房屋的平面设计图，再选择感兴趣的摄像头，另一种可选方法是，通过选择”所有摄像头“，可以同时从所有的摄像头查看缩略视图快照。当选择了某个摄像头时，可以选择”查看“，然后以每秒一帧速度显示的图像就可以在窗口中显示。如果希望切换摄像头，选择”选取摄像头“，原来窗口显示的信息消失，并且再次显示房间的平面设计图，然后就可以选择感兴趣的摄像头，以便显示新的查看窗口。
用例 – 用活动序列表现交互（正式点）
用例：访问摄像头监视设备 —- 显示摄像头视图（ACS – DCV）
参与者：房主
描述：
1.房主登录SafeHome产品网站。
2.房主输入用户ID。
3.房主输入两个密码（每个至少八个字符长度）。
4.系统显示所有的主要功能按钮。
5.房主从主要功能按钮中选择”监视“。
6.房主选择”选取摄像头“。
7.系统显示房屋的平面设计图。
8.房主从平面设计图中选择某个摄像头图标。
9.房主选择”查看“按钮。\

细化初始用例：
要完整地理解所描述的功能，必须说明所有可能的交互。
1.主场景中的每个步骤要通过如下提问进行评估：在这一步，参与者能进行一些其他活动吗？
2.在这一步，参与者有没有可能遇到一些错误的情况？
3.在这一步，参与者有没有可能遇到一些其他的行为？如果有，是什么？
4.这些问题的答案会得出一些次场景，次场景属于原始用例的一部分，是可供选择的行为。\

举例：次场景
例如，考虑前面描述的主场景的第6步和第7步：
6.房主选择”选取摄像头“。
7.系统显示房屋的平面设计图。
①在这一点上，参与者能进行一些其他活动吗？答案是肯定的。参考非正式的描述说明，参与者可以选择同时查看所有摄像头的缩略视图。因此，一个次场景可能是“查看所有摄像头的缩略视图”。
②在这一点，参与者有没有可能遇到一些错误的情况？作为基于计算机的系统操作，可能出现许多错误情况。在这里，我们仅仅考虑在第6步和第7步中说明的活动的直接错误条件，问题的答案还是肯定的。带有摄像头图标的房屋平面可能还没有形式，这样选择“选取摄像头”就导致错误情况：“没有为该房屋配置平面设计图”。该错误情况就成为一个次场景。
③在这一点，参与者有没有可能遇到一些其他的行为？问题的答案再依次是肯定的。当第6步和第7步发生时，系统可能遇到报警。这将导致系统显示一个特殊的报警通知（类型、地点、系统动作），并向参与者提供和报警性质相关的一组操作。因为这个次场景可以在所有的实际交互中发生，所以不会成为ACS-DCV用例的一部分。而且，将开发一个单独的用例—“遇到报警条件”，这个用例可以根据需要被其他用例引用。

除了以上三个常规问题外，还应该问下面的问题：
①在这个用例中是否有某些具有“有效功能”的用例出现？包括：引用确认功能，可能出现的出错条件
②在这个用例中是否有支持功能（或参与者）的应答失败？如：应答超时
③性能差**的系统是否会导致无法预期或不正确的用户活动？如：速度慢时用户的多重选择

编写正式用例

非正式用例对于需求建模常常是够用的。

但是，对于复杂的步骤场景，则需要更正的用例描述。

正式用例一般会有一个模板。模板内容包括：用例编号，用例名，参与者，前提条件，主要流程，异常处理等等。

模板内容细节可以根据情况微调。

下面是一个模板实例

用例：通过互联网访问摄像头监视 —— 显示摄像头视图（ACS – DCV）
迭代：2
最新更新记录：1月14日
主要参与者：房主
情境目标：从任何远程地点通过互联网查看遍布房间的摄像头输出
前提条件：必须完整配置系统；获得正确的用户身份证号和密码
启动：房主在远离家的时候决定查看房屋内部
场景：
1. 房主登录SafeHome产品网站。
2. 房主输入用户身份证号。
3. 房主输入两个密码（每个都至少）。
4. 系统显示所有的主要功能按钮。
5. 房主从主要功能按钮中选择“监视”。
6. 房主选择“选取摄像头”。
7. 系统显示房屋的平面设计图。
8. 房主从房屋的平面设计图中选择某个摄像头的图表。
9. 房主选择“视图按钮”。
10. 系统显示一个由摄像头编号确定的视图窗口。
11. 系统在视图窗口中以每秒一帧显示视频输出。\

异常：
1.身份证号或密码不正确或无法确认。– 参看用例：“确认身份证号和密码”。
2.没有为该系统配置监视功能。 – 系统显示恰当的错误信息；参看用例：“配置监视功能”。
3.房主选择“查看所有摄像头的缩略视图快照” – 参看用例：“查看所有摄像头的缩略视图快照”。
4.平面设计图不可用或未配置 – 显示恰当的错误信息，参看用例：“配置平面设计图”。
5.遇到报警条件 – 参看用例：“遇到报警条件”。
优先级：必须在基础功能之后实现，中等优先级。
何时可用：第三个增量。
使用频率：中等频度。
使用方式：通过基于个人计算机的浏览器和互联网连接到SafeHome网站。
次要参与者：系统管理员，摄像头。
次要参与者的使用方式：
6.系统管理员：基于个人计算机的系统
7.摄像头：无线连接。
未解决的问题：
8.有什么机制保护SafeHome产品的雇员在未授权的情况下能使用该功能？
9.足够安全吗？黑客入侵该功能将使最主要的个人隐私受侵。
10.在给定摄像机视图所要求的带宽下，可以接受通过互联网的系统响应吗？
11.当可以使用高带宽的连接时，能开发出比每秒一帧更快的视频速度吗？

上述例子中的部分UML图：

4.8.2 基于类的建模（class-based-modeling，常用类图、协作图（CRC）描述）

基于类建模要表示系统操作的对象、应用于对象间能有效控制的操作（也称方法或服务）、对象间的关系、已定义类之间的协作等。
基于类的分析模型的元素主要有：类和对象、属性、操作、CRC模型、协作图和包。
基于类的建模，就是要识别和表示这些元素。
类每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类。
类的建模分为五个部分

例如：

传感器Sensor类，可以用类图描述。
类相互之间的协作以及类之间的关联和交互等也需要描述，UML中有规范。
传感器Sensor的类图：

4.8.2.1 识别和分析类

识别分析类：可以通过检查需求模型开发的使用场景，或通过对为系统开发的用例或处理叙述进行“语法分析”，来进行识别。

具体做法：

首先用下划线画出每个名词或名词词组
将这些名词输入到一个列表中，同时标注出同义词。
筛选甄别，把描述问题的名词和解决方案的名词分开。

分析类的表现形式

在所有名词的基础上，找以下对应形式：

外部实体（例如，其他系统、设备、人员），产生或使用基于计算机的系统的信息，产生或使用基于计算机的系统的信息。
事物（例如，报告、显示、字母、信号），问题信息域的一部分。
偶发事件或事件（例如，所有权转移或机器人的一组移动完成），在系统操作环境内发生。
角色（例如，经理、工程师、销售人员），由和系统交互的人员扮演。
组织单元（例如，部门、组、团队），和某个应用相关。
场地（例如，制造车间或码头），建立问题的环境和系统的整体功能。
结构（例如，传感器、四轮交通工具、计算机），定义了对象的类或与对象相关的类。

上面是一种一般性归类方法，之所以这样做是为了防止两个问题：

防止漏掉未来系统中需要的类
防止误认为一些名词是系统中类

还有其他归类方法，如：按照数据产生者（源）、数据使用者（汇点）、数据管理者、查看（或观察者）类、辅助类。

特别注意：

什么不能是类或对象。
通常，绝不应该用“强制性的过程的名称”为类命名
例如：
- Image”图像“是类
- InvertImage”图像翻转“是操作，不应是类

举例：

描述如下：

名词列表如下：

分析筛选建议

分析师在考虑每个潜在的类是否应该包含在分析模型中时，可使用以下6个选择特征：

保留信息：只有当相关信息必须被记录才能保证系统正常工作时，潜在类在分析过程中才是有用的。
所需服务：潜在类必须具有一种可确认的、能用某种方式改变类的属性值的操作。
多个属性：在需求分析过程中，焦点应在于”主“信息；事实上，只有一个属性的类可能在设计中有用，但是在分析活动阶段，把它作为另一个类的某个属性可能更好。
公共属性：可以为潜在类定义一组属性，这些属性适用于类的所有实例。
公共操作：可以为潜在类定义一组操作，这些操作适用于类的所有实例。
必要需求：在问题空间中出现的外部实体，或者任何系统解决方案的运行所必须的信息，几乎都被定义为需求模型中的类。

分析筛选如下：

注意：

上面的表是不全面的，必须添加其他类以使模型完整；

某些被拒绝的潜在类可能成为那些被接受的类的属性；

问题的不同陈述可能导致作出不同的”接受或拒绝“决定。

如何确定某个潜在类是否应该真的成为一个分析类？

4.8.2.2 描述属性

属性是在问题环境下完整定义类的数据集合。

例如（仍是SafeHome实例）：

考虑为SafeHome定义System类。
房主配置安全功能以反映传感器信息、识别信息、报警响应信息、激活或关闭信息等。
可以用如下方式表现这些组合数据项：
- 识别信息 = 系统编号 + 确认电话号码 + 系统状态
- 报警应答信息 = 延迟时间 + 电话号码
- 激活或者关闭信息 = 主密码 + 允许重复次数 + 临时密码

说明：

等式右边的某些数据项可以精化到基础级，
可以为System类组成一个合理的属性列表。
通常，如果多个项和类相关联，就应避免把这个项定义为属性。例如：
- 传感器（Sensor）是整个系统（System）的一部分，因此并没有列为System类的属性。
- Sensor已经被定义为类，多个Sensor对象将和System类关联。

4.8.2.3 定义操作

操作：定义某个对象的行为。
通常可以粗略地划分为四种类型：
- 以某种方式操作数据；
- 执行计算的操作；
- 请求某个对象的状态的操作；
- 监视某个对象发生某个控制事件的操作。
操作必须”理解“类的属性和相关属性的性质。
定义操作中：
- 研究处理说明（或用例）合理选择属于类的操作
- 研究语法解析分离动词
例如描述：”为传感器分配编号和类型“ ”主密码用于激活和接触系统“ 表明：
- assign（）操作和Sensor类相关
- arm()和disarm()应用于System类
另外，操作还可能被划分成子操作

4.8.2.4 CRC建模

类-职责-协作者建模（Class – Responsibility – Collaborator,CRC）
- 职责：其实就是描述属性和定义操作（前面已经阐述）
- 类的协作者： 可以简单理解和自己有关系、有交互的类。
是一个简单方法，可以识别和组织与系统或产品需求相关的类。
CRC模型是表示类的标准索引卡片的集合：

4.8.2.5 描述两个类之间的关系

这部分在4.9.3.2中详细讲解。

4.8.3 基于行为的模型（behavioral models，常用状态图、序列图（时序图）描述）

状态图描述系统的状态，并显示事件如何影响系统状态。
序列图指示事件如何导致从对象到对象的转换。

4.8.3.1 生成行为模型

行为模型显示了软件如何对外部事件或激励作出响应。
类模型侧重的是系统的静态结构。
行为模型侧重的是系统的动态表示。
系统行为表示成一个特定事件和时间的函数。
可以简单理解成系统运行起来后，事件发生时系统如何转换，或随着时间的推移系统如何运转。
生成行为模型的步骤：
1. 评估所有的用例，以保证完全理解系统内的交互顺序。
2. 识别驱动交互顺序的事件，并理解这些事件如何与特定的对象相互关联。
3. 为每个用例生成序列。
4. 创建系统中的状态图。
5. 评审行为模型以验证准确性和一致性。

4.8.3.2 识别用例事件

用例表现了涉及的参与者和系统的活动顺序。
一般而言，只要系统和参与者之间交换了信息就发生事件。
识别用例事件，就是从场景中，找到事件及参与者，标记交换的信息及条件和限制
例如：

一旦确定了所有的事件后，这些事件需要被分配到所涉及的对象。
对象生成事件
- 房主生成输入密码事件
对象响应事件
- 控制面板识别比较密码事件
响应事件的对象一般会发生状态变化

4.8.3.3 状态表达

行为建模中，必须考虑两种不同的状态描述：
系统执行其功能时每个类的状态；
系统执行其功能时从外部观察到的系统状态。
类状态具有被动和主动两种特征。
被动状态是某个对象所有属性的当前状态。
对象的主动状态指的是对象进行持续变换和处理时的当前状态。
事件促使对象从一个状态转移到另一个状态。

4.8.4 面向流的建模（常用数据流图（DFD）描述，不属于UML图）

信息在软件系统中流动时会被转换，系统接受多种形式的输入；使用并将其转换；生成多种形式的输出。
早期，常用数据流图建模，而且形成了比较完善的结构化分析和设计方法。
随着系统庞大和复杂，该方法已经逐渐被抛弃。但在一些局部，我们还是可以采用的。

4.9 分析建模所使用的UML图

统一建模语言（Unified Modeling Language——UML）是一种面向对象的建模语言，它可以实现大型复杂系统各种成分描述的可视化、说明并构造系统模型，以及建立各种所需的文档，是一种定义良好、易于表达、功能强大且普遍适用的建模语言。

4.9.1 用例图（Use Case Diagram，基于场景建模）

4.9.1.1 用例图的含义

由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的视图称为用例图。

4.9.1.2 用例图的作用

用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的理解系统的功能。
借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。
用例图可视化地表达，具有直观、规范等优点，克服了纯文字性说明的不足。

4.9.1.3 用例图的构成

4.9.1.4 用例图之间的关系

泛化（Generalization）
包含（Include）
扩展（extend）

（1）泛化关系：是一种继承关系，子用例是父用例的一种特殊形式，它继承了父用例的所有结构、行为、关系。其中三角箭头指向父用例。

（2）包含关系：基本用例的行为包含了另一个用例的行为，是比较特殊的依赖关系。箭头方向由基本用例指向被包含用例。执行基用例时,每次都必须调用被包含用例, 被包含用例也可以单独执行。

例1：

当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系。其中提取出来的公共用例成为抽象用例，而把>原始用例变成基本用例或基础用例。箭头指向抽象用例。

说明：
阅读者在读书和借书的时候，都要登记记录，他们有登记记录这一共同的行为，所以把它提取出来作为一种抽象用例，借书和还书这两个基本用例中包含了登记记录这一抽象用例。

例2：

一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。

说明：

一般用户有很多功能，其中包括各种信息的查看，这时可以建立一个查询信息这一个用例，然后下面在包含查看余额、查看上机记录、查看充值记录这三个小用例。

（3）扩展关系：扩展用例在扩展点上增加新的维护和含义。扩展用例为基用例添加新的行为，箭头指向基本用例。

例子：

在机房收费系统当中，操作员在进行信息查询的时候，需要将查询到的信息导出为excel表格，这个导出excel用例相对于信息查询用例来说就是一个扩展用例

何时使用，如何区分？

什么时候使用包含关系：

当两个或两个以上的用例包含大量的一致行为的时候，可以抽象出一个抽象用例

当用例数量太多或过于复杂的时候，可以使用抽象用例包含一些小用例

什么时候使用扩展关系：

基本动作在一个用例中，如果这个基本用例还有其他动作，但需要在一定条件下才执行，可以将它放在扩展用例中

4.9.2 活动图（Activity Diagram，基于场景建模）

4.9.2.1 活动图的含义

活动图是一种用于描述系统行为的模型视图，它可用来描述动作和动作导致状态改变的结果。
通常，活动图用来描述单个用例或商业过程的逻辑流程、以及单个操作或方法的逻辑。
在UML中，活动的起点是活动图的开始状态，用黑的实心圆表示。活动的终止点是活动图的终止状态，用一个含有实心圆的空心圆表示。活动图中的活动既可以是手动执行的任务，也可以是自动执行的任务，用圆角矩阵表示。