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

波尔(Klaus Pohl)

计算机科学丛书

4：需求工程框架、5：系统和上下文边界、6：系统上下文结构化组织

第4章 需求工程框架

4.1 需求工程的目标：在上下文中建立愿景

每一个需求工程过程都开始于一个致力于改变当前现状的目标。

将这种所构想的改变称为系统“愿景（vision）”。

一个愿景仅仅定义了应该改变什么，但并不说明变化的实现方式。

愿景并不是表达一种不切实际的设想。相反，愿景描述了一种清晰定义且可验证的目标，并且经常与实现目标的时间点相联系。对于开发过程中所涉及的所有涉众而言，愿景都是一种在整个开发过程期间的指导思想。

愿景与系统上下文是需求工程过程的两种根本性的输入。

4.2 框架概览

需求工程框架定义了在现有上下文中建立愿景所需要的需求工程过程的主要结构元素。

该框架主要由以下部分组成。

❑系统上下文：本框架将系统上下文分成4个部分：主体刻面、使用刻面、系统刻面与开发刻面。

❑三个核心需求工程活动：为了在现有的上下文中建立愿景，3个核心需求工程活动（抽取、文档化与协商）需要不断迭代执行。

❑两项横切活动：这两项横切活动（确认和管理）为核心活动提供支持，并保证了需求工程结果的正确性。

❑需求制品：我们的框架区分3种基本的需求制品类型：目标、场景以及面向方案的需求。

4.3 4个上下文刻面

软件密集型系统的需求在很大程度上受系统上下文的影响。对上下文的充分理解是开发一份好的需求规格说明的根本前提。

如果相关的上下文方面被忽略、考虑不充分，或未被充分地文档化，那么这将导致不正确的、不完整的需求规格说明。

4个上下文刻面的定义如下：

❑主体刻面：主体刻面包含了系统上下文中与系统相关的对象与事件。主体刻面中的对象和事件相关的信息必须在系统中加以表示。主体刻面也包含了一些影响系统中对象和事件相关信息表示的方面。

❑使用刻面：系统由人或其他系统使用从而达成一个目标或完成某项具体任务。使用刻面包含了与人或其他系统对本系统的使用相关的所有方面。

❑IT系统刻面：IT系统刻面由运行与技术环境的所有方面组成，包括那些定义了如何使用各种技术与运行环境的约束或指南的方针与策略。

❑开发刻面：开发刻面包含了与系统开发过程相关的上下文方面，包括过程准则与约束、开发工具、质量保障方法、成熟度模型、质量认证，以及其他确保软件密集型系统质量（如安全性、保密性）的手段或技术。

4.3.1 4个上下文刻面间的关系

每一个软件密集型系统都需要一种对现实世界中对象（存在于主体刻面中）信息的表示

系统使用现有的技术（存在于IT系统刻面中）实现现实世界对象信息的数字化表示。

系统根据所定义的功能来处理所表示的信息。该处理过程就是在IT系统刻面里进行的。

将处理后的结果展现给用户体现了IT系统刻面和使用刻面的关系。

系统用户对所获得的系统输出进行解读，并将其与主体刻面中的现实世界对象联系起来。

软件密集型系统本身是发生在开发刻面中的开发过程的产品。

4.3.2 4个上下文刻面的使用

对每个上下文刻面及其关系进行定义并使用简单的检查表，有利于对于系统上下文进行更加系统化的考虑，并得到质量更高的需求规格说明。

4.4 3个核心活动

从这3个维度可以导出需求工程的3个核心活动（文档化、抽取与协商，见4.4.2节）。

4.4.1需求工程的3个维度

❑内容维度：内容维度被用来理解所获取的系统需求。在需求工程过程中，我们必须抽取需求，包括新的或者创新性需求的开发。因此，需求工程过程的第一个基本目标可以定义为：所有相关的需求应当在所需要的细节水平上被明确地了解和理解。

