如果您对以上任一问题的答案是肯定的，那么请继续阅读下文，您的问题很有希望得到解决。作为开发人员，您可能认为需求管理(RM)不如设计和实现技巧来得重要。实际上，很多开发人员认为 RM 是项目团队中分析人员的责任，开发人员在此过程中的任务仅限于接收需求规格说明书。在一个项目中，如果开发人员的角色仅限于需求的接受者，那么您会发现经常需要返工。这将导致延误项目交付日期，缩小项目的范围，而且导致交付给客户的项目质量不合格。而这些将最终导致客户不满，客户的不满意反过来又会影响项目团队的士气和心情。在成功的项目中，开发人员在 RM 中涉足的范围更广，扮演着较为重要的角色。这使得他们对开发对象具有更好的控制力，最大程度地减少返工量，最终也就能够给向客户交付正确的解决方案。

本文旨在说明在一个成功的软件项目团队中开发人员在 RM 中扮演的重要角色。此外，本文还提供了一些 RM 实施方面的技巧，开发人员可通过应用这些技巧，帮助项目团队在为客户提供正确的解决方案方面取得更大的成功。

开发人员为什么要关注需求管理？
作为开发人员，您可能认为"我没有时间进行需求管理"，或者"RM 与我毫无关系"。如果情况正是这样，那么项目团队如何定义您正在构建的系统功能呢？实际上，您对于项目交付的职责是由某位人员决定并定义的。无论这位人员只是在头脑中计划着这些需求、在纸上草画出需求、在正式会议上讨论了需求，还是将需求正式记录在需求文档中，每个软件开发团队都要涉及某种形式的需求管理。他们可能并没有意识到，因为他们的 RM 实践可能极其不规范。不管怎样，所有软件团队都要进行某种程度的 RM。问题只是您的软件团队的 RM 实践的规范化程度如何。

理解开发人员在 RM 中的重要性，有助于反映 RM 的目的。RM 的目的是在客户和软件组之间建立共识，其内容包括查找、文档化、组织并跟踪不断变化的需求。与客户达成共识是计划和管理项目的基础。如果项目团队不能有效管理需求，那么他们达到关键里程碑的能力就会受到损害，进而影响项目计划的精确度和效用。这通常导致开发和测试资源被浪费在错误方面。开发人员在 RM 上扮演了重要角色，不仅因为他们根据需求构建软件，而且因为他们能够防止项目团队一开始就使用不完整或者模糊需求。最大化需求的完整性和清晰度是保证整个项目成功的转折点，可以确保包括测试人员和文档编写人员在内的整修团队能够在最短的时间内构建质量合格的系统。

RM 的正式程度因项目和项目团队而异，并且与您的项目团队在不能交付正确的软件解决方案方面愿意冒多大的风险直接相关。RM 过程的正式程度越差，项目团队不能向客户交付令他们满意的软件的风险就越大。幸运的是，项目中 RM 的松散程度是权衡 RM 形式的优缺点之后所作的一个简明的决定。关于采用松散 RM 过程的最常见的论据包括：它可以使的开发速度更快，可以更好地适应不断变化的市场，并且不需要正式的需求文档来了解我们应该创建什么系统。不幸的是，这些论据是项目团队很难实际把握的，并且需要仔细分析项目成功所需的 RM 正式程度。从根本上说，RM 实践应该产生：1）所有项目团队成员都能够清楚理解的需求，2）对不断变化的需求的控制，以保证项目团队能够跟踪正确解决方案的交付，3）有效的沟通，以保证整个项目团队协调一致。

有时使用非常正式的 RM 实践可能是小题大做。比如，如果您的项目团队任务是构建一个视频游戏，那么扩展请求和需求变更就可能频繁出现，以至于随后如果使用传统变更控制过程（需要变更控制委员会的批准）实际上可能妨碍项目成功。这种情况下，变更控制过程实际上限制了开发人员的创新，并且成为软件交付的瓶颈。然而，即使在这种情况下，项目团队仍可以使用诸如故事板或原型这样的RM技术在开发和交付之前验证游戏创意，并从中获益。

在另一个极端上，也有极其需要使用非常正式的 RM 实践的时候。比如，如果项目团队的任务是开发一个运行医疗设备的软件，它能根据情况自动管理病人的精确的、正确的用药量，那么项目团队就应该采用高度正式的 RM 过程来保证开发出正确的系统。这种情况下需求错误的风险可能危及人的生命安全。

