引言
本文描述了 IBM Rational® RequisitePro® 2003 和 IBM Rational® XDE™ Developer v2003 之间的集成如何帮助软件团队保持设计活动与需求的一致性。目的在于能够交付实际满足客户需求的软件。

Rational RequisitePro 是 IBM Rational 市场领先的需求管理工具。借助于 Rational RequisitePro，您可以在 Microsoft Word 文档中管理需求，这些需求已链接到需求数据库中，利用该数据库可以高效组织和管理其他需求信息。

Rational XDE Developer 是一个完全可视的设计和开发环境，它在开发人员的集成开发环境（IDE）中加入了 UML（统一建模语言）建模，从而增进了交流，并提高了软件设计的文档化。本文描述的集成适用于以下 Rational XDE Developer 家族成员：

Rational XDE. Developer - Java. Platform Edition，可以通过内建的 Eclipse IDE 单独实现集成，或者将其安装到 IBM WebSphereTM Studio Application Developer 和 Integration Edition IDE 中。 Rational XDE. Developer - .NET Platform Edition，扩展了 Microsoft Visual StudioTM .NET IDE。 Rational XDE. Modeler Edition，它提供了 Rational XDE Developer 功能的子集，从而使架构人员和设计人员能够为架构、业务需要、可重用资产和管理级通讯创建通过平台实现的 UML 模型。

本文首先回顾了保持需求与设计一致的挑战，然后深入探讨了 Rational XDE Developer 和 Rational RequisitePro 之间的集成如何提供了针对这些挑战的解决方案。

本文第二部分详细描述了如何利用该项集成来创造效益。

背景：从需求出发进行设计的挑战
需求为软件开发人员定义了应该创建何种系统。通过需求来记录客户需要，这些需要是为了使客户能够创造价值，软件必须要解决的。同样，应该通过需求来驱动所需的全部软件活动，从而实现最终目标：交付能够为客户创造价值的软件。

实际上，在记录了需求之后，软件团队需要一直遵照这些需求，并且确保按照这些需求来进行设计和编写代码。

以往的需求工具和设计工具都是相对独立的，这两种工具之间存在一道屏障，将业务分析人员和开发人员分割开来。这样就产生了不良的软件开发后果，最终导致所开发的应用程序没有实现需求所指定的功能。这种普遍现象的根源在于需求与开发人员之间贫乏的交流，特别是需求变更与开发人员之间的交流不足。将需求规格说明书的初次调整传递给开发人员，这并不难实现，但是当需求频繁地发生变更时，如果不将不断变更的需求传递给开发人员，他们将还按原来的需求来开发系统，从而使所交付的应用程序无法满足不断变化的用户需要。特别是创建大型系统时，开发团队极易疏忽某些需求。在设计阶段评估需求的覆盖程度，对于确保应用程序能够满足客户在项目开始时所设定的期望值非常重要。

现在还没有一个很好的方法，来回答以下问题：

需求处于何种最新的状态？ 全部经商定的需求在设计中都考虑到了吗？ 设计模型的哪个部分受到了最新的需求变更的影响？ 如何才能知道设计是可行的？能否满足用户需要？

为回答第一个问题，我们将 IBM Rational RequisitePro 和 IBM Rational XDE Developer 进行了集成，通过将存储在 Rational XDE Developer 模型中的用例图，和存储在 Rational RequisitePro 中的相关用例需求信息（事件流、优先级、难度、风险等）链接起来，从而解决了向开发人员高效传递需求这项挑战。

为回答其他两个关键问题，我们将 Rational RequisitePro 和 Rational XDE Developer 进行了集成，通过在需求和实现该项需求的相关设计要素之间建立直接关系，从而解决了保持软件设计与需求一致这项挑战。

利用 IBM Rational 工具，从需求出发进行设计
为了说明 IBM Rational RequisitePro 和 IBM Rational XDE Developer 集成所带来的利益，本小节讲一下，将这两种工具的集成用于软件团队的日常工作中，这里软件团队遵从 IBM Rational Unified Process? 中规定的软件开发最佳实践。用斜体分别列出了 Rational RequisitePro 和 Rational XDE Developer，以及它们二者的集成为该软件活动所带来的特定价值。

