需求工程:基础、原理和技术

波尔(Klaus Pohl)

计算机科学丛书

1：动机、2：需求:3：持续的需求工程

第1章 动机

1.1软件密集型系统

如果一个系统的功能和/或质量的核心部分是通过软件实现的，那么我们将其称为“软件密集型系统”。

❑信息系统：信息系统对信息或数据进行收集、存储、转换、传输和/或处理，其目标是在适当的时间和地点为用户（人或其他系统）提供他们所需要的信息。

❑嵌入式软件密集型系统：与信息系统相比，软件仅仅是嵌入式软件密集型系统的一部分，但却经常支撑着其创新性功能和质量特性。软件与硬件之间密切地集成在一起，即待实现系统中的硬件和软件之间经常存在复杂交互。

1.1.2开发软件密集型系统的挑战

挑战包括如下特征：

❑基于软件的创新：客户对于创新性的要求越来越多。

❑日益增加的复杂性：由于软件所实现的功能数量、不同系统间的集成、为满足客户需要而实现的系统变体等不断增加，软件密集型系统的复杂性也显著增加。

❑降低成本的压力：市场停滞、不断激烈的竞争、客户对于降低产品价格的要求等使得很多企业面临着持续降低成本的压力。

❑更短的开发时间：一方面复杂性在不断增加，另一方面软件密集型系统的开发必须在更短时间内完成。

❑更高的质量要求：软件正变得无处不在，并且被越来越多地用于实现安全相关甚至是安全攸关的系统功能。

复杂性不断增加的创新性软件密集型系统必须以更高的质量等级、更短的时间和更低的成本开发出来，而这正是软件密集型系统开发所面临的重大挑战。

1.2 需求工程的重要性

造成超支和功能实现不完整的原因：

缺少用户参与、不完整的需求、需求变更、缺少管理、技术能力不足、缺少资源、不现实的期望、模糊的目标、不切实际的时间要求、新技术、其他。

1.2.3 需求缺陷导致高成本

需求缺陷发现得越晚，所需要的移除成本越高。

提示1-1：需求工程日益增长的重要性
实践中需求工程重要性日益增长的原因包括：
❑由于需求缺陷导致的项目失败：
❑在系统开发后期阶段移除需求缺陷所需的成本将高出很多；
❑更加快速、高质量、低成本地开发创新、独特、复杂的软件密集系统所带来的挑战;
❑软件密集型系统在许多工业领域中的重要性日益增强；
❑更多的系统功能、与其他系统更加紧密的集成以及使用方式更加分化。

1.3组织上下文中的需求工程

需求工程总是处于特定的组织上下文之中。

需求工程过程通过交互接口获取信息，同时通过接口为其他过程提供信息。

需求工程也处于组织中所建立的开发过程之中。

涉众有着不同的利益和背景。在需求工程中，他们组成一个团队，负责对系统需求及期望的质量进行抽取、协商和文档化。如果合适的涉众能在适当的时间参与到需求工程中，需求缺陷和高代价的返工就可以显著降低甚至完全避免。

提示1-2：涉众
涉众是与待开发系统有利益关系的人员或组织

1.3.1与其他组织过程的相互关系

需求工程总是处于一个组织之中，因此会受到其他组织过程的影响，反之亦然。

❑与产品管理的关系：产品管理提出关键需求，需求工程对它们进行细化和修订（如果需要的话），以建立一个完整的需求规约。此外，需求工程一般也会向产品管理提供新抽取或构思的系统特征。

❑与市场营销的关系：市场营销为需求工程过程提供市场需要、趋势、竞争对手产品的相关信息、将来的发展计划等。反之，需求工程也会向市场营销提供有利于吸引新客户或开拓新市场的系统特征。

❑与客户关系管理的关系：客户关系管理收集来自当前客户的改进建议、要求、问题报告等信息。将它们整理成满足客户期望并能够解决所报告问题的一组需求。

1.3.2与其他开发活动的相互关系

❑与项目管理的关系：项目管理要考虑其他组织过程或单元（如产品管理、策略管理）所设定的目标，并且要对需求工程过程中所抽取的系统目标进行审查和批准。

❑与设计的关系：需求工程负责定义与所有这些设计活动相关的需求。