那么 RM 如何影响像您这样的开发人员呢？诸如 Standish Group 报告（见参考文献）这样的研究表明，需求错误是修复成本最高的错误，因为它们出错的时间越长，影响就越大。随着软件开发生命周期的进展，这些错误越来越难以纠正，这实际上产生了雪球效应。如果您从一个错误的需求或者需求变更开始，那么您的设计就是无效的，这最终会导致进行代价昂贵的构架返工。确认测试也是错误的，用户文档也不精确，等等。最终，这将导致花费更多的时间来修复问题，而这些是完全可以避免的。

但您是开发人员，而不是分析人员。RM 不是仅用于分析人员的吗？可以肯定的是，您项目团队中代表客户的那些人涉入 RM 最深。分析人员通常负责创建需求。然而，需求的质量不仅仅落在分析人员的肩上。记住，整个项目团队对需求有一个完整清楚的理解是至关重要的。为了实现这种质量，开发人员必须尽早参与，以帮助澄清最初需求版本中的模糊性。开发人员提供了一种实现视角，能够提高已编写需求的质量，并且能够增加开发解决方案的成功率。与开发人员的合作是"如鱼得水"；开发人员负责将概念转化为现实。因此，开发人员越早参与需求的澄清，项目成功交付正确的软件解决方案的机会就越大。

开发人员还应该关心适当的 RM，因为它可以简化他们的工作。当从高质量的需求而不是很差劲的需求（这样的需求总需要团队成员查找测试内容，并且用各种问题打断开发人员）开始工作时，质量保证（QA）或质量工程（QE）和文档编辑团队的工作就更有效率。另外，维护活动可以减少到只专注于系统中真正的实施缺陷，而不是由不清楚和不完整的原始需求导致的缺陷。更高质量的需求最终能够保证软件的质量更高，这使得开发人员可以集中精力思考如何对系统作出改进。

与拙劣的需求管理相关的软件问题
让我们看一下可能面对的问题，将它们与拙劣的 RM 实践中的根本原因挂钩，并为每个问题提出解决办法。

问题1：持续变更
市场或销售人员每隔多久会要求您在代码中加入客户请求的变更？通常变更看上去都是很小，并且看上去是合理的。当然您希望能够成功地完成代码编写，所以您非常愿意满足他们的请求，并且加班加点地在代码中加入变更。这些持续性的中断影响您设计和交付优质软件的效率。您很难集中精力。但是更大的破坏是接受这些随意的请求对项目计划和总体软件质量造成的影响。像这样持续的中断使项目计划超出了最初的范围，这就是通常所说的"范围蔓延"。这些打断分散了项目团队的思路，使他们无法按照最初目标交付软件，从而导致所交付的软件不能满足客户期望。

该需求问题的根源在于，项目团队在接受变更或扩展请求之前不能正确评估它们的影响。

让开发人员对这些直接请求作出响应，可能导致项目团队不能正确评估接受变更的整体影响。结果，如果开发人员接受这些乍一看很小的请求，就会导致必须对代码的其他部分作出必要变更的涟漪效应。同样，涟漪效应超出了代码范围，扩大到了项目团队的其他领域。比如，如果没有将变更有效地通知测试人员，那么他们可能就不能构建出必要的验证脚本来测试变更，从而带来了影响软件质量的风险。此外，即使变更只需要开发人员的一点点努力就能实现，但是对 QA/QE 或文档的影响可能延误整个项目进度。由于涟漪效应的存在，整个项目团队为出现的变更召开会议就很有必要。

由于这些依赖关系，开发人员将接受变更的权利委派给项目团队中对项目交付有着高度和完整预见性的人就变得很重要。为了降低破坏项目稳定性的风险，您只希望接受被项目团队批准的变更，这样您就知道您正在实现的是一个商定的功能，并且每个人都有义务测试和记录该功能。

解决办法：通过评估变更的影响控制需求变更
良好的 RM 实践可以避免未经评估就随意做出变更。他们将变更请求视为"头等公民"，以保证所有潜在的变更都经过检查，并且接受变更的影响能在影响开发人员的工作之前得到评估。