确保软件能够为客户创造价值
项目开始时，用一个可视的文档（通常由分析人员来编写，但要在团队和客户之间传阅，并得到他们的批准）来说明客户问题和这些问题的建议解决方案。在可视文档中，用高级产品功能来说明所建议的解决方案。

用 Rational RequisitePro 来管理可视文档和高级产品功能，同时也管理从这些产品功能和其他涉众获取的详细需求。

在 Rational RequisitePro 中，通过保持需求之间的关系（称作"可跟踪性链接"），来提供覆盖报告（用来确保全部的高级需求都通过更详细的需求得到实现）和影响分析报告（用来度量需求变更对其他需求产生的影响）。

当可视文档达成一致意见后，为了能够让软件团队将精力集中于为客户创造价值上，使用一个用例图，以用户的视角，来描述应用程序能够带来的价值。通过用例图来描述某一系统与用户和其他系统发生交互时，将产生何种系统行为。在过去 10 年中，用例已经得到验证，它是一个高效的方法，从用户的视角来记录系统功能，该用户视角既为软件团队也为他们的客户提供了一个关于待建系统期望行为的公共理解。通过最大限度地降低误解风险，用例提高了软件团队必须交付成功系统的机会。

在 Rational XDE Developer 中创建用例图，同时创建参与者和用例简短描述。

图1 典型的用例图解


为用例划分优先级
当团队和客户对用例中图解中的值达成一致意见后，要对用例划分优先级，从而使开发团队可以首先集中精力于最重要的用例上。最重要的用例指的是，能够自动聚焦于业务过程的核心和自动驱动软件架构的那些用例。

为了使优先级划分过程具有客观性，要为每个用例设置属性。属性特别有益于迭代软件开发， 它提供了一个简单的方法来设置项目中每个迭代过程的管理范围。用例属性通常包括：实现难度、架构的有效性、风险和特定的客户价值。

利用 IBM Rational XDE Developer，使用 Rational XDE Developer 和 Rational RequisitePro 的集成，可以为用例分配需求属性。这些需求属性作为用例属性。

IBM Rational RequisitePro 提供了默认的用例需求属性。

可以使用 Rational RequisitePro 来创建用例报告，根据属性对用例进行排序和过滤。

对优先用例进行详细分析
为了实现具有高优先级的用例，开发人员要创建顺序图，来开始构建软件架构，并确定设计类别。为了创建顺序图，开发人员需要访问用例图中用例椭圆之外的更多详细信息。因此，每个具有高优先级的用例被细化为一个步骤集，该步骤集描述了一个对话，对话的双方分别为初始化用例的参与者（图 1 中的客户），和用于实现用例（例如，图 1 中的 Sort Catalog）中描述功能的系统，该步骤集通常称作用例的事件流。通常用例有一个单个的事件流（描述用户与系统之间所期望的交互）和几个可选（有时称作异常）事件流（记录系统处理应该如何处理异常事件，如打印机缺纸）。注意在这一点上，无需详述每个单个用例；只需详述被选为高优先级的那些用例即可。

因为用例中的事件流通常是用 Microsoft? Word 来记录的，并且 IBM Rational RequisitePro 允许用户在 Microsoft Word 中编辑需求，因此 Rational RequisitePro 是用来管理用例的一个理想的工具。在使用 Rational XDE Developer 时，为用例附加一个简单的 Word 文档，与之相比，使用 Rational RequisitePro 来详细描述用例，是一项关键性的优势。

可以清楚地识别用例事件流文本中所包含的功能性需求。
因为使用 Rational RequisitePro，需求文本在显示方式上，不同于文档中其他描述性信息（见图 9），因此很容易识别用例事件流中所表述的功能性需求。您可以选择在用例流级别上标记功能性需求，或在单个的步骤流级别上标记功能性需求。当某一测试场景典型地用于测试基本步骤流与备用流结合时，在流级别上标记需求，有利于从用例出发，来创建测试用例。 自动跟踪对用例文档的修改。
每项需求变更的审计跟踪（谁做出的变更、内容、时间、原因）存储在 Rational RequisitePro 数据库中。这些修订帮助您实现对用例变更的控制。 跟踪功能性需求
用例事件流中包含的功能性需求标记为软件需求，并为它们分配了属性（优先级、难度、风险等），而且与高级业务需求或产品功能链接起来。 可以将用例文档中的需求与相关的其他需求链接起来
通过跟踪用例到业务需求，或跟踪到产品功能，更易于度量与需求相关的变更所带来的影响，并且验证覆盖度。