❑与质量保障的关系；质量保障的任务是确保系统的开发能够满足所期望的功能和质量需求。需求工程为质量保障和测试活动提供质量及功能需求。质量保障需要需求工程来解决在质量保障活动中所发现的需求缺陷，必要的话还需要需求工程来澄清一些需求以便能够得到合适的测试制品规约。

❑与系统维护的关系：系统需求规约用于确定所报告的缺陷或所需要的扩展是否导致定义新的需求，或者是否是已定义但未被正确实现的需求导致了缺陷或扩展要求。

第2章 需求

2.1术语“需求”

IEEE 610.12-1990标准将术语“需求”定义为：

定义2-1：需求
（1）用户解决某个问题或者达到某个目标所需要的条件或能力；
（2）一个系统或系统组件为了实现某个契约、标准、规格说明（规约）或其他需要遵循的文件而必须满足的条件或拥有的能力；
（3）对（1）或（2）中所描述的条件或能力的文档化表示。

需求不仅定义了
（1）用户的需要和目标，而且还定义了
（2）待开发系统由于组织需要、法律，或标准等方面的要求而需具备的条件和属性。
文档化或未被文档化的条件和能力都被称为需求。

使用术语“需求制品”来指代文档化的需求。

定义2-2：需求制品
需求制品是文档化的需求。

文档化的需求是执行所有其他开发活动的基础，因此对于任何开发项目而言都是根本性的。

**注：需求制品的定义和概念在本教程后续所有场景中都会使用，必须明确的理解，需求制品即是文档化的需求。言下之意是被理解并按规定格式记录的需求，具有可查询的背景和跟踪关系。

2.2 需求类型

相关文献和需求工程标准一般都对以下3种主要的需求类型进行了区分:

❑功能性需求；

❑质量需求；

❑约束。

2.2.1功能性需求

功能性需求说明了系统应向用户（人或其他系统；）提供的功能。

定义2-3：功能性需求
[功能性需求]是关于系统应提供的服务、系统针对特定输入如何响应，以及系统在特定情形下的行为的陈述。在某些情况下，功能性需求还会陈述系统不应做什么……
功能性的系统需求详细描述了系统功能、系统输入和输出、异常等。”

功能性需求通常使用3个互补但部分重叠的视图来进行文档化：数据视图、功能视图和行为视图。

定义了系统数据、功能和行为的需求是一种面向解决方案的需求。

目标是以一种与解决方案无关的方式定义的。

2.2.2 质量需求

定义2-4：质量需求
质量需求定义了一个整个系统或一个系统组件、服务或功能的质量特性。

质量需求的类型

质量属性

质量属性	简要描述
可用性	可用性是指系统处于实际可用且完全正常运行的时间的百分比
效率	效率是对系统有效利用硬件资源（如处理器时间、存储单元或通信带宽）的程度的衡量
灵活性	灵活性表示系统扩展新功能时需要付出多大努力
完整性	完整性反映了系统面对未授权的访问、破坏数据隐私性、信息丢失和恶意软件感染时，系统得到保护的程度
互操作性	互操作性表示系统与其他系统交换数据或服务的难易程度
可靠性	可靠性是指系统在特定时间段内无失效运行的概率
健壮性	健壮性是指系统或组件在面对非法输入、相连接的系统或组件故障、或非预期的运行条件下能够持续正确运行的程度
易用性	易用性衡量用户为准备输入、操作系统、解读系统输出需要付出多大努力
可维护性	可维护性是指在系统中系统修复缺陷或实施变更的难易程度
可移植性	可移植性是指将一个系统或组件从一个运行环境迁移到另一个运行环境需要付出多大努力
可复用性	可复用性是指一个组件能够在最初开发该构件的系统之外的其他系统中使用的程度
可测试性	可测试性是指软件组件或集成的系统能够被测试以查找缺陷的难易程度

非功能性需求

强烈建议不要使用“非功能性需求”这一术语。
大多数在需求规格说明中被划分为非功能性需求的那些需求，实际上都是不明确需求。

有两类非功能性需求：

❑不明确的功能性需求：非功能性需求很多时候都是在描述一个不明确的功能性需求。

❑质量需求：描述质量需求。

非功能性需求经常掩盖了不明确的功能性需求，并导致了对所期望的系统属性的多种不同解读。

