敏捷开发允许我们快速地交付高质量的软件产品。敏捷项目开发需要开发团队、涉众以及用户之间频繁且深入的交流，以获取真正的客户需求及目标。

如果开发团队位于同一个地理位置，那么敏捷开发方法会强调面对面的会议来进行沟通，而不是撰写文档来进行交流。然而，当开发团队散布于不同的地理位置时，很难进行有效的远程交流。而当涉众也同样位于不同的地理位置，那么对产品需求这一最为重要的沟通交流来说，将可能十分困难。同时，由于敏捷项目管理热衷于接受变更以及采纳迭代开发方法，因此需要一个有效的工具以更轻松和快捷地进行设计和交流。

IBM? Rational? Requirements Composer 软件可以促进涉众与开发团队之间关于需求定义和需求管理之间的交流。它使得涉众可以使用各种可视化及基于文本的技术来进行同一语境协作，以捕捉商业目标并精确化软件需求。

在分析需求沟通上存在的障碍之后，本文将继续介绍 Rational Requirements Composer 提供了三项关键的特性以支持敏捷开发（您可以在 Jazz.net 社区中进一步了解 Rational Requirements Composer）。

协作作以定义基于文本及可视化的需求

通过使用一系列各种各样的定义技术：文本、记事板、用例图、用户界面草图以及业务流程图等，来精化、获取并简化需求。

使用强大功能的客户端以及 Web UI

需求获取者可以使用 Eclipse 客户端来创建、精化并管理需求工件。

需求评审组可以使用小型的 Web UI 来评审和评论工件，而不需要安装软件。

与 Rational RequisitePro 集成以实现需求的可追溯性

正如您所知道的那样，敏捷开发用户会在软件开发的所有阶段中使用迭代方法，这些阶段包括在开始阶段中与涉众一起定义需求。如果您将 IBM? Rational? Requirements Composer 与 IBM? Rational?

RequisitePro? 集成起来，那么您可以得到完整的需求可追溯性，并且可以完全控制需求定义过程。

图 1 显示了敏捷项目中需求定义与设计的迭代循环过程。本章节详细介绍了敏捷开发中的迭代需求定义过程（参见参考资料 部分以链接到 Rational 需求中心信息中心以得到更多信息）。

图 1. 迭代需求定义过程

解决业务问题

在迭代需求定义的第一阶段，业务分析员有责任收集关于当前业务中存在难题的信息，这样在后续阶段中需求才能够得到合适的发展。收集有用信息的方式有几种。首先，业务分析员会安排一次与涉众及系统用户的面对面会议。每一个涉众和用户都可以向业务分析员告诉他们关于系统的要求、期望和不满。第二，分析员会收集关于当前系统的文献及相关信息资源。有几种方式可以收集信息。

记录评价过程

在弄清楚业务难题之后，业务分析员会创建文件及其他的工件，来描述当前的系统及预期的解决方法。这些工件可以拥有不同的形式，但是实际上都包含有以下这些项目：

• 当前系统的文献
• 方案的目标
• 涉众的需求以及期望
• 与方案相关的问题与风险
• 业务过程草图
• 记事板

用例图

工件组成了项目需求的来源。在图 1 中，您可以看到迭代循环拥有一个起始点，它意味着如果需求没有任意改动及重排的话，这个过程可以得到不停的重复。项目团队会重复地评审和更新评价过程，以交付项目的需求基线。

评审评价过程

在记录评价过程之后，业务分析员就可以让其他的团队成员进行一项评审，这样他们就可以向相关的文献添加自己的评论了。然后分析员可以与其他的成员讨论这些评论，并将变更整合到相关的工件中去。

向涉众展示并得到反馈信息

然后项目团队可以向涉众展示草拟的工件。这些工件可以包含一个需求文件、一个草拟的用户界面、用户事例等等。如果涉众认为指定的需求是不完整的、模糊的甚至自相矛盾的，那么他们给给出他们的评论，这样项目团队可以进行相应的调整。这样就使得迭代需求循环又回到文件评价阶段。您可以重复进行文件评价、评审评价，并不断地向涉众进行展示，直到项目团队和涉众达成一致意见为止。

交付需求基线