根据详细的用例，生成设计类别
根据用例规格说明书的事件流，设计人员可以构建顺序图，将事件流作为对象之间的一连串消息来表述。

在 IBM Rational XDE Developer 中创建顺序图，并且与 Rational XDE Developer 对用例图的标注链接起来。请注意：我们经常被问起工具是否可以将用例事件流自动转换成顺序图。最好的回答是，不良的设计可能来源该方法，而好的设计却进行优化，来表达所有的关键性事件流。

根据顺序图中确认的对象，可以进行设计分类。

在 Rational XDE Developer 中创建类图和其他 UML 图，并与它们的源顺序图链接起来.用来表示用例设计的 UML 图的集合通常被称作"用例实现"。该命名说明了这样一个事实，通过设计实现了用例中的需求。

使设计与需求变更保持一致
当设计活动开始时，需求促使原始用例（和随后的顺序图及类）变更的创建。不断变更的需求是（软件）生命周期中的事实，也是（软件）生命周期的信号，同时也是健全的项目的信号。在项目开始时，不可能 100% 了解软件需求和用户需要，因此变更反映了从您必须创建的（如果只是等待得到全部需求，那么您永远也不会有一个开始，最终将导致分析过程瘫痪）最初的需求集向最终的需求汇聚的过程。为了确保所交付的软件确实能够满足用户需要，需要使设计与不断变更的需求保持同步。

IBM Rational RequisitePro 可跟踪性矩阵将需求之间链接起来。

利用 Rational RequisitePro 和 Rational XDE Developer 的集成，还可以将设计要素与它们所实现的需求链接起来。The IBM Rational XDE Developer 设计要素反映在 Rational RequisitePro 可跟踪性矩阵中。

通过过滤需求和设计之间的可跟踪性矩阵，可以访问所需的特定信息。

利用 IBM Rational XDE Developer 和 Rational RequisitePro 的集成
本小节详细阐述了采用 Rational XDE Developer 和 Rational RequisitePro 进行集成的步骤。这里提供了Rational XDE Developer - Java? Platform Edition 的屏幕截图，但是正如介绍中所提到的，该集成同样适用于 Rational XDE Developer 和 .NET Edition and Rational XDE Modeler Edition 的集成。

在 Rational XDE Developer 中，可以从两个地方调用集成：Tools > Rational RequisitePro 菜单和对上下文敏感的右键菜单。当选定了一个 Rational XDE Developer 要素后，或者从图开始，或者从 Model Explorer 开始。上下文敏感菜单选项根据所选 Rational XDE Developer 要素的不同（软件包、用例或其他 UML 语言）而变化。

用例的菜单选项：

打开/新建用例文档，该选项用来创建一个新的用例文档或者将用例与现存的 IBM Rational RequisitePro 用例文档关联起来。 查看需求属性，该选项用来查看和编辑用例的属性和可跟踪性（依赖性）链接。

软件包的菜单选项：

关联/取消关联 RequisitePro，该选项用来指定一个 Rational RequisitePro 项目，该项目包中所有的要素都要参与集成。

设置集成
默认情况下，IBM Rational XDE Developer 模型未被激活以用于该集成，通过选用模型的 AppliedProfiles 属性中的"RequisitePro" profile，可以在 Rational XDE Developer 模型中激活该集成。

图2 在 Rational XDE Developer 中激活集成


选用了 "RequisitePro" profile 后，每次打开 IBM Rational XDE Developer 模型时，可以从 Rational XDE Developer 主菜单（图3）中使用需求管理功能，也可以从 Model Explorer 或用例图的上下文右键菜单来使用。

图3 Rational XDE Developer 主菜单的需求选项


