需求和需求管理为什么需要管理需求？
　
　　简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。 以下最近收集的证据很有说服力： Standish Group 从 1994 年到 2001 年的 CHAOS Reports 证实，导致项目失败的最重要的原因与需求有关。 2001年，Standish Group 的CHAOS Reports报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是"变更用户需求".为什么要管理需求？
　
　　避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理。
　
　　什么是需求？
　
　　理解需求管理的第一步就是对什么是需求管理达成共识。Rational 把需求定义为"（正在构建的）系统必须符合的条件或具备的功能".电气和电子工程师学会使用的定义与此类似。 著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面 - 但不仅仅限于软件："软件需求可定义为： 用户解决某一问题或达到某一目标所需的软件功能。 系统或系统构件为了满足合同，规约，标准或其他正式实行的文档而必须满足或具备的软件功能。"什么是需求管理由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。 换句话说，需求管理就是：一种获取，组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
　
　　这个定义与 Dorfman 与 Thayer 以及 IEEE 的"软件需求工程"的定义相似。需求工程包括获取，分析，规定，验证和管理软件需求，而"软件需求管理"则是对所有相关活动的规划和控制。这里介绍的以及 IBM Rational提出的需求管理定义包括了所有这些活动。它们的区别主要在于这里选用了"管理"这个词，而不是"工程".管理这个词更合适用来描述所有涉及到的活动，并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性。
　
　　对那些不熟悉"引出"这个词的人来说，它可定义为团队用来获取或发现涉众请求，确定请求后隐藏的真正需要，以及为满足这些需要对系统提出的一组适当需求。
　
　　需求管理问题 一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢 当它真正在实际项目实施时，困难就暴露出来了。图 1 显示了年对开发人员，经理和质量保证人员所做的一次调查结果。该图显示了经历过最常提到的需求相关难题的受访者比例。
　
　　下面列出了更多与需求有关的问题：需求不总是显而易见的，而且它可来自各个方面。 需求并不总是容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求的数量将难以管理。 需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。 需求有唯一的特征或特征值。例如，它们既非同等重要，处理的难度也不同。 需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。 需求发生变更。 需求可能对时间敏感。 当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时，许多团队都对管理好需求不抱希望了。IBM Rational 已经开发出指导团队提高需求管理技能和流程的专业技术，并使用相应的工具使得上述的流程和专业技术得以实现。
　
　　需求捕获从上述的分析可以看出，需求的捕获是需求管理的基础和前提。在这里，将介绍一
　

[1] [2] [3] 下一页  

【责编:Lili】