❑共识维度：共识维度与相关涉众就已知需求的理解取得共识的程度相关。对系统需求的理需求的冲突应当尽早被发现。未解决的冲突会造成系统验收的风险，同时也将危及系统愿景的实现。将需求工程过程的第二个基本目标定义为在相关涉众间建立起对系统需求的充分共识。

❑文档化维度：文档化维度采用各种文档化/规格说明格式对系统需求进行文档化和规约描述。所有的需求都应当依照相关的格式和规范进行文档化与规约说明。

定义4-1：需求工程的目标
需求工程是一个协作式的、不断迭代以及增量的过程，旨在确保：
（1）所有相关的需求都在所需要的细节层次上得到了清晰的了解和理解；
（2）在相关涉众间建立起对于系统需求的充分共识；
（3）所有需求都依照相关的文档化/规约格式和规范进行了文档化和规约描述。

4.4.2 核心活动

每一个核心活动都服务于需求工程3个子目标之一的达成。

文档化

文档化活动的关注点是根据所定义的文档和规约规范，将所抽取的需求进行文档化和规约描述。

❑总体文档规范：这些规范适用于所记录的所有信息。这些规范一般定义文档布局、文档的头部信息以及文档作者和版本历史等的文档管理信息。

❑文档规范：规范适用于需求工程过程的各个阶段所定义的每一项需求。规范旨在保证需求文档的质量。

❑规约规范：适用于需求规格说明中所包含的所有需求。旨在保证需求规约描述的质量。一般情况下，规约规范要比文档规范更严格。

抽取

抽取活动的目标是要改进对需求的理解，即在内容维度上取得进展。

需求从涉众和其他需求来源那里抽取出来。

抽取活动的一个基本任务是系统地识别与系统相关的需求来源。

协商

系统必须满足不同涉众的要求和期望。涉众之间存在的不同见解就会导致冲突。

协商活动的目标具有两个层次：首先，不同涉众观点之间的所有冲突都必须识别并且明确表达出来；其次，应当（尽量）解决所有的冲突。

4.5 两个横切活动

横切活动用来支撑3个核心活动。

确认

确认活动是一个横切活动，它包括3个子活动：

❑需求制品的确认：需求制品的确认旨在发现需求中的缺陷。缺陷可以归因于3个维度中某个维度上的一个或多个目标未能达成。确认活动的一个关键目标就是按照内容、文档化和共识3个维度对需求进行确认。一个需求只有通过了所有3个维度上的确认才可以被用作后续开发过程的参考或者作为合同的一部分。

❑核心活动的确认：核心活动（文档化、抽取和协商）确认的目标是检查活动的执行是否符合过程规约和/或活动规约。

❑系统上下文考虑因素的确认：旨在确认需求工程是否按照所期望的方式对系统的上下文进行了考虑。旨在确认是否所有的相关涉众都在正确的时间参加到了需求工程过程中，以及4个上下文刻面中的所有相关的方面是否都进行了考虑。

管理

管理活动可以分为以下3个基本子活动：

❑需求制品的管理：包括整个系统生存周期中的需求制品管理。确定需求的优先级、需求的持久化保存、需求的配置管理和变更管理，以及需求追踪关系的维护。

❑活动的管理：对需求工程活动的规划和控制。

❑系统上下文的观察：旨在识别与系统相关的系统上下文的变更。一个相关的上下文变更通常会要求一个或多个需求工程活动的执行或者活动的重新规划。

5个活动之间的相互关系

一个需求工程活动的进行通常会引起附加的需求工程活动的执行。

4.6 3种需求制品

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

3种需求制品，分别是目标、场景和面向方案的需求。

4.6.1 目标

需求工程需要理解涉众对于待开发系统的意图。涉众的意图被刻画为目标。

定义4-2：目标
目标是关于系统的目的、属性或者使用的意图。

