使用 Rational RequisitePro 进行需求管理的新技术

从 Kumar Mani 的这个系列中发现捕获，管理和跟踪构架需求的新方法。这种方法是建立在构架理论基础上的，且适用于所有的 IT 项目。如果您是一位在公司或者综合项目中面临复杂请求的IT构架师或者经理，您就可以利用这些方法来管理这个项目，并有助于保证及时交付的时间。这篇文章探究了利用 IBM® Rational® 工具集的实现，但是它能够被复制，就像使用其它产品一样简单。

介绍

这篇文章描述了一个构架方法和一个着重强调 需求项目、获取需求的科学、分析以及项目整个生命周期的管理需求的技术。尽管这篇文章是利用 Rational 工具集来阐述这些技术的，但是并不是特意为这些产品来做指导的。你们的目的是利用基本的构架技术并将它们运用到您的项目中。IT 构架师对 Rational 都比较熟悉，当然也应该能够很容易地在他们的项目中复制这些技术。

需求非常重要是因为它们是来自开发架构的中心的。 图 1 显示了 Open Group Architecture Framework Architecture Development Method (TOGAF ADM) 和它的八个阶段。

图1. TOGAF Architecture Development Method

需求作为一种需要、机会或者缺乏的表现，贯穿整个开发过程驱动着其他的阶段。然而需求管理在项目中由于许多不同的原因通常被忽略或者并没有被充分地处理。IT 构架师通常会问：

• "我正在利用 Rational 产品来建模或者开发，可是我怎样才能将它们与需求联系起来呢？"
• "我们已经拥有了 XYZ 工具并有可比较的特性，这里所说的有什么更好的特性呢？"

IT 专家喜欢清晰地陈述他们的技术需求，以便他们能够开始编码。项目经理和消费者们并不清楚像 Rational RequisitePro® 这类工具的好处，也不清楚它们与 Rational Portfolio Manager，诸如此类项目管理工具的适应性。（有些项目使用了整个 Rational 工具集，除了 RequisitePro！）在这篇文章中还回答了一些有效的问题。

 

像 Rational 这样的工具，如果我们适当地运用，就具有重要的意义。有些项目经理把工具（比如 RequisitePro）作为需求的智囊库，也就是说，这些需求被输入了这个工具，然后报告就从这个工具中发布。于是项目经理就对他们为什么看不见切实 的利益而感到奇怪。

这篇文章的目的就是填补产品文档与方法文档之间的空白。这个 Rational 工具文档很好地描述了它的特性和能力，方法文档中含有大量的方法和最佳实践。然而，IT 构架师仍然面对着如何将这个工具的利益最大化的问题。在这篇文章中，您将学到业务需求、用例，以及基本的跟踪能力，并附有系统级别的需求、组件，以及测试过程中的跟踪性。

Empire Systems Corporation

为了论证如何最佳使用构架需求技术，这个系列的文章将会涉及到来自 Empire Systems Corporation (ESC) 的特殊的，假定的例子，个人计算机、膝上电脑、电脑组件以及相关硬件，比如 Web 照相机和麦克风的虚构的制造商和供应商。ESC 已经有一个 Web 应用，并且已经启用了许多它的应用软件。现在公司的领导者想通过流线的过程把公司转型到下一个级别，使业务能力自动化，采用一个企业构架，最终，提高税收和利益率。

业务需求

成 功的 IT 项目都是以良好的业务需求开始的。技术文档含有需求工程的方法、技术和最佳实践。然而，对于需求的讨论，尤其是业务需求通常非常模糊、散漫，并且一般而言 都比较难于理解。由于缺乏清晰的需求表达会影响到业务需求的传递，随后会影响映射到技术需求。让我们重新回顾一下一些基本的需求工程的原则。

重视业务

业务需求应该重视实际的业务需求，并要与其它的业务概念有明显特性（比如远景、任务、目标或者结果）。通常的一个错误将业务的目标（例如，“达到缩减20％成本的目标”）陈述为一个业务的需求。

尽可能简洁

需求必须是 具体的 、 可测量的 、 可控的 、 可现实的 以及 限时 的。这比看起来更有挑战性。可是，通过寻问以下的问题就能够很容易地完成：

• 为什么要用这种方式来处理？
• 您将获得什么样的结果，或者如果这个问题被解决您将能够做什么？
• 明确地说，什么过程将会受到这个障碍的影响？
• 通过补偿这个过程将会得到什么利益（尽可能是可计算的）？
• 做什么来改变事情？

  这通常很难回答，涉众们往往回到问题的陈述上来。需求工程可以以一些如果……怎么样 的建议来获取一些可能性。尽管如此，还是要在涉众们回到正轨时立即撤回。

• 关于时间框架，对于背景和业务环境什么时候可以完成？

  这并不是特意为项目交付而设的点，而是推理业务 背景的起点。例如，一个上网卡的商人想要以节日为目标开张他的新 Web 站点。

确定并阐明范围

什么是 进 什么是 出 ？ 什么被执行了或者被交付了，什么时间？

确定“主语”和“谓语”