**注：所以，当提到非功能需求的时候，应明确辨别出质量要求部分，然后把其余部分划为待明确的内容。不应该存在非质量，非功能的需求，那一定是不精确，无法说明真实意图的需求，应有风险警示。

一个不明确需求没有在需求工程过程中进行精化和细化，那么就会造成不同涉众以完全不同的方式理解该需求，从而导致潜在的风险。

因此，掩盖了不明确的功能性需求的非功能性需求应当进行精化。

强烈建议在书写规格说明的时候避免这类“非功能性”需求。 

提示2-1：如何处理“非功能性”需求
❑避免这类“非功能性”需求出现在需求规格说明中。
❑相反，要对功能性需求和（具体类型的）质量需求进行区分。
❑“非功能性”需求中通常隐藏着不明确的功能性需求。
❑只有很小一部分所谓的非功能性需求是质量需求。
❑对每个“非功能性”需求，检查其是否表示某个不明确的功能性需求，如果是则对其进行充分精化。

如果一个“非功能性”需求表示一个质量需求，那么该质量需求也可能是不明确的。

2.2.3约束

约束是对开发过程或待开发系统属性的限制。

定义2-5：约束
约束是一种限制了系统开发方式的组织或技术要求。

约束类型

约束可以通过来源进行区分。

另一个区分药束的方法是考虑被约束影响的主体。

约束的限制影响

每个约束都定义了一个对系统功能性和质量需求的实现的限制。约束限制了能够实现需求的可选方案范围，同样也限制了能够实现整个系统的可选方案范围。

即约束所导致的限制可能会排除所有可能的实现选项。

2.3问题VS.解决方案

2.3.1 开发过程中的“做什么”和“怎么做”

需求用来定义问题并说明“要开发什么”；而系统设计用来定义解决方案并说明“系统应如何开发出来”。

开发过程中的不同涉众对于他们的开发任务中的“做什么”和“怎么做”有着不同的视图。 

系统开发过程中的“做什么”与“怎么做”

对于给定的问题（做什么）存在着多个不同的解决方案（怎么做）。在开发过程中的每个阶段，通过迭代进行问题定义和解决方案描述，可能的解决方案的数量持续地精简。

2.3.3“做什么”和“怎么做”之间的交互

系统开发中的一个重要的观察就是定义问题（“做什么”）和提出解决方案（“怎么做”）这两种过程是紧密交织在一起的。

问题定义与解决方案开发不是单向的顺序执行过程。事实上，定义“做什么”和开发“怎么做”之间存在着复杂的交互。

需求是系统体系结构设计的基础。

需求工程与体系结构设计之间的交互作用

双高峰模型将需求工程和体系结构设计之间的交互关系描述为需求和体系结构交替进行的螺旋过程，并伴随着粗粒度制品逐渐转化为更细粒度的制品。

大部分需求在描述的时候都伴随着脑海中所考虑的（初步的）解决方案。

第3章 持续的需求工程

3.1传统系统分析

术语“系统分析”（systems analysis）包括在对一个现有系统或过程进行分析的基础上定义一个新系统（发布版本）需求的各种不同的方法。

传统的系统分析按照功能、数据和行为来定义一个系统所期望实现的功能方面。

结构化分析使用数据流图来描述系统功能以及每个功能的输入和输出数据流。

结构化分析要求基于对现有系统和/或过程的分析，在当前状态模型中对当前状态进行刻画，在此基础上再将所期望的变更集成到当前状态模型中，这样就得到了期望状态模型。

系统分析中的当前状态和期望状态

❑当前状态分析：在当前状态分析中，分析人员分析现有的系统和过程，并将所识别和收渠的需求记录在当前状态模型中。

❑期望状态定义：相关涉众分析当前状态模型并指出新系统所要实现的潜在改进。这些改进集成到当前状态模型（即调整当前状态模型以反映这改进）之后，就创建了期望状态餐型。因此，期望状态模型定义了待开发系统的需求。

期望状态模型的实现将产生一个新系统，其将替换或部分替换现实世界中的现有系统和或过程。

期望状态模型描述了待开发系统必须满足的需求。

3.2本质系统分析

系统的本质包含了系统所有的真实需求。真实需求是系统必须拥有的属性或能力，无论系统是如何实现的，即无论使用什么特别的技术及由此带来的约束。

3.2.1本质VS.对应物