需求规格说明书应该经过由客户、开发团队和测试团队三方代表组成的小组批准之后才能进行变更。这个小组通常被称为 CCB。该组的职责是从客户的角度、开发的角度、测试和文档化的角度评估每一个被请求的变更。根据应用程序类型的不同，培训和支持人员可能也需要参与进来。

为什么需要所有这些人参与呢？因为每个代表都在分析实施给定变更请求的潜在影响或成本时具有不同的视角：

• 开发代表负责评估变更请求影响的所有软件设计区域，以及实施变更所需的后续努力。通常需要个别开发人员作为这样的代表参与分析变更请求的影响。
• QA 代表必需评估与接受提议变更相关的测试工作的可行性和程度。我们应该时刻记住变更可能很容易加入到代码中，但是很难（有时候甚至不可能）测试。
• 客户代表提供了业务视角，并保证变更不会使项目偏离最初的业务目标，以及提供有关变更的任何信息来帮助 CCB 理解客户需要。
• 最后，为了安全起见，包含来自 CCB 的培训、支持和文档化代表也是我们推荐的，因为变更请求通常也对这些领域有影响。

为了保证评估过程的有效性，CCB 的每个成员应该负责查找一个适当的替代品，以防万一，从而保证对变更请求的评估绝没有偏见。对于所有方面都没有代表的罕见情况，应该将变更请求推迟到以后再评估。

好的 RM 实践应该防止开发人员匆忙地对事情做出变更。需求的变更方面，从您编写它们开始直到交付软件，都是项目中最难应付的事情。Standish Group 在它 2001 Extreme Chaos 报告中指出："变更需求就像死亡和税收一样确定无疑"。掌握管理变更需求的技巧对于项目的成功很重要，并且它还是一种直接影响开发人员生活的实践。

迭代开发取代传统的瀑布型方法对管理需求变更是一种很大的帮助。在传统方法中，需求规格说明书在项目一开始就被冻结了，并且直到软件发布之后变更还不能加入进入。让变更进入版本中的唯一方法就是直接找开发人员，请求他们变更代码。这也正是我们前面看到的由于不能评估变更对项目真正的总体影响而导致项目不稳定的方法。迭代开发允许软件团队将工作分割成小的部分，其中需求是稳定的并且在迭代过程中保持不变。在下一次迭代开始时，团队就有机会更新需求规格说明书，以加入上一次迭代中提交和接受的变更。在迭代开发中，规格说明书只在迭代开始时发生变更，而不能在迭代过程中进行变更。这使得我们可以在迭代期间把注意力集中在一组需求上。当下一次迭代来临时，您就会被分配一组缺陷和新的或更新过的需求。

问题2：处在影响您工作的变更的盲区
当需求发生变更时，如何通知您？您的经理被通知吗？通常开发人员都依据过时的需求工作，因为有些人忘了将影响他们工作的变更通知给他们。

即使在实际中，QE/QA 和文档化通常比开发人员更处于盲区之中，经常出现这种情况：没有及时将间接影响开发人员工作的变更通知开发人员。团队中的分析人员可能与另一位开发人员讨论，衡量变更的影响，但是却没有意识到它可能对开发人员工作的影响。

解决办法：需求变更通知
好的 RM 实践确保在影响您工作的变更发生时，您能够得到通知。同时通知您应该与哪些人取得联系，以保证您使用的是最新的需求。

如何知道需求变更何时会影响您的工作？除非您团队中的某个人对需求与实现这些需求的设计要素之间的关系进行跟踪，否则很难快速评估需求变更对设计的影响。好的RM都对需求和设计工件之间的依赖关系做了跟踪，以便在需求发生变更时您能查明设计的哪一部分受到影响。

由于需求是不断变化的目标，所以RM的一个主要利益是能跟踪需求是否被实现。这就是所谓的可跟踪性。存在各种级别的可跟踪性，但不幸的是，同时也有许多方法在滥用可跟踪性。可跟踪性的任务是保证您为客户许诺的功能能够真正实现（由开发人员来完成），并且按照指定的要求工作（由测试人员确认）。为了保证能够实现需求，并评估需求变更对设计的影响，需求应该被跟踪到设计元素。为了保证需求发生变更时能够得到验证同时测试验证也得到更新，需求应该被跟踪到测试工件（通常为测试用例）。

