通过RUP用例进行需求管理的可追踪性策略

1. 摘要

在许多用例建模技术的商业应用软件中，用例模型必须与更传统的需求获取技术结合起来，从而提供一个让项目涉及的所有涉众均可接受的需求管理流程。本文探讨了组织在采用用例建模技术作为部分需求管理策略时可以使用的可追踪性策略。

2. 简介/背景

2.1 可追踪性项

在 讨论需求管理时，特别在使用 RequisitePro 此类工具的时候，“需求”这个词丰富的含义常常使人感到困惑。除了通常定义为“需求”的项以外，我们还需捕获和追踪其他许多类型的项的属性以及这些项之间 的可追踪性。这些其他的可追踪性项包括问题、假设、请求、词汇表术语、主角以及测试等等。

 捕获并追踪这些其他类型的可追踪性项能够帮助我们有效地管理项目需求。

 定义：可追踪性项

 需要明确地从另一个文本或模型项进行追踪的任何文本或模型项，目的是为了跟踪两者之间的依赖关系。

 在 RequisitePro 中，这个定义又可另述为： 

在 RequisitePro 中用一个 RequisitePro 需求类型的实例表示的任何文本或模型项。 

RequisitePro 本身提供了一个优秀工具，用于定义、捕获并跟踪值、属性以及软件开发所涉及的多种可追踪性项之间的可追踪性链接。

2.2 隐含和明确的可追踪性

任何开发流程都隐含有一定量的可追踪性。这些可追踪性通常由流程中工件之间的正式关系提供。  

这类隐含的可追踪性的示例包括：

• 命名约定
例如，设计模型中名为 Fred 的类由实施模型中的 Fred 类来实现。

• 构建模型间的映射
例如，Rose 中的构件视图允许 Rose 中逻辑视图内的包和类显式映射到实施模型中的包。这种映射可以包含对具有不同打包策略的模型与应用程序之间的重命名。

• 模型项本身之间的关系
例如，在 Rational Unified Process 中，设计模型中的用例实现可追溯至实现它们的用例。

• 确立不同的角度来阐明一个模型中的元素如何满足另一个模型的元素所隐含的需求
例如，设计模型中的用例实现说明了设计模型的模型元素如何通过合作实现用例的方式。这就提供了一个从用例角度说明设计模型的方法，它可以验证和补充设计模 型中类和包的静态封装方法所有这些示例都具有一定级别的可追踪性，允许利用开发模型保留的信息执行影响分析。  

如下图所示，受用例驱动的开发包括一系列相互关联关系的模型。 　

该图显示了模型以及它们之间的隐含关系。模型之间的关系具有一定级别的可追踪性，它是开发流程隐含的。  

在进行用例驱动的开发时，需要一些支持工件来支持用例模型，并定义完整的软件需求规约。在 Rational Unified Process 中，这些工件是补充规约和词汇表。其他有关的工件还有商业理由以及前景文档，它们包含了项目的需要、目标和特性的定义。  

模型间的关系不涉及这些支持工件，因此就不包含在开发流程内建的隐含的可追踪性之中。  

隐含关系是开发流程的基础，并且它可以从构建作为开发人员工作的一个有机组成部分中受益。这些关系是建模流程的核心，它们需要在模型趋向成熟的过程中进行构建和维护。  

隐含的可追踪性仅限于在建模表示法中可用的关系。

那么为何还需要明确的可追踪性呢？  

如果我们打算采用需求可追踪性的原则，就需要将需求、模型项及其他可追踪性项集成到一个可追踪性分层结构中。我们最好还要向开发流程添加更多的可追踪性关系。  

下图是一个可追踪性分层结构示例，该分层结构显示了前景文档定义的“特性”与用例模型和补充规约定义的“软件需求”之间的关系。它还显示了软件需求如何追溯至测试需求、设计和用户文档。 　

　