在默认情况下，整个 Rational XDE Developer 模型与 IBM Rational RequisitePro 关联起来，但是您可以为单个的软件包覆盖这种模型级的关联（图4）。这样就允许用例（或设计要素）存储于不同的软件包中，从而可以使用不同的 Rational RequisitePro 项目来存储需求信息。该软件包级的关联将其自身提供给大型软件项目，这些项目可能使用多个 Rational RequisitePro 项目（通常每个子系统使用一个），或使用不同的用例文档模板（例如，系统级用例和低级别的用例）。

图4 使用 Rational RequisitePro 项目来关联软件包


下一步是指定 IBM Rational RequisitePro 项目，该项目将与 IBM Rational XDE Developer 模型进行集成。

从 Rational XDE Developer Tools 菜单中选择 Rational RequisitePro > Associate Model to Project，并且定位 Rational RequisitePro 项目，将项目与该模型关联起来（图5）。一个 Rational RequisitePro 项目包括文档类型和需求类型。文档类型用于选定 Microsoft Word 文档模板，该文档模板以 Word 文档记录不同的需求，需求类型用于按具有共同属性（优先级、风险、难度、状态等）的类别，将需求进行分组。

图5 Rational RequisitePro 项目和用例信息选择


当使用 Rational XDE Developer 进行新用例详细设计时，选择一个文档类型来作为用例文档模板，并且选择一个用例需求类型。Rational RequisitePro 提供了我们所推荐的默认项目结构，您可以从它开始工作。随着对工具的逐渐熟悉，您可以创建自己的文档类型和需求类型，以及项目模板，以便再次工作时使用。

当在 Rational XDE Developer 模型中指定了 Rational RequisitePro 项目后，下一步您可以从 Rational XDE Developer 用例图开始，将用例文档和 Rational RequisitePro 关联起来，并且为 Rational XDE Developer 设计要素添加跟踪功能。

为用例添加需求属性
在本文第一部分中讨论了为用例划分优先级过程，为该过程作准备，我们在 IBM Rational XDE Developer 中为用例设置需求属性，单击用例右键菜单，选择 RequisitePro?View Requirement Properties。在对话框中单击 Attributes 标签，然后设置用例属性值。注意您可以在与 Rational XDE Developer 模型关联后的 IBM Rational RequisitePro 项目中，改变"即开即用"的用例属性和它们的默认值。还可以从该对话框中，单击 Traceability 标签，来建立用例和其他需求之间的可跟踪性。

图6 在 Rational XDE Developer 中查看并编辑用例需求属性


为用例划分优先级
当在 Rational XDE Developer 中，为用例附加了用例文档或分配了需求属性后，用例即成为 Rational RequisitePro 中需求集的一部分。同样，可以使用 Rational RequisitePro 需求管理功能将用例排序（按优先级、按迭代等），来查询特定用例（例如只计划用于下一个迭代的用例，），并且生成用例矩阵。

IBM Rational RequisitePro 中一个属性矩阵视图（见图7）提供了一个全部用例（或所选的用例子集）和其对应属性的视图。该视图帮助您组织用例信息，来回答本文开始时的第一个问题：我如何组织用例？可以运行查询来确定将哪个用例分配给哪位设计人员，它们的实现难度有多大，或者应当在哪个版本中实现它们。这同时也回答了本文开始部分的另外一个问题：如何才能知道在哪个版本中实施某个特定的用例？

图7 Rational RequisitePro 中用例属性矩阵视图


创建用例文档
为了在 IBM Rational XDE Developer 中详细设计用例（为用例附加一个用例文档），可以在 Rational XDE Developer 中（从 Rational XDE Developer Model Explorer 或用例图）单击用例右键菜单，选择 RequisitePro>New Use Case Document。

在 Rational RequisitePro 控制下运行 Microsoft Word，可以显示基于模板的用例文档，并准备对其进行编辑。如果只想用 Microsoft Word 将用例规格说明记录下来，过后再将其输入到 Rational RequisitePro 中，那么您可以使用 RequisitePro ? Associate to RequisitePro 菜单选项，将现有的 Rational RequisitePro 文档和 Rational XDE Developer 中的用例关联起来。

在这点上，您应该拥有在 Rational RequisitePro 中完成的用例文档。

图8 从 Rational XDE Developer 创建用例规格说明