定义3-1：系统的本质
真实需求是系统必须拥有以满足其目标的一种特征或能力，无论系统如何实现。我们将一个系统真实需求的完整集合称为系统本质或本质需求。

本质是由“一个所规划的系统如果使用完美的技术进行实现后所具有的所有特性”所构成。

待开发系统的本质模型在使用完美技术实现系统的假设之下定义了该系统的需求。

与系统本质相反，系统的对应物则定义在运用现实的、不完美的实现技术基础上。对应物模型因此经常被称为物理模型或实现模型。

3.2.2方法

本质系统分析区分当前状态模型和期望状态模型。

在本质系统分析中，当前状态模型是通过良好定义的规则转换为本质模型的，同时期望的变更是基于本质当前状态模型定义的。通过定义变更就创建了本质期望状态模型，然后再选择打算使用的对应物，即实现系统所要使用的具体技术。在所选择的对应物以及由此产生的限制基础上，就可以定义出所谓的物理期望状态模型。因此，物理期望状态模型定义了待开发系统的对应物。

3.2.3本质系统分析的优点

严格区分本质和对应物便于分析人员在不掺杂技术实现细节的情况下单独考虑系统功能。

本质模型呈现出以下几个优势：

❑本质模型更稳定：关于完美技术的假设使得本质模型独立于任何技术变化。

❑本质模型更小：本质模型通常小很多。

❑无设计限制：本质模型并不包含任何无意识的、隐式的设计决策，因为本质模型不定义任何技术。本

❑在本质方面，现有的系统和新系统通常没有明显的不同：相反，两个系统的各自的对应物通常却具有显著的区别，这主要是由于系统实现技术的不同以及由此所导致的限制。

本质系统分析的根本思想，即对本质和对应物二者的区分。

3.4 系统分析及面向阶段需求工程的缺点

需求工程中的涉众面临着为新的创新性系统功能与质量开发和抽取需求的问题。

将需求工程实现为早期开发阶段还有进一步的显著缺陷：

❑无持续性：需求工程仅在特定的时间段内进行。

❑当前状态分析需求：当开发下一个系统发布版本时，如果没有对需求进行持续更新，那么就只有过时的需求规格说明可用。

❑无系统性的需求复用：跨项目与产品边界的需求复用没有系统性的支持。

❑狭隘的关注点：在面向阶段的需求工程中，需求工程的关注点通常局限于正在开发的系统。

需求工程应当持续地在概念层次上抽取和记录现实世界中的相关变化，并将所有相关涉众纳入进来。

3.5需求工程是一个持续过程

持续的需求工程是一个跨越整个系统生存周期，甚至扩展到跨越项目和产品的活动。

区分两种持续的需求工程的质量层次：

❑需求工程作为跨生存周期的活动：需求工程作为一个跨生存周期的活动在整个开发过程中开展。需求工程活动在整个生存周期中保证需求抽取和管理的一致性和可追踪性。需求工程与所有其他开发活动之间都存在交互。

❑需求工程作为跨项目和跨产品的活动：将需求工程的范围扩展到包括跨越不同项目和产品的、持续的需求抽取和管理。所抽取的需求在专门的需求库中，以一种独立于具体系统开发的方式进行文档化和记录。

一个组织中的项目具有明显的共享领域，推荐将需求工程作为一种跨项目的活动来进行理解和实现。

从跨项目和跨产品的需求工程中获得的巨大优势包括：

❑系统的学习过程：持续的跨项目需求工程建立了一个制度化的学习过程，有利于项目间的需求交换和共享并提供了一个能够为所有未来的开发项目提供有价值的输入的最新的需求库。

❑保持最新的需求：持续的需求工程能够保证由系统上下文（如市场需求或法规）以及系统开发中导致的需求变更能够整合到文档化的需求中，即确保需求库是最新的。

❑较短的产品开发时间：因为文档化的需求总是最新的，每个开发项目开始时费时的当前状态分析就不再需要了。

❑跨项目的复用：作为一种跨项目活动的需求工程，将支持需求制品和其他相关的软件制品跨项目边界的复用。

❑清晰的职责：持续的需求工程要求明确安排一个或多个人负责需求的开发和管理。这些人因此具有清晰的责任，并且不局限于特定的时间段、不依赖于特定的开发项目。