如果我们仔细查看补充需求（在补充规约文档中定义）与设计、实施和模型之间的关系，就可以发现该关系并未包含在模型间隐含的可追踪性之内。 这 是另一级别明确的可追踪性的典型示例，它通常是项目必需的。许多需求由于与用例模型之间存在隐含关系，需要在整个模型系列中进行追踪。补充需求在补充规约 里是沿着用例模型获取的，它们不直接与考虑它们的设计模型中的任何包相关，与实现它们的实施模型中的构件也无直接关系。  

其他示例包括以下各项之间的关系：

- 系统特性与用例模型之间的关系

- 用例模型与用户文档之间的关系

- 用例模型与测试需求之间的关系  

在建立需求可追踪性流程时，需要作出的重大决定之一就是确定所需的可追踪性级别，以及达到该目标需要多大的明确可追踪性。我们希望我们的需求、可追踪性和管理的方案有利于开发流程的执行，而不是使之复杂化或对其施加限制。  

可 以看到，增加开发工件明确的可追踪性会显著提高项目成本。当考虑到采集和维护这些额外消息的长期成本时，这种影响尤其显著。我们要做的就是为项目确立一个 合适的可追踪性级别，使得我们在额外的明确可追踪性上的投资能得到回报。我们的开发人员应该把时间放在开发上，而不是进行追踪。为了达到这个目标，在给项 目增加明确的可追踪性成本之前，需要建立可追踪性策略，并对策略进行评估。  

可追踪性策略定义我们希望添加到软件开发流程的明确可追踪性级别。2.3 管理支持工件

上面的图 1 显示了在 RUP 中需求规约所涉及的工件。  

这里要注意，用例模型和补充规约形成了完整的软件需求规约 (SRS) 。这就是说，我们并不需要传统需求管理技术所必需的正式软件需求规约文档。

　

下面的图 2 显示了传统 SRS 文档通常如何与 RUP 工件相关。传统的 SRS 仅仅是记录软件需求的一种备用方法。这两种方案都可以为我们提供定义待建系统的完整外部行为的软件需求规约，意识到这一点非常重要。

这种关系经常被曲解为这两种需求管理模型不能共存。人们经常以为，在使用正式软件需求规约文档的传统需求管理技术，以及基于使用用例模型及补充规约的需求管理技术的用例模型之间，必须选择其一。实际上，在某些情况下，同一项目中存在两种形式的软件需求管理规约是必然。

2.4 可能的可追踪性策略

2.4.1 可接受的可追踪性策略是否不止一个？  

有许多可追踪性策略可用于改进需求管理流程，即使在 Rational Unified Process 的框架内，也可能存在多种方案。读者在应用中最常见的策略有四种，分别是：

1. 唯用例模型  

在这种情况下，用例模型是系统需求的唯一声明。选择这种方案的项目特点在于，客户和开发员之间有紧密的联系和高度的信任。  

用例模型和词汇表以及补充规约形成了系统需求的完整声明 - 不存在其他需要、产品特性或软件需求定义。

2. 特性驱动用例模型  

这是 Rational Unified Process 推荐的默认策略。用例模型和补充规约形成了完整的软件需求规约。特性记录在前景文档中，并追踪到用例。如果它们未在用例模型中反映出来，则将它们追踪至补充规约的补充需求。  

在这种情况下，用例模型作为功能需求的主要声明。除词汇表和补充需求外，用例模型和补充需求还用需要和产品特性加以完善。  

3. 用例模型是对软件需求规约的一种解释  

在这种情况下，用例模型是对正式传统的软件需求规约的一种解释。由于规章、协议或内部原因而被迫采用正式传统的软件需求规约，以及在必须使用用例模型来启用受用例驱动的开发时，经常用到这种方案。

追踪至正式软件需求规约文档而不是软件需求的(与传统需求管理一样)特性，随后显式追踪至用例模型中。  

4. 用例模型调和多个传统软件需求集  

用例模型是对来自多个源的软件需求规约集的解释，它提供了单个通用系统的规约。  

