则，那么我们事先也需要建立“游戏规则”。
如果事先没有“游戏规则”的话，开发方的负责人需要一些社交技巧来减缓矛盾。例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。
另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。
需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。
二、为什么需要管理需求？
简单地说,系统开发团队之所以管理需求,是因为他们想让项目获得成功.满足项目需求即为成功打下了基础.若无法管理需求,达到目标的几率就会降低. 以下最近收集的证据很有说服力: 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 显示了年对开发人员,经理和质量保证人员所做的一次调查结果.该图显示了经历过最常提到的需求相关难题的受访者比例.
下面列出了更多与需求有关的问题:
需求不总是显而易见的,而且它可来自各个方面. 需求并不总是容易用文字明白无误地表达. 存在不同种类的需求,其详细程度各不相同. 如果不加以控制
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