从需求跟踪到源代码会如何呢？虽然乍一看很有吸引力（比如，如果我变更一个需求，我知道哪些代码必须更新），但实际上代码在本质上比需求更具动态性。您可以从一个设计开始，然后优化该设计。新设计可能会导致代码变更，但是它仍与需求一致。维护可跟踪性链接需要花费时间，但是软件团队永远也没有足够的时间。所以您应该明智地使用可跟踪性。可跟踪性的真正价值在于将需求跟踪到设计和测试。编写代码实施规格说明书的方法有很多种，但是最终用户不会关心您编写的代码是什么，只要它满足需要就可以了（需求是清楚无误地向整个软件团队表达这些需要的媒介）。这种情况的一个例外是如果您工作的系统经过了标准实体（如 FDA）的审计，该标准实体托管了从需求到代码（有时甚至几行代码）的可跟踪性。即使这种情况，您在构建软件时仍不应该将需求跟踪到代码。您只需要报告最终产品需求跟踪到了代码，并且每段代码都实现了一个需求。管理需求和源代码之间的可跟踪性链接可能是一个没有多少实效的耗时工作。

问题3：根据不完整的需求规格说明书编写代码
需求文档的最初版本中总是存在模糊性，这是您的团队面临的主要RM挑战之一。上一次读需求文档并感觉您确切理解了构建目标是什么时候？大部分需求文档不包含开发人员设计系统所需的足够信息，而是留下了让他们"解释"用户需要的余地。

尽管分析人员通过RM会议、联合应用开发（JAD）会议、会见或者专题组收集和文档化需求下了不少功夫，但是开发人员在第一次读完需求之后还是有很多疑问。不管分析人员多么专业，都会出现这种情况。通常，开发人员只提供了一个可能被分析人员忽略的不同的视角。比如，开发人员通常会提出系统用户可能遇到而分析人员却没有意识到的异常情况。因此，开发人员和分析人员必须紧密合作，在开始设计之前精化原始的需求规格说明书。开发人员应该无拘束地向分析人员提出有关需求规格说明书的问题，而分析人员则应该提供答案，必要时甚至可以直接与客户联系。

解决办法：详细且无歧义的需求规格说明书
好的RM实践认识到需求规格说明书的初版需要项目团队的检查，并且还需要开发人员关于该规格说明书的提问。因此，必须给予开发人员足够的时间来检查并提出关于需求的问题。反过来，负责任的需求分析人员应该回答工程师提出的问题，并将这些澄清记录在需求文档中。出于项目规划的目的，应该为这种检查分配时间，尤其是让分析人员直接与客户一起检查未知问题以获得更多细节的时间。因此，需求规格说明书检查应该成为常规工作，而不是项目中的例外情况。最后，在开始设计之前应该解决所有的开发人员问题。如果完备的需求规格说明书检查受到影响，那么您的项目团队就面临着工程师在系统设计中引进不希望的假定的风险。

除了检查之外，另一种可用的有效实践是使用用例来表达功能需求。用例通过从用户的观点将系统功能记录为一系列步骤描述了系统与外部世界交互时的行为。该视角为软件团队和他们的客户提供了对待建系统的预期行为的共同理解。通过最小化需求误解的风险，用例还能够提高需求的清晰度。比如，在使用用例的项目中，分析人员通常只注意主要用例（关于如何使用系统的用法场景）并且相信没有大问题。然而，一旦开发人员开始通过识别所有备用流（在出错情况下的备用用法场景）来整理用例的细节，真正的问题就浮出水面。如果开发人员在设计之前没有进行这种细化，那么该设计就需要多次返工，以便包含所有的用户场景。该细化过程中，能否在开发人员和分析人员之间建立起关键的交流关系，通常决定了能否成功交付最终产品。

然而，必须注意到并非所有需求都可以用用例表达。比如，可靠性和性能需求更适合以声明性的形式表达（如，"系统应该……"），但是用例确实提供了一种从各种视角记录系统的用户体验的机制。通过专注于用户观点，用例还避免了在需求规格说明书中引进设计元素的问题，从而将设计者从无根据的设计约束中解脱出来。