目标具有指示性的含义，即目标表达了对于系统的期望和要求。

目标刻画了涉众的意图，并且对系统的使用以及系统的实现进行了抽象。目标将系统愿景精化为系统将要实现的目的。

目标应当是与解决方案无关的，即一个目标不应该预先定义某个特定的解决方案。

对目标（涉众的意图）的明确定义有助于冲突解决。

4.6.2 场景

一个场景通常刻画了一个具体的系统使用实例。它说明了一个目标（或者一组目标）是如何满足（或者未满足）的。

一个场景描述了系统如何满足或者不满足某个目标的一个具体实例。一个场景可以在不同的抽象级别上定义交互序列。

定义4-3：场景
场景描述了一个目标（或者一组目标）被满足或者未被满足的一个具体实例。它提供了一个或多个目标的具体细节。一个场景通常定义了一系列为满足目标而执行的交互步骤，并将这些交互步骤与系统上下文联系了起来。

4.6.3 面向方案的需求

面向方案的需求定义了一个软件密集型系统上的数据视图、功能视图和行为视图。还包括（面向方案的）质量需求以及（面向方案的）约束。

面向方案需求的定义通常意味着一个概念（或逻辑）的系统解决方案。

4.6.4 3种需求制品的使用

在需求工程中，3种不同的需求制品（目标、场景和面向方案的需求）在需求工程中是相互补充使用的。

4.6.5 本文中的“需求”

使用术语“需求”时，都是指上面所提到的3种需求制品（目标、场景和面向方案的需求）。

提到需求抽取时，我们是指对目标、场景以及面向方案的需求的抽取。

面向方案的需求包括数据、功能、行为需求，以及（面向方案的）质量需求和约束。

定义4-4：需求（本书中使用的术语)
当我们使用术语“需求”时，我们是指目标、场景以及面向方案的需求（即数据、功能和行为需求，以及面向方案的质量需求和约束）。

第5章 系统和上下文边界

5.1 术语“上下文”

在不考虑系统所处环境中相关部分和方面的情况下，系统需求将无法进行适当的定义、理解或解释。忽视或错误地理解系统环境的重要方面很可能会导致需求规约中的严重缺陷。

定义5-1：系统上下文
系统上下文是系统所处的环境中与定义、理解和解释系统需求相关的那些部分。系统上下文由4个上下文刻面组成：主体刻面、使用刻面、IT系统刻面、开发刻面。

系统开发中必须考虑的系统环境的那些部分被称为系统上下文。

❑系统边界：通过定义系统边界，涉众将属于系统的方面与系统上下文、无关环境，即不属于系统本身的方面，分隔开来。属于系统的物质和非物质对象（即系统边界内的制品）在系统开发过程中可以被改变。系统边界以外的制品（即属于系统上下文或无关环境的制品）在系统开发过程中不可以被改变，因此可以认为是稳定的。

❑上下文边界：上下文边界将系统上下文和被认为与系统开发无关的环境分隔开来。上下文边界将环境中无关的部分从相关的部分中区分开，从而减少了在需求工程中需要考虑的环境方面。

需求总是相对于一个给定的系统上下文而存在。因此，对于系统上下文的清晰定义（即系统和上下文边界的清晰定义）是正确定义系统需求的前提。

定义5-2：上下文方面
上下文方面是系统上下文中的各种物质和非物质对象，如人、技术与非技术性系统、过程、物理规律等。

5.2 系统边界

系统边界将待开发系统与其环境分隔开。系统边界内的所有元素在系统开发中都可以认为是可改变的。

定义5-3：系统边界
系统边界将待开发系统和系统上下文分隔开来。系统边界将属于系统之内、在开发过程中可以被改变的那些部分和那些在开发过程中不可改变、属于系统上下文的部分分隔开。

为了识别系统和系统上下文边界，可以考虑系统的信息源（source）和接收单元（sink）。信息源为系统提供输入，而接收单元接收系统的输出。