如果需求定义得到了涉众的确认，那么项目团队就会交付需求基线，并在项目生命周期阶段管理它。

循序渐进介绍的范例：Fantasy Bookstore

在本段中，我们使用一个在线书店程序作为范例，来向您展示怎样将 Rational Requirements Composer 应用到迭代需求定义过程之中。

项目描述：

Fantasy Bookstore 是一个在线书店程序，用于在网上销售各种类型的书籍。它支持各种类型的支付手段、汇款、现金交易（COD）以及信用卡。
如果您想定义 Fantasy Bookstore 的需求，那么您可以按照前面介绍的过程来进行操作。

准备步骤

创建项目

在安装和配置 Rational Requirements Composer 服务器之后，您需要链接到一个存储库上，该储存库链接到 Rational Requirements Composer 服务器上之后，您的团队就可以创建项目并存储项目工件了。

然后您可以使用只包含有属性组基准项目模板，来创建一个名为 Fantasy Bookstore 的项目。

图 2. 链接到储存库上

创建并向项目添加用户

在创建项目之后，适用管理员页面来向项目添加用户，并分配成员的角色。在我们的书店项目中，我们将团队里的成员分成三组角色：

管理员：执行管理性操作。例如创建项目和文件夹，管理用户的访问等等。

程序设计者：组成项目的工件。

评审者：评审项目的工件并提供评论。

图 3. 管理 Rational Requirements Composer 中的用户角色

1. 评价业务上的难题并上传工件

业务分析员与客户面对面地交流以收集关于 Fantasy Bookstore 的文件和信息。然后分析员会将文件导入到 Rational Requirements Composer：

在创建的项目中，您可以创建文件夹以包含各种项目的工件。

对于已经存在的工件，例如文件和图片，您就可以使用上传特性，或者只是将文件从本地的文件夹中拖拉到 Rational Requirements Composer 文件夹视图中。在我们的项目中，会为与涉众的交流上传文件：

图 4. 为项目上传文件

2. 记录评价过程

业务分析员会创建一系列的文件及其他的工件，以表达当前的系统以及预期的方案。

词汇表：业务分析员会从与涉众面谈的结果中提取一些专业术语，以创建项目词汇的条目，例如那些目录、销售商店、普通用户、VIP

用户等等的条目。

用例：就像其他的需求分析工具一样，Rational Requirements Composer 会提供工具和视图以创建用例。在您书写用例之前，您可以在书店项目中创建三种类型的角色：管理员，用户，以及 VIP 用户。然后在 Fantasy Bookstore 项目中创建七个用例。在用例中，您可以向项目轻松添加其他已经存在的工件。图

5 中的屏幕截图列出了 Fantasy Bookstore 项目中的所有用例。

图 5. 用例

用例图：在 Rational Requirements Composer 中，您可以通过使用已经存在的用例及角色，来轻松组合成用例图，或者您可以简单地创建新的用例图。

图 6. 用例图

草图：Rational Requirements Composer 中的一个重要的特性，就是它提高了一个手工调板和工具，以创建可以轻松更改和编辑的用户界面的一个雏形（也就是所谓的草图）。草图可以帮助开发团队以一种方便的方式，来理解需求并将他们的设计方案展现出来。这在敏捷开发项目中十分的有用，特别是在使用迭代化设计和执行方法时更是有用。

草图由图片、部件、面板和页面组成。

部件：您可以创建一个能在多页面中使用的公共部件。在 Fantasy Bookstore 项目中，Victor 以及 UI 设计者会创建一个头标部件，它是所有页面的公共头标，如图 7 中的屏幕截图所示。

面板：多个 UI 控件可以组成一个面板。Victor 会将文本区域和一个按钮进行分组以创建一个签名面板（见于图 8）。

图 8. 面板

页面：通过合并部件与面板，您可以创建页面。Victor 会添加头标部件与签名面板以组成登录页面。除了登录页面，Victor 还会为其他的用例创建书籍搜索页面以及支付页面（查看接下来的三个范例）。

图 9. 登录页面

图 10. 搜索页面

图 11. 支付手段选择页面

屏幕流程：在您创建草图之后，您可以创建屏幕流程文献以指示页面的流程。