问题4：根据过时的需求规格说明书编写代码
在可以开始设计和编写代码之前，需要了解交付目标，并且分析人员负责确认您理解了客户需要。这是需求规格说明文档的任务。它必须保证项目团队中的每个人对要将要开发用来解决客户提出的特定问题的系统有着共同理解。如果需求规格说明文档的角色已经给定，那么开发人员就可以很容易地定位文档，更重要的是定位它的最新版本。这看上去可能没有什么意义，但经过验证它非常灵活。通常，要按照特别的基础来检查规格说明书，并且还要做出决定和假设。不幸的是，在这种情况下，需求并不总能及时得到更新。此外，更新过的需求不能总是重新分发给项目团队。另一种情况可能是更新过的需求被重新分发之后，淹没在每个人邮箱中的邮件堆里，无从寻觅。最后，保证最新的需求并提供对它们的访问应该是项目团队的标准实践。

解决办法：最新的规格说明书随时可用
好的 RM 实践为管理需求规格说明书清楚地确定了一个中央知识库，这样每个人都能总是得到最新的需求版本。作为开发人员不能依赖电子邮件时间标记，您可以保证不以一个过时版本的需求文档开始工作，从而不浪费时间和精力。此外，与项目团队交流（通过电子邮件、电话、会议等）需求已经被更新的消息也是一种良好、健康的实践。

在机构中改善需求管理的六种技巧
本节，我们提供为开发人员提供简单有效的指导，帮助他们避免前面讨论过的软件问题。

技巧1：参与建立变更请求过程
这可能看上去令人畏缩，但实际上却很容易实现。简单地说，任何变更请求在被接受之前都应该经过确认。

• 建立变更请求过程的第一步是确定您的团队如何收集和管理变更请求。最简单的方法是创建一个标准的纸张形式表格，每个人都可以通过电子邮件或者亲自填写该表格。更健壮的方法是使用某种程度的自动化工具支持。
• 接着，您需要确定如何存储这些请求。这些纸张形式文档可以存放在一个三环的活页夹中吗？或者您会使用有些种类的电子数据库？使用商业性的缺陷与变更跟踪工具（如 IBM Rational ClearQuest），允许在Web上提交变更请求，不需要本地软件安装，并且允许 CCB 进行查询以筛选变更请求并确定接受哪些，从而极大地简化了变更请求的管理。
• 然后项目团队需要决定 CCB 多久应碰一次面来检查变更请求，并且要决定在确定应该实现哪一个时所使用的标准。

技巧2：在加强已建立的变更请求过程中学会说"No"
作为开发人员，您在成功建立变更请求过程中扮演了关键角色。越是没有让 CCB 评估它们就接受和实施来自典型来源（如，销售人员、客户和高级经理等）的特别变更请求，项目团队就越感觉变更无穷无尽。同样，这只会增加直接奔您而来的特别请求的数量，因为请求者知道您是他们实现希望的特性所可以依赖的人。

为了帮助控制影响您项目团队的持续不断的变更，您必须学会向请求者说"不"，并且将他们引导到您已建立的变更控制过程。这看上去可能很容易，但是这通常会导致高压情形。比如，最成功的销售人员可能很有影响力和说服力，并且通常是很多特别请求的煽动者。销售人员通过说这样的话来施加压力，"如果您添加那个特性我就用不着 XYZ 账户了"或者"我最近从竞争对手那里丢掉了很多生意，因为我们没有 ABC 特性"。不管他的论据看上去多么充分，您和开发团队都必须表现出坚定的原则，并礼貌地将这些请求者引导到您已建立的变更控制过程中。这些请求者的行为不可能一夜之间改变，但是假以时日，一定会有所改观。

技巧3：建立和参与需求规格说明书检查
需求规格说明书检查是确认是否理解需求的简单有效的方法。作为开发人员，您知道不管何时收到一组需求您都会有很多问题，因为有些规格说明书不清楚或者是含糊的。与其猜测规格说明书的意图，从而增加不能交付客户期望的软件的风险并导致返工，不如为项目计划分配时间进行定期的需求规格说明书检查。这些检查不需要很正式，相反它们应该是一个开放的论坛，需求规格说明书的特定部分都可以拿来与指定的开发人员公开讨论，以保证人们清楚地理解了这些需求。

作为开发人员，应该主动参与这些检查会议，并且应该在对需求的解释的基础上准备一个初步的设计或者概念。该过程本质上是高度迭代的，因为在开发团队能够对需求有一个清楚的理解并且开始设计之前通常需要多次会议。同样，通过这些迭代，保证所有变更被正确捕获和记录就是分析人员的责任了。在您以及其他开发人员开始设计之前，整个项目团队必须对所有需求有一致的理解。