单元包括：

❑人；

❑其他技术或非技术系统；

❑传感器和执行器。

系统与环境的所有交互都发生在系统接口上。

在需求工程过程中，系统边界及接口是不稳定的。只有当需求被充分理解和文档化的时候（即需求工程过程的终点），系统边界和系统接口才趋于稳定。

由于（在初始阶段）对系统及其边界的划分可能存在一定的模糊性（即模糊的边界定义），因此系统及其上下文之间经常存在一个所谓的灰色区域。这一灰色区域在一定时间内代表了潜在的系统边界的可能范围。

提示5-1：注意系统边界
❑明确哪些方面属于系统;
❑确定哪些方面属于系统边界之外;
❑定义系统边界时应让所有相关的涉众参与其中；
❑设法就系统边界达成一致。当你无法确定某一对象是否属于系统时，把其放到灰色区域中;
❑经常检查已定义的系统边界是否仍然有效。注意系统边界所需的扩大或缩小;
❑如果系统边界需要进行调整，验证所做的调整是否影响已定义的需求。

5.2 系统边界

定义5-4：上下文边界
上下文边界将系统环境划分为相关部分与无关部分。换言之，它将系统上下文和那些在系统开发中无须考虑的无关环境区分开。

需求工程过程中，对于上下文边界的理解和定义一般都会逐步改善。

系统上下文和无关环境之间也存在灰色区域。这一灰色区域包含那些已被识别但尚未明确归属系统上下文或无关环境的方面。因此，灰色区域包括那些对于系统需求定义的影响尚不明确的那些上下文方面。

5.4 描述上下文方面的必要性

需求只能在给定的上下文之中进行定义和解释。上下文的变化可能导致需求含义的巨大变化。

通过上下文方面限制对需求的解释

上下文方面直接或间接地限制了对于需求的解释。

插述上下文信息的必要性

充分插述上下文方面对置求的正确解释是至关重要的。需求文档除了包含所描述的需求之外，通常还包含上下文信息。

上下文信息和需求经常交织在一起，这常常导致难以明确区分上下文信息和需求。

建议定义项目特定的上下文信息描述指南。该指南的目标是在需求工程和系统开发过程中支持上下文信息的沟通、交流和考虑。

指南应当定义：

❑针对待开发系统应考虑和描述的上下文方面的类型；

❑上下文信息描述的表示格式和结构；

❑用以关联上下文信息和需求的关系类型；

❑上下文信息描述的职责。

第6章 系统上下文的结构化组织

一个上下文结构有助于我们在每个需求工程活动中关注于特定的上下文方面，因此能够支持核心活动文档化、抽取、协商，以及横切活动确认和管理。

6.1 结构化原则

❑将上下文分为4个上下文刻面:首先,将上下文分为不同刻面可以在需求工程中为涉众提供支持。其次，将上下文结构化为多个不同的刻面可以保证涉众在需求工程中不会忽略某些重要的刻面。

❑上下文方面的分类:在每个上下文刻面中,我们区分不同类型的上下文方面。首先，在每个需求工程活动中,每种类型的上下文刻面都可以单独进行系统化的处理。其次，这种区分可以为每个刻面定义标准化的模式以用于对于每个刻面的标准化解释。最后，可以在上下文方面之间，以及不同的上下文方面和需求之间，定义不同类型的关系。

6.2 4个上下文刻面和3类上下文方面

用4个上下文刻面来组织系统上下文：

❑主体刻面：主体刻面包括了与系统相关的上下文中的实体和事件。主体刻面中的实体和事件必须在系统中进行表示。主体刻面还包含那些影响或约束系统中的信息表达的方面。

❑使用刻面：使用刻面包含与人和其他系统使用本系统相关的所有方面。

❑IT系统刻面：包括与系统部署后的运行或技术环境相关的所有方面。