在用例文档中管理需求
在 IBM Rational RequisitePro 中，当完成对不同的用例事件流记录后，您可以识别功能性需求并将它们标记为需求（图9）。这样做使您能够为这些功能性需求附加需求属性，并且对其进行跟踪，直到它们成为高级需求。

图9 Rational RequisitePro 中的功能性需求


保持用例与业务需要一致
当为需要实现的用例划分了优先级后，应该确保这些用例与它们要实现的不断演进的用户需要一致。图 10 中的可跟踪性视图显示了在用例和变更需要之间建立的关系。使用可跟踪性矩阵，您可以查询业务需求，而不仅仅是对用例进行跟踪，这使您可以回答这个问题：这个用例是用于哪个特定业务需要的？另外，当业务需要发生变更时，您可以迅速获悉哪些用例可能受到该变更的影响，从而确保用例能够自始至终反映不断演进的业务需要。这里的一项可疑链接（图 10 中的红色箭头）表明由于业务需要 BUS1.4 的变更，可能需要对用例 UC1.2 进行修订。对可疑链接进行查询，可以回答这个问题：用例与它们所要解决的不断演进的业务需要一直保持密切联系吗？

图10 用例和业务需要之间的可跟踪性关系


确保设计能够实现全部需要的功能
同样，为了确保设计能够真正实现需求，应该将 IBM Rational RequisitePro 中的需求与 IBM Rational XDE Developer 实现这些需求的设计要素链接起来，

在 Rational XDE Developer 中创建了设计要素（类、图等）后，可以单击设计要素的右键菜单，选择 RequisitePro ?Add Traceability（图11）， 将这些要素与驱动生成它们的需求链接起来。这样就在 Rational RequisitePro 中为该设计要素添加了表示法。

图11 完成 Rational RequisitePro 中设计要素的变更


当 IBM Rational XDE Developer 设计要素名称或简短描述发生变更时，可以调用同一个菜单中的 RequisitePro? Update Traceability 选项来完成变更。如果要对 Rational XDE Developer 作出多项变更，可以通过选择 Tools ? Rational RequisitePro ? Update All Traceability 来快速完成所有变更（图12）。

图12 完成 Rational RequisitePro 多项设计变更


为 Rational XDE Developer 设计要素添加可跟踪性后，可以在 IBM Rational RequisitePro 中创建需求到设计的可跟踪性矩阵（图13）。需求（如用例）和设计之间的可跟踪性矩阵，是验证设计活动是否覆盖全部商定的需求的一种方法。

图 13 用例和设计之间的可跟踪性关系


在该链接建立之后，可以运行 IBM Rational RequisitePro 的报告功能，来评估设计对需求的覆盖度，并且用一个定量的答案来回答："全部经商定的需求，在设计中都考虑到了吗？"从而说明设计模型将要实现的已签发的每项需求。

需求与设计之间的链接，对于检测需求变更对设计要素产生的影响也至关重要。在链接到设计要素的某项需求发生变更时，在图 13 中，可疑链接（红色箭头）将取代蓝色箭头。对需求和设计之间的可疑链接进行查询，可以回答这样的关键问题：设计模型中的哪部分将受到最新需求变更的影响？

图 14 用例和设计之间的可疑关系


如需查看集成工作方面的更多信息，请参见 Rational XDE Developer 在线帮助。

结束语
总的来说，IBM Rational RequisitePro 和 IBM Rational XDE Developer 之间的集成，使开发人员能够清楚地交流需求信息，并且使设计与不断变更的需求保持一致。

这是达到最终目的的关键：交付能够实际解决客户需要的应用程序。

如果没有这项集成，用例将以 Microsoft Word 文档形式记录，不能够跟踪功能性需求，包括用例规格说明。这项缺陷将导致设计与需求无法保持一致。

如果没有这项集成，软件设计将置于偏离需求轨道的风险中。当某项需求发生变更时，迅速评估哪部分设计将受到该项变更的影响，最大限度地提高了设计满足客户需要的解决方案的成功概率，从而解决需求所表述的客户需要。

通过访问 http://www.rational.com/events/webinars/index.jsp 您可以查看如何使用该项集成的更多信息。

参考资料
书籍

- Kurt Bittner & Ian Spence, Use Case Modeling

- Alistair Cockburn, Writing Effective Use Cases