这是经常最容易被忽略的，也是范围频繁变化的主要原因。如果这不仅仅是一个动词，可以将它规定为独特的需求。这提高了明确性并促进涉众们之间更好的理解。

关注需求本身 ，而不是如何实现

业务需求通常陈述完成了 什么 ，并且应该避免任何关于 怎样 完成的提示。例如，一个企业想要主观的、综合的观点融合到他们的业务数据中。重点应该是他们想要做什么，而不是他们需要得到什么（例如，数据库）。

需求样例

ESC 有几个基于 Web 的应用软件。因为每个应用软件都是独立开发的，消费者面临着像需要分别在每个应用软件上注册以及对于每个业务功能需要不同的窗口的问题，引起了他们的抱怨。为了解决这些抱怨，ESC 业务小组制定了下面的需求：

BR264 ： 消费者应该能够通过一个兼容的界面访问所有的 ESC 应用软件，并且只需要注册一次。ESCWeb（主要的商业 Web 网站）对于所有的消费者应该有相同的外观和感觉。这将减少用户差错并提高用户的体验。ESCWeb 最终也将支持移动的和远程的客户。

很显然，这个需求能够被改善。通过运用这些原则，我们能够对它进行如下的重述。

BR264 ：在 ESC5.0 版本中，消费者想要注册一次就可以应用所有的 ES C应用软件，包括 ESCWeb、 ESCOrderStatus、 ESCVendor 以及 ESCSupport。

BR265 ：在 ESC5.0 版本中，所有的 ESC 应用软件将执行 ESC Web Standard 273-1 和 273-2，这将再减少10％的用户差错。

技术1. 确定 RequisitePro 中的业务需求

在这个记录将需求记录在 RequisitePro 的技术中，关键是保持获取和澄清这个需求的原则。这个技术包括三个步骤：

1. 确定一个业务需求的 Requirement Type 。所有的业务需求都将分配这个类型。BUS 是一个习惯性的前缀。
2. 当规定一个 Requirement Type 时，利用 Requirement Must Contain 选项来指定一个分隔符(比如 "|")。这个主语和谓语可被安置在分隔符的任何一边。这并不是强制性的要求，RequisitePro 手册有更多的细节。方法是在识别主谓成为需求的过程中使用逐渐导出的原则。
3. 在最高层次为业务需求创建一个包。您可以立即看到它是如何帮助跟踪的。

技术1现在已经完成。您已经获取了一个清晰而且简洁的业务需求，并准备好转向下一个阶段。 图 2 显示了这个技术。

图 2. 利用技术1获取业务需求

用例

技术2 (将用例与需求连接起来 )覆盖了这个项目的下一个阶段。只要业务需要被确定，这个业务构架师或者分析师就会开发用例来对它们进行说明。尤其对于大的或者复杂的项目，业务分析师经常会遇到这样两个问题：

• 需求存在于文档中(除非您使用技术1 )，用例位于模型中，比如 Rational Rose® Enterprise (Rose)。
• 由于需求(和用例)的数量逐渐增长，拆分也变得越来越难于管理。

 

业务需求与用例是如何连接起来的？用例捕获用户的视角，他们说明了用户的行为和系统的回应。但是业务需求远远超越了作为一个服务于用例的数据源。当规定了 属性或者限制时，它们就变成了用例的属性（或者备用信息流）。我们应该能够记录业务需求和一个用例之间正常的连接，并用它做一些有意义的事情，比如跟踪或 者分析。

建模用例时需要大量的资料。在 资源 部分中的文章都是很好的起点。查看这些案例属于这篇文章以外的范围，但是我们将介绍一个应用于这个技术实现的命名习惯。

用例的命名原则

为什么用例的名字非常重要？回忆一下我们介绍过定义需求时主谓一致的结构。这个概念在这里得到延伸。主语由这个用例模型中的施动者来代表。我们的用例命名原则规定，用例应该以现在时态或者动词的动名词形式(ing )。在有些情况下，它有助于包括被动词修饰的宾语的名称。

技术 2. 连接用例与需求

现在是定义用例并把它们与需求连接起来的时候了。这个技术的目的是维持定义用例的明确性，使它们与需求保持连接（可跟踪的），可以采用下面的步骤：

1. 如果您的 RequisitePro 项目不包含用例的包或者用例的需求类型，那么就创建一个。
2. 利用 Associate Model to RequisitePro project 对话框将 Rose 模型和 RequisitePro 项目联系起来。Default Requirement Type 被设置为 Use Case 。
3. 现在您可以在 Rose 中创建您的模型。对于每个用例，首先根据命名原则创建一个 Use Case 类型的 RequisitePro 需求，如 图 3 所示。在 Requirement Text 中输入这个名字。
   
   图3. 用例命名原则
   
   　
4. 在 Rose 中创建这个用例。右键点击这个用例获取 Associate Requirement to Use Case 的对话框。 选择 Use Case in RequisitePro 然后点击 OK 。这将产生 Resolve Use Case Name 对话框，这个对话框非常重要因为它利用动词连接着用例和需求，如图 4 所示。
   
   图4. 连接用例和需求
   
   　