在 这种情况下，每个涉众都有自己的软件特性和软件需求集，这在他们各自的前景和软件需求规约文档内有详细的说明。这些多样化的观点，以及可能存在的相互矛盾 的期望，都需要在单个用例模型中进行调和（该用例模型指定了系统将要执行的操作内容）。这一策略在处理独立涉众的大集合时非常有效。  

在不包括选项 1 在内的所有情况下，我们把用例模型与传统需求可追踪性流程的元素结合起来。  

当然还存在许多其他选项，它们也许根本没有用例模型。我们把这些选项称为“无用例模型”。  

这些方案及其他方案，在下面的可追踪性策略分类中有更详细的论述。

2.5 软件为何要采用混合方案 需求集为何要采用混合方案 ?

可 以看到，以上的两种极端方案（唯用例模型和无用例模型）采用的观点极其纯粹，都只允许存在一种形式的需求捕获。两者都假设有一种万能方案可适用于所有的项 目和涉众群体。两者方案本都看到了成功的希望，但由于它们在处理复杂情形以及“真实世界”项目中产生的涉众关系集时表现呆板和无能，最终落得个声名狼藉。

 

Rational Unified Process 推荐如下的可追踪性分层结构：

 

　

这是上面的“特性驱动用例模型”选项，而且也可能是最有效的可追踪性策略。但应该注意，即使 Rational Unified Process 采用了这种方案，它也并不总是最有效的。

 

将用例建模作为功能软件需求规约的唯一机制，这种做法证明是有问题的，有例为证：

• 存在许多矛盾的需求源（即许多矛盾的期望需要进行跟踪和管理）。

• 承担项目的组织坚持与现有的传统需求捕获流程保持兼容。

• 让涉众参加建模专题研讨会，制定一个大家一致同意的需求模型时存在困难。

• 采用用例建模技术在现有需求捕获流程的约束下驱动面向对象的软件开发。

• 涉众群体不能或者不愿意直接在用例模型内表达所有的功能软件需求级别期望。

• 客户确定了产品将以传统软件需求集的形式交付。在进行开发投标的时候，这种情况很常见 － 传统的需求声明成为交付合同的一部分。

 

我们认为，应该采用哪个方案必须根据每个项目和开发组织的具体情况来决定这个问题不存在万能的解决方案，那种企图强行将所有项目都用一个需求管理方案来解决的做法是愚蠢的。

应该记住，Rational Unified Process 是一个可配置的流程，能够处理本文介绍的、不包括“无用例模型”方案在内的所有可追踪性策略（Rational Unified Process 的用例驱动本质排除了采用该选项的可能）。在编写 Rational Unified Process 开发案例的过程中，其中决策之一是决定采用哪种方案。

3. 关于可追踪性策略分类

为了定义可追踪性策略，我们需要一种分类和定义策略项的机制。

 

定义：可追踪性类型

 

具有共同特征和属性的一类可追踪性项（例如需要、产品特性、用例、软件需求、测试需求、主角、词汇表术语等）。

 

注意：在 RequisitePro 中，可追踪性类型用需求类型表示。

 

建立可追踪性策略涉及了三个紧密关联关系的活动：

1. 确定定义可追踪性项所需要的可追踪性类型集。

2. 确定这些可追踪性类型之间的有效可追踪性关系。

3. 确定可追踪性项必需的属性，以便实施有效的项目需求管理。

 

可追踪性策略分类通过记录已知可追踪性项集以及它们的可追踪性关系，方便了前两个步骤的执行。（它不包括第三个活动，因为可追踪性类型有关属性的定义目前超出了本文的讨论范围。）

 

在分类中描述的可追踪性策略都使用了同一个基本的可追踪性类型集的子集。

 

1 需要

2 产品特性

3 软件需求（功能性和非功能性）

4 词汇表术语

5 用例

6 用例段

7 主角

 

注意：在用例建模的时候，通常唯一的软件需求是补充规约定义的补充需求。

 

若能在所有传统可追踪性类型与用例模型的构成部分之间进行追踪，项目就有许多可以选择的可追踪性策略。