❑开发刻面：包括影响系统开发的所有方面，或者是由法律和客户等所施加的与系统开发过程相关的所有上下文方面。

还区分如下 3类上下文方面:

❑需求来源：需求来源是定义系统需求的根源。

❑上下文对象：是一个上下文刻面中需要在需求工程里涉及或进行考虑的人以及物质和非物质对象。

❑上下文对象的属性和关系：表达关于上下文对象的一些附加信息。

3个上下文方面和4个上下文刻面

6.2.1需求来源

区分3类需求来源：涉众、(现有)文档、(现有)系统。

涉众

定义6-1:涉众(需求工程中的)
 涉众是在待开发系统中存在潜在利益的人或组织。涉众对于系统通常有着他们自己的需求。 一个人可以代表不同涉众(人和/或组织)的利益，即一个涉众可以有多个角色并代表多个涉众。

涉众通常具有关于一个或多个上下文刻面 中一个或多个上下文方面的知识。

现有文档

现有文档包含定义系统需求所需的大量信息。包括通用文件(如法律、标准)、特定组织文件(如开发指南、组织内的通用指南)或描述同类开发制品或原有系统的文档(如用户手册、系统体系结构文档、需求规格说明、测试文档等)。

现有系统

与需求工程相关的现有系统分为3类：

❑遗留系统和原有系统：

❑竞争对手的系统

❑类似系统

可以基于使用现有系统的经验为待开发系统定义需求。

❑复制现有系统的特性；

❑改进现有系统的特性；

❑避免现有系统已知的缺陷；

❑避免原有系统中已经被修正了的错误。

6.2.2上下文对象

上下文对象是存在于系统上下文之中、定义系统需求时需要考虑的人、物质或非物质对象。 可以是：

❑人；

❑法律主体；

❑物质对象；

❑非物质对象。

每个需求来源都属于系统上下文。然而，需求来源可以不是上下文对象。

人也可以同时属于需求来源和上下文对象。

6.2.3上下文对象的属性和关系

还需要抽取上下文对象的属性以及相互间的关系。

提示6-2:应用所提出的上下文结构
❑总是创建并维护一张包含重要的上下文对象及其属性和相互间关系的词汇表。或者为4 个上下文刻面中的每一个单独定义这样的词汇表。
❑使用适当的文档格式来描述上下文知识或关于4个上下文刻面的知识。
❑进行需求工程活动时，使用检查表来辅助考虑所有相关的上下文方面。

6.3 4个上下文刻面中的相关上下文方面

在各个上下文刻面中，需要考虑的需求来源、上下文对象，以及它们的属性和关系很大程度上取决于系统愿景。

即使是与两个不同系统相关的同一个上下文对象，其需要考虑的属性和关系也会由于系统愿景的差异而完全不同。

6.3.1 主体刻面

主体刻面中的需求来源

在主体刻面中，领域专家是一个重要的需求来源。他们提供关于系统所属领域以及需要在系统中表示的上下文对象的信息。

主体刻面中的相关文档包括主体领域的参考模型，通常称为领域模型。参考模型或领域模型中定义了可能与待开发系统相关的上下文对象以及它们的属性和关系，这些信息因此也可以被复用。

相关信息也可以从现有系统中抽取。

主体刻面中的上下文对象

主体刻面中相关的上下文对象很大程度上取决于系统愿景以及所需的系统功能。

包括以下几类：

❑相关数据需要被储存的人(如客户、供应商);

❑物质对象(如生产商品、消费商品);

❑非物质对象(如温度、速度、数学公式);

❑过程(如软件密集型系统所支持或提供自动化的生产过程或业务过程)。

主体刻面中的属性和关系

主体刻面中需要考虑的属性是那些已识别的上下文对象的一些相关属性。

映射函数定义了例如系统中上下文对象属性表示的精度和现实性等。

表示的精确性定义了使用系统中的对象属性表示现实世界对象属性时的精确程度。精确性包括数据的精度和对现实世界对象的抽象。