此外，需求规格说明书检查的迭代本性为项目团队提供了一种自我检查机制，保证了软件需求和初步设计的质量。通过保持这两个工件的同步，项目团队会保持同步前进，并增加交付成功解决方案的机会。因此，在实际阶段应该分配时间进行需求规格说明书检查。经常在设计阶段，很多开发人员在需求规格说明书检查中发现更多的含糊性需要澄清。这里再一次需要需求规格说明书检查。

技巧4：需要一个术语表
术语表是消除需求规格说明书中模糊性并避免误解的简单却强有力的手段，应该由分析人员拥有、开发和维护。由于时间的限制，项目团队成员可能不知道他们对同一需求有着不同的解释。术语表不需要列出需求规格说明书中用过的每一个词汇，但是它必须包含可能有歧义的词汇。术语表通过给出需求规格说明书中关键词汇的定义，消除了模糊性。如果术语表中的词汇有具体和重要的关系（比如，在构建财务应用中，客户可能只有一定数目的账户，并且同一账户不能被两个以上的人拥有），您可能希望用一个域模型来补充术语表。该域模型可视化地描述了客户与账户之间的一致关系，因为开发软件时需要考虑这些关系。

项目团队的任何成员都可以建议分析人员在术语表中添加词汇，但是整个项目团队必须对词汇的定义达成一致。作为开发人员，您必须保证清楚地理解了影响您正负责开发的系统领域的关键词汇。

技巧5：坚持项目远景以帮助提供解决方案的环境
为了帮助获得对正在构建的软件应用程序的理解，项目领导人或者分析人员应该将项目团队要解决的特定业务问题文档化。由于时间压力，很多软件团队没有花时间分析他们将要解决的业务问题。相反，他们将重点放在他们负责的特定需求上，并且尽可能快地转移到设计上。如果没有理解业务问题，开发人员就面临着开发出来的产品不不能满足客户希望的风险。

让我们暂且考虑一下车模配件吧，完全包装在一个很好看的盒子里，盒子上印着一个完整的汽车。您打开之后会看到说明书以及大量需要粘合在一起的零部件。如果您只是一头扎进说明书，开始构建您的车模，那么您将不能得到包装盒上所描绘的漂亮的小汽车。您将得到一个不伦不类的东西。然而，如果仔细研究盒子上的图片，然后再根据说明书组装汽车，那么您将得到正确的最终产品，一辆令您兴奋的小汽车。在这项比喻中，盒子上的汽车图片就像是远景，说明书就是需求。同样，在软件项目中，项目团队需要知道远景，以便为客户构建正确的解决方案。作为开发人员，在您研究需求并开始设计之前，先检查项目的远景文档。如果它不存在，那么可以向项目领导人或者分析人员提出该问题，并坚持让他们为您开发一个。这样就可以节省大量的时间，避免浪费在开发无用软件上。

技巧6：采用用例来说明系统功能
以用例的形势表达功能性需求，以更好地理解用户如何使用该软件。通过创建软件的用法故事，用例帮助我们整理需求细节，并避免了开发人员的很多猜测工作。用例在为技术和非技术人员提供需求表达格式方面具有独特作用。它们创建了一个通用描述，表达了软件应该为用户提供哪些功能。通过避免需求传统的用户和系统表示（通常导致技术性稍差的分析人员和技术性很强的开发人员之间的脱节），用例给予软件团队对预期系统功能达成一致理解的更好机会。

此外，用例故事板是构建用户接口原型以确认需求的另一种不错的方法。用例故事板是关于用例中描述的功能如何以用户接口表示的逻辑和概念性描述。用例故事板尤其适用于理解可用性需求。它们代表了用户接口的高级理解，并且开发起来比实际的用户接口更快。用例故事板因此可用于在各种用户接口被原型化、设计和实现之前对其进行讨论。