在可追踪性项之间有两个级别的可追踪性：

 

1. 基本可追踪性

无论选择哪种可追踪性策略，都要应用一些基本的可追踪性。这些可追踪性隐含在可追踪性类型的本质当中。其中包括如用例与用例段之间或用例与主角之间的关系。

 

在阅读以下可追踪性策略段中的概述图时，这些基本的可追踪性不在每个策略中重复说明，但在默认情况下包含在可应用的可追踪性策略中。

 

2. 扩展可追踪性

这是为支持特定的可追踪性策略而引进的可追踪性。这些可追踪性更具主观性，而且对不同的可追踪性策略也是不同的。

4. 可追踪性策略分类

4.1 图解符号

可追踪性类型及其可追踪性关系显示为统一建模语言 (UML) 图表。下图说明了如何解析在此环境中 UML 的使用。

 

为了充分理解该图，在实施 RequisitePro 中的定义时了解所用的实施映射是有用的。下表解释了图解符号如何映射到 RequisitePro 项目上。

 

图解符号	RequisitePro 映射
类/可追踪性类型	需求类型
关系	RequisitePro “追踪到”关系
聚合关系	分层需求
泛化关系	通过添加一个附加的“子分类”属性，对需求超类型进行的分类

 

注意：RequisitePro 允许将任何可追踪性项都追踪到任意其他项。可追踪性策略定义的是有意义的可追踪性链接，这些链接将成为项目需求管理策略的核心。

 

4.2 支持的可追踪性类型

4.2.1 说明

在本节中，我们定义了一个支持性可追踪性类型集，它可用于支持所选的任意可追踪性策略。

4.2.1 概述

 

注意： 这些支持的可追踪性类型可追踪至所选可追踪性策略包含的任何其他可追踪性类型。

4.2.3 可追踪性类型

可追踪性类型	说明
词汇表术语	这一可追踪性类型定义代表词汇表术语及其定义的可追踪性项。 它包含在支持的可追踪性类型集中，因为不管选择采用哪个可追踪性策略，词汇表都是必需的。
问题	这一可追踪性类型允许添加代表在 RequisitePro 内需跟踪的问题的可追踪性项。随后这些问题与受其影响的可追踪性项联系起来。 追踪与词汇表术语有关的问题就是使用问题可追踪性类型的一个示例。如果定义未确定，或者定义有争议，问题就会出现，并包含在 RequisitePro 中。这就确保了问题不会被遗忘，并允许建立一个视图，报告所有与未解决的问题有关的词汇表项。另一个使用这个可追踪性类型的典型示例就是，在复审用例和其他开发工件时跟踪出现的问题。
假设	这一可追踪性类型允许跟踪所作的假设。随后这些假设可与受其影响的任意可追踪性项联系起来。
支持文档	这一可追踪性类型允许向可追踪性分层结构添加任何需要的文档。这在将那些预先存在的、用于澄清另一个可追踪性项的意义或目的的示例或文档包含在该类型时特别有用。RequisitePro 灵活的可追踪性机制允许将支持文档与任何类型的任何可追踪性项关联关系起来。 使用支持文档类型的一个示例就是，将详细的 EDI 消息规约作为词汇表的支持信息，或者作为使用消息的用例附录包含进来。

4.2.4 基本可追踪性

可追踪性链接	说明
词汇表术语到词汇表术语	此关系允许我们使用单个可追踪性类型同时捕获词汇表术语及其定义。
支持性可追踪性类型到其他任何可追踪性类型	这些支持的可追踪性类型可追踪至所选可追踪性策略包含的任何其他可追踪性类型。

4.3 无用例模型

4.3.1 说明

在这种情况下不存在用例模型。需要产生了产品特性，而产品特性依次产生了记录在正式软件需求规约里的软件需求。

 

“我不能没有讨厌的用例模型！”项目经理们的话一语中的。

4.3.2 特征