6.3.2 使用刻面

使用刻面中的需求来源

使用刻面中的涉众是待开发系统的直接或间接用户。直接用户对系统的用户接口有各自的需求。

间接用户一般是具有以下特性的人或系统：

❑自身并不使用该系统却与系统的使用间接相关的人或系统；

❑影响系统使用的人或系统；

❑从系统使用中间接获利的人或系统。

另一个重要的需求来源是用户接口设计专家

为了支持创新性需求的开发，相关应用领域的专家也可能会参与进来。

存在于使用领域中的领域模型，如业务过程模型，也是一种重要的需求来源。

以相同或相似方式使用的现有系统也应当被视为待开发系统的需求来源。

使用刻面中的上下文对象

在使用刻面中，用户组是典型的上下文对象。了解不同用户组的期望和要求是定义系统使用需求的关键。

使用刻面中的另一个重要上下文对象是用户接口的输入方式。

系统的各种使用流程构成了使用刻面的一个核心方面。

为其他技术系统和软件密集型系统创造的新价值也是一种重要的相关上下文对象。从这些上下文对象中可以得到与其他系统交互以及相应的交互接口相关的需求。

使用刻面中的属性和关系

为了正确定义支持各种使用流程的需求，需求工程师需要理解不同使用流程间的相互关系。

用户组和使用流程之间的关系构成了使用刻面的相关上下文信息，通过这些信息通常可以获得系统的相关需求。

使用刻面中的上下文对象及属性通常和主体刻面中的上下文对象及属性相关。这些关系的产生是由于系统处理与主体刻面中上下文对象相关的数据并将处理后的结果以某种格式呈现给系统用户。系统用户必须能够正确解读系统产生的结果，并将其与使用刻面中相应的上下文对象联系起来。

6.3.3  IT系统刻面

IT系统刻面中需求来源

IT系统刻面中的相关涉众是进行IT系统环境规划、设计及运行的所有人员。

如果系统和其他现有系统交互，那么定义这些系统接口以及系统规格说明的文档也是相关的需求来源。

分析IT系统刻面中现有的系统也能获得相关的上下文信息。

IT系统刻面中的上下文对象

IT系统刻面中相关的上下文对象包括：

❑系统开发过程中需要考虑的软硬件组件

❑待开发系统的运行和维护；

❑相关企业的IT策略。

IT系统刻面中的属性和关系

IT系统刻面中上下文对象的相关属性是指相关软硬件组件的技术性能。

6.3.4 开发刻面

开发过程在开发刻面中进行，显然会影响系统的开发方式。

开发刻面中的需求来源

开发刻面中的需求来源为系统开发提供信息。

在开发刻面中，提供包括维护和系统替换在内的整个开发过程阶段重要信息

涉众可以被分为以下几类：

❑过程工程师；

❑过程经理；

❑过程执行者(如需求工程师、架构师)。

一些重要的文档包括：

❑开发标准；

❑开发指南；

❑方法描述；

❑最佳实践文档；

❑此前项目的项目计划。

开发刻面中的上下文对象、属性和关系

开发刻面中相关的上下文对象及其属性和关系涉及开发过程的所有部分。包括：

❑角色定义；

❑制品定义；

❑活动定义；

❑工具；

❑资源可用性和资源约束。

工具环境是开发过程中另一种重要的上下文对象。

特定组织的开发工程以及相互之间的协调是开发刻面中重要的上下文对象，必须进行考虑和充分理解。

6.4 上下文方面的不同角色

一个特定的上下文方面可能与多个上下文刻面相关。

如果一个上下文方面与多个刻面相关，那么区分4个上下文刻面就尤为重要。

将系统上下文组织为4个刻面使得涉众能够对各个需求来源包含或提供的信息进行分类和描 述。

一个需求来源可以分别从4个刻面进行分析。