编写良好的用例已成为一种实践，IBM Rational 在 Rational Edge (http://www.therationaledge.com)上提供了关于如何编写良好用例的在线研讨会和各种文章。此外，对于现有的 IBM Rational 客户，Rational Developer Network 上也有大量的信息。

利用工具自动完成需求管理过程
在进行需求管理时能给予软件团队的最大帮助就是过程指南。一个 RM 工具本身可能有帮助，但是只能达到过程还不错的程度。此外，RM 工具只能帮助自动完成部分过程。比如，没有工具能够取代项目团队成员之间的交流需要。为了成功，首先把重点放在您机构的 RM 实践上，并保证它们是健康的，能够正常工作。只有此时，您的项目团队才能从使用 RM工具中获益。

IBM Rational 提供了完整的 RM 解决方案，包括 IBM Rational Unified Process? (RUP?)中的过程指南、利用 Rational RequisitePro? 进行的工具自动完成，以及来自 Rational University (http://www.rational.com/university/index.jsp)的公共或现场课堂。IBM Rational还通过当地的客户服务部门提供了各种形式的现场专业服务。

需求管理最佳实践
几本书中总结了最佳实践（见本文推荐的一些参考书目）。然而，及时访问指南通常是确保遵守指南的最佳实践。这也正是 IBM Rational 为什么在 RUP 中以可导航和可搜索的 Web 站点的形式发布在线软件开发过程指南的原因。这些指南包括用于有效管理需求的角色和职责。您可以从 http://www.rational.com/products/rup/index.jsp 上大概了解一下 RUP。

图1 Rational Unified Process 中的最佳实践

RUP 还包括工具指导，告诉您如何利用 Rational RequisitePro 实现 RM 最佳实践。

图2 Rational RequisitePro Tool Mentor--Rational Unified Process 中的工具指南

一种用于开发人员的需求管理工具
通过自动完成RM的部分过程，Rational RequisitePro 为开发人员提供了如下利益：

• 快速访问最新的需求规格说明书
• 控制需求变更
• 在检查规格说明书时快速访问术语表
• 对需求创建和变更的完整审计跟踪
• 快速识别需求变更对设计的影响
• 用例规格说明书模板

大多数开发人员发现 Rational RequisitePro 是最容易使用的需求管理工具，因为它集成了 Microsoft Word，而他们已经收到的需求规格说明书可能就是 Word 格式的。

图3 Rational RequisitePro--需求数据库与 Microsoft Word 的紧密集成

为了对 Rational RequisitePro 有大致了解，请看下面的演示记录：

• http://www.rational.com/products/reqpro/index.jsp 上的概述演示
• http://www.rational.com/tryit/reqpro/seeit.jsp 上的详细演示

利用开发工具访问需求
除了以上提供的对需求的轻松访问，Rational RequisitePro 还与以下 IBM Rational 开发环境集成：IBM Rational XDE? Professional、 Microsoft? .NET Edition 和 IBM Rational XDE? Professional:Java? Platform Edition (www.rational.com/xde)。Rational RequisitePro 还与 IBM Rational 的可视化建模工具 IBM Rational Rose (www.rational.com/rose ) 集成在一起，从而提供了直接从您选择的环境到需求规格说明书的快速和及时的访问。

这些集成提供了从用例图（记录在 Rational XDE 或 Rational Rose 中）到用例规格说明书（存储在 Rational RequisitePro 中）的无缝导航。利用这些集成，RequisitePro 将用例规格说明书作为真正的需求文档维护，从而保证您在文档化软件用例的同时得到管理需求的所有利益。

关于这些集成的更多信息，请见 Rational Web 站点上的用例管理白皮书(www.rational.com/products/reqpro/whitepapers.jsp)。

结束语
我们希望本文能向您证明开发人员必须在实现有效的需求管理技术方面扮演积极的角色，以保证项目的成功并最大限度地降低开发人员工作中的混乱程度。

通过拒绝未经批准的变更，并且在开始设计软件之前对需求文档中的模糊性和完整性提出疑问，能够减少日常返工和挫折，并且还会帮助团队交付真正解决客户问题的软件，而这正是在软件行业中成功立足之本。

伴随着快速交付软件的压力，需求从一开始就要正确也变得越来越重要，因为您可能没有机会修复因较差的需求而导致的缺陷。由于需求对开发生命周期其他部分的影响（它们定义了设计内容，测试内容，以及用户手册内容），需求错误已经成为软件项目中成本最昂贵的错误。但是一旦您知道了要注意哪些方面之后，就可以相对易于避免需求错误。我们希望本文能够在需要注意的这些方面为您指点一条迷津。