特征	值	注释
明确的可追踪性	高	实施需求管理技术但不使用用例的项目往往在可追踪性类型之间维持着高级的显式可追踪性。
信任	低
可说明性	高
正式性	高
完整性	低	很难评估传统软件需求集的完整性。
文档集	大	衡量文档集通常用英尺而不是英寸。
重点	合同	需求捕获流程的重点在于，在客户和开发员之间建立一个在法律上可强制实施的合同，而不是对有待解决的问题和所提出的解决方案取得一致理解。
可理解性	低	用户群体和开发人员通常无法访问需求文档。需求文档由许多单独的线项组成，线项按类型或者功能范围进行分组，给复审人员的环境提示很少。
流程	典型瀑布式	传统需求获取技术常常作为瀑布式开发流程的一部分实施。由于缺乏环境以及评估需求的任何子集的完整性存在困难，这都不利于采用迭代式和递增式的开发流程。
开发风格	功能分解	在将需求转变为解决方案时，需求按类型或功能范围分组常常导致连续的功能分解。

 

4.3.3

可追踪性概述

 

4.3.4 可追踪性类型

需求类型	说明
需要	为了证明购买或使用的合理性而必须解决的业务或运作问题（机会）。也称之为目标或目的。
产品特性	直接满足某一需要的系统功能或特征。通常理解为系统的“公开优点”。
软件需求	正在构建的软件必须符合的条件或具备的功能。

4.3.5 可追踪性摘要

可追踪性链接	说明
需要追踪至产品特性	每一种需要由一个特性集实现。这种关系允许追踪每个特性的业务利益。
产品特性追踪至软件需求。	每个特性由一个软件需求集实现。 这种关系允许追踪每个软件需求的业务利益，并在产品特性级别进行软件需求规模管理。

4.3.6 优点和缺点

正面：

- 容易理解

- 对法定合同有好处（请看许多与已交付软件满足/无法满足指定需求有关的法庭案例）。

- 是许多标准流程所推荐的。

- 允许有详细的、低级别的正式可追踪性。

- 不会由于引进“惊世骇俗”的新思想而扰乱了现状。

反面：

- 难以完成需求捕获 - 非常容易停滞在需求阶段。

- 难以理解以这种形式表达的需求。

- 难以评估需求变更所带来的影响。

- 单个需求没有相关环境。

- 维护成本高。由于缺乏隐含的可追踪性，项目必须承担维护大量显式可追踪性关系的高成本。

- 由于缺乏相关环境，确定有意义的需求子集难免存在困难。这又使得规模管理以及产品的递增式交付更加难以进行。

4.3.7 示例

需求可追踪性的无用例模型方案广泛应用在许多业务领域的诸多项目中。很多组织都要求有一个正式的传统软件需求规约作为正式合同谈判的基础。这就导致他们认为传统的需求管理方案是适用于项目的唯一方案。

4.4 唯用例模型

4.4.1 说明

“用例模型是我的需求。”客户和开发人员之间的紧密联系和高度信任通常是采用这种方案的项目的特点。该方案一般用于内部可说明性低的项目。在这些项目中，开发人员希望通过与客户一起开发用例模型（或经用户批准进行开发），展示或取得对需求的清晰理解。

 

在这种情况下，用例模型是系统需求的唯一声明。用例模型、词汇表和补充规约形成了系统需求的完整声明。

4.4.2 特征

特征	值	注释
明确的可追踪性	低	不要求有明确的可追踪性。用例驱动方案所提供的隐含可追踪性就足够了。可能不维护显式可追踪性，因此不使用需求管理工具。
信任	高	缺乏任何需要或特性级别的分析意味着涉众给予用例模型的开发者高度信任，相信他们能交付正确的系统。
可说明性	低
正式性	低
完整性	低	尽管用例模型本身有利于建立软件需求规约的完整性，但缺乏到涉众需要的可追踪性通常导致生产出来的系统不完整或者过于精细。
文档集	小	该方案包含最小的文档集。
重点	用户	用例模型表达用户观点。
可理解性	高	用例模型容易为项目中的所有涉众所理解。
流程	典型的迭代式和递增式	用例把软件需求放在有利于迭代式和递增式开发的环境中（用例提供一个优秀的交付单元）。用例还可以与瀑布式开发流程一起使用。
开发风格	典型的面向对象	尽管用例可以使用任何开发风格，但通常用于驱动面向对象的软件开发。如果不采用面向对象的模式，则要求具有高级别的显式可追踪性。

 