记事板：记事板会为由草图组成的框架呈现了整个的用户情况。有了记事板，涉众可以轻松评审用户界面及交流的整个过程。基于这些草图，Victor 会创建整个书店销售的情况。情况包含了以下的用例：签名 > 搜索一本书 > 评审书的具体情况 > 向货架添加书籍 > 评审货架 > 为书籍付款。记事板由这些用例中的框架组成，如图 12 组成。Rational Requirements Composer 提供了一种轻松的方式来从已经存在的草图或者前期的框架中创建框架。因为 Fantasy Bookstore 支持两种支付方法，汇款以及现金交易（COD），所以 Victor 会为这些两种方法创建两个记事板。

图 12. 书店销售的记事板

定义需求：您可以从已经存在的工件中创建需求。例如，您可以打开一个记事板，右击您想要为之草拟需求的构件，然后选择 Mark As Requirement 以在 Rational Requirements Composer 中添加一项需求。您还可以打开其他的工件，例如一个用例文件，并强调显示文本以提取一项需求，如图 13 所示。

图 13. 提取背景中的需求

例如，在签名面板中，我们可以创建三种类型的需求（见于图 14）：

密码应该是不可见的。

如果用户 ID 或者密码无效则显示一条出错信息。

用户 ID 的长度应该介于 3 到 20 个字符。

图 14. 登录需求

向涉众展示并得到回馈

有两种方式可以向涉众展示工件：

将工件作为 Microsoft? Word 文件导出。涉众可以评价本地的工件。

通过使用 Web UI 来展示它们。涉众可以登录到 Rational Requirements Composer 服务器 Web UI 来评审项目的工件，还可以直接添加评论，如图 16 所示。

图 16. 评审 Web UI 中的评价视图

在评审两个支付记事板之后，涉众可以提出一项变更：“书店应该支持使用信用卡作为支付手段”。这就是需求上的变更。因此，工件设计者 Victor 可以编辑相关的工件来整合这项变更。

为这项变更添加一个新的面谈结果文件。

通过添加一个术语，“信用卡”来变更词汇表。

通过添加第三种支付手段来编辑支付用例。

通过添加信用卡选项来编辑支付草图。

添加通过信用卡支付的记事板。

添加通过信用卡支付的需求。

图 17、18 和19 显示了对支付草图所做的更改。因为草图由不同的部件和面板组成，所以可以很容易地为变更需求编辑已经存在的草图。

图 17. 添加支付方法选项

图 18. 添加信用卡输入

图 19. 在确认页面上添加信用卡信息

第 5 步至第 7 步可以进行不断的重复，直到所有的需求都得到澄清，并且用户界面得到涉众 的确认为止。它可以轻松应用到敏捷开发过程中。

交付并管理 Rational RequisitePro 中的需求基线

通过不断地重复第 2 步至第 4 步，您就可以定义项目的需求基线。为了管理需求，业务管理员会使用 Rational RequisitePro 来添加需求。Rational Requirements Composer 被设计成可以与 Rational RequisitePro 进行集成，以在需求管理过程中进行合作。您可以选择在 Rational RequisitePro 项目中创建并管理需求，然后将它们导入到 Rational Requirements Composer 项目中以进行更具体和更精致的编辑。同样，您可以定义 Rational Requirements Composer 中的需求，并向一个 Rational RequisitePro 项目添加需求。

总结

敏捷开发的目标包括快速设计以及验证用户需求，它需要与涉众就需求进行充分的交流，就算他们处于不同的位置也是这样。但是，远距离地交流是十分困难的，因为在基于文本的文件内进行可视地设计很难节省时间，而且很难进行追踪或者稳定下来。结果，如果涉众和开发团队需要在每一次迭代过程中就需求就行远程的交流，那么敏捷开发就会遇到一个障碍。

本文介绍了 Rational Requirements Composer 是怎样帮助您克服这个障碍，以及它是怎样促进关于需求的远程交流的。有了 Rational Requirements Composer，项目团队可以创建用例、UI 草图以及记事板，并重复性地得到来自涉众的反馈。这些基于文本和可见的工件支持需求定义阶段中有效的协作。所有的需求可以轻松转化为 Rational RequisitePro，并且在整个项目的生命周期内对其进行管理。