5. 您现在可以看到 Requirement Properties 的对话框。选择 Traceability 键，用例就回到了 BUS 需求。

这个技术已经完成。您可以通过对 RequisitePro 中的用例命名 来开始，它能够让您完全在 Rose 中进行定义、细化，并跟踪这个用例。这突出了 Rational 中的一个重大的优点：需求、建模和设计的整合。

跟踪性

为什么可跟踪性如此重要？ 可跟踪性 就 是对需求的生命周期从它的开始到各种转化，前前后后的跟随。随着企业的发展，也会对支持他们的系统（和他们的需求）进行跟踪。可跟踪性是联合需求的过去、 现在和将来关键的连接。可跟踪性可以提供一些数据，项目的各种分析，比如成本，覆盖范围以及影响力都可以根据这些数据来执行。

在实际中跟踪是很难做到的。主要的问题是可跟踪性被看作需求工程的一个附属的方 面。这些需求被规定在文档和构建在 Rose 中的模型中。可跟踪性通常是建模工作完成之后，手工记录在电子表格中的。维护这些电子表格非常麻烦而且容易出错。但是对项目影响更大的是，电子表格本身充 当了跟踪报告从而逃避了详细审查。

我们的下一个技术 解决了这个问题。这个技术的第 1 部分是，当需求被创建时 归纳出跟踪需求的原则。 （我们利用用例在前面的技术中已经证明的这一点。）这个思想是在需求的整个生命周期和测试中都要维持原则。第 2 部分是生成覆盖 和附属 报告。这个附属报告是影响分析的第一个层次。中心思想是，这些自动生成的报告在检查中需要详细审查。

覆盖 ， 正如其名字所示，确保同一个层次的每个需求在下一个层次都被覆盖（或者更进一步的规定）到。例如，每个用例都必须被测试用例覆盖到。附属需求就是那些在无 意中悄悄混进这一层次的需求，它们在之前一个层次中并不存在。在生命周期的早期把它们都捕获是十分重要的，因为在这个阶段的警告比系统交付后的错误报告更 容易处理。使这些功能自动化操作同样十分重要。

技术3. 跟踪覆盖和附属需求

这个技巧显示了如何构建 Coverage and Dangler 视图来业务需求和用例之间的差距。这些视图符合标准的 RequisitePro 视图框架。采用下面的步骤。

1. 从业务需求包的 Coverage 中，选择一个新的 View ，这里的 View Type 是一个跟踪性矩阵，Row Requirement Type 是 BUS，Column Requirement Type 是 UC。注意如何从技术1 重新利用 BUS 包。
2. 在 View Properties 框中，在行需求中创建一个名为 Business Requirements Coverage Query 。现在为这个 Query 增加 一个 Traced-from 属性。
3. 这将产生 Query Requirements 对话框。如 图 5 所示，选择 Not Traced 并选中 Direct links only 。
   
   图5. 跟踪覆盖
   
   　
4. 刷新这个 View 。您将可以看到这个没有相关用例的业务需求。您可以省略步骤2和3创建一个完整报告 View 。
5. Dangler 视图是通过在这个技术中反向 Query 标准来创建的。我们以列需求类型（用例）开始，并选择 Traced-to BUS 需求。这个视图显示了所有的附属用例。

这个技术已经完成。您可以跟踪用例到最初的业务需求，并可以排除虚假的用例和不完善的业务需求。您的项目现在可以安全地进入解决方案领域了。

总结

在这篇文章中，您研究了需求工程的基本原理并介绍了三个管理构架需求的新技术。回顾了需求的基本原则，描述了三个管理业务需求，用例和跟踪性的技术。

然而，我们仍然处于问题领域中。在本系列文章的第 2 部分，我我们将进入解决方案领域和解决方案开发的各个阶段（从架构的角度），并且探索管理解决方案交付的新技术。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
• "Requirements: An introduction " (developerWorks,2004年4月)：精确的需求是软件项目成功法则中必不可少的部分。我们在这篇文章找到了其中的原因，并学习到一种进行有效需求文档化的三重方法。
• "Agile requirements methods "：这篇 Rational Edge e-zine 文章(PDF)讨论了一个敏捷需求方法。
• "Transitioning from requirements to design ": 这篇 Rational Edge e-zine 文章 (PDF) 阐明了业务需求和用例的区别。
• "Use case management with Rational Rose and Rational RequisitePro "：这篇 Rational Edge e-zine 文章讨论了用例与需求的集成。
• "Adopting use cases, Part 1 " (developerWorks,2003年5月)：审查了用例和构架的不同类型。
• 访问developerWorks Architecture 获得您所需要的资源，提高您在构架领域中的技术。
• 找到更多关于 Rational Portfolio Manager 的资源。
• 找到更多关于 Rational Rose Enterprise 的资源。
• Rational Rose Enterprise：试用版下载 。
• 浏览技术书店 找到关于这些或者其它技术话题的书籍。

获得产品和技术

• 下载一个 Rational RequisitePro 的试用版本。
• 下载 IBM 产品评估试用版 ，并使用来自 DB2®、Lotus®、Rational、Tivoli® 以及 WebSphere ®的应用程序开发工具和中间件产品。