4.4.3 可追踪性概述

 

　

4.4.4 可追踪性类型

可追踪性类型	说明
用例	此可追踪性类型定义代表用例的可追踪性项。
用例段	利用此用例段能够将用例段包含在可追踪性分层结构里。 它还允许我们追踪到单个流以及构成用例的其他属性。 子段分层关系的出现允许我们获取各个段的独立部分。例如，它可以让我们确定组成前置条件段的前置条件。   注意：在某些情况下，确定用例事件流内的单独软件需求是可以的（这种情况下段非常小），但除非用例本身已经稳定，否则不要进行这样的尝试。
主角	此可追踪性类型定义代表主角的可追踪性项。

 

4.4.5 可追踪性摘要

可追踪性链接	说明
用例至用例段	每个用例由一个用例段集组成。这种关系允许我们追踪哪些用例段组成了哪一个用例。
用例段至用例段	一些更为复杂的用例段包含许多子段。例如，事件流可能包括许多子流，而前置条件段则由许多前置条件组成。
用例至主角	这种关系允许我们查看哪一个用例包含哪些主角。
主角至主角	这种关系允许我们使用单个可追踪性类型同时捕获主角及其简要说明。

4.4.6 优点和缺点

正面：

- 文档集最小

- 需求管理所涉及的工作量最小

- 很好地支持规模管理、影响分析和递增式开发。

- 用例易于理解。

反面：

- 没有追溯回涉众需要的关系。在开始制定解决方案之前没有实际尝试分析问题。

- 许多人认为仅仅基于一个用例模型还难以接受合同。

- 如果不进行任何需要分析，就很难知道用例模型本身何时描述了一个合适的解决方案。在编写用例的时候，想象力容易失控。

- 如果执行定期发布，在没有任何比用例本身级别高的信息的情况下，难以管理产品和持续管理涉众期望。

4.4.7 示例

这种方案通常用于小规模的非正式内部项目。在这些项目中，开发人员和用户的合作密切。

4.5 用例模型定义产品特性。

4.5.1 说明

在这种情况下，用例建模作为主要的需求获取方法使用，并且用例模型成为系统提供的产品特性定义以及软件需求声明。

 

该方法由于不具有规模调整功能，因此只适用于生命周期短的小型开发项目。即使每个用例代表一个系统特性，但特性仍会多于用例，而且在实际情况中，特性会对很多用例有影响。随着系统的演进，每个发布版的新特性越来越少，而且以新用例形式出现的可能性更小。

4.5.2 特征

这是前面的“唯用例模型”方案的一个变种。我们在讨论这种方案时只注意了它们之间的少数区别。

 

特征	值	注释
明确的可追踪性	低	与唯用例模型相同。只存在一小组的需要，而这些少量的额外可追踪性仍然产生了对少量明确的可追踪性的需求。
信任	中/高	向用例模型添加需要导致策略的信任程度比唯用例模型的稍低。
可说明性	低
正式性	低
完整性	中	用例模型本身有利于建立软件需求规约的完整性，而追溯涉众需要的额外可追踪性则有助于验证用例模型的适用性。
文档集	小	这种方案包含一个非常小的文档集。包括用例模型，加上包含需要的前景文档。
重点	用户	用例模型和需要都持用户观点。
可理解性	高	需要和用例模型都容易为项目中的所有涉众所理解。
流程	典型的迭代式和递增式	与唯用例模型相同
开发风格	典型的面向对象	与唯用例模型相同