需求变更管理

《需求变更管理》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、三、需求变更控制前面已经说过了，在软件开发项目开始之前，就要消除“绝不允许发生需求变更”的思想。在项目进行，一旦发生需求变更，更不要不i味的抱怨，也不要去一味地sp;曲而己经说过了，在软件开发项目开始之前，就要消除“绝不允许发生需求变更”的思想。在项目进行，一旦发生需求变更，更不要不一味的抱怨，也不要去一味地迎合客户的“新需求”，而是要管理和控制需求变更。软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全的止确，因为在己经签定的项II合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到了客户的投入收益，所以有的时候项H经

2、理反倒应该为客八着想。对于项目中的需求，可以实行分级管理，以达到対需求变更的控制和管理。•一级需求（或变更）是关键性的需求，这种需求如果不满足，意味着整个项li不能止常交付使用，前期工作也会被全部否定。这个级别的需求是必须满足的，否则就意味着否定1'1已的项目成员和成员的所有努力，所以定为“Urgent”。这通常是属于补救性的debug类型,要救火。・二级需求（或变更）是后续关键性需求，它不影响询而工作内容的交付，但不加以满足，新的项目内容无法提交或继续，所以是“Necessary”。一般新模块关键性的基础组件，属于这个级别。•三级需求是后续

3、重要的需求，如果不被满足会令整体项n工作的价值下降，为了体现项目价值，也是开发人员自已的技术价值的证明，所以定为“Needed”。一般性的重大的有价值的全新模块开发，属于这个级别。以上三个等级是应该实施的，但吋间性上可以作优先级的排列。•四级需求是改良性需求，没有满足这类需求并不影响U有功能的使用，但如果实现了则会更好，定级为“Better”。界而和使用方式的需求，一•般在这个档次。•五级需求是可选性需求，更多的是偶是一种设想，以及一种可能，通常只是客八的的一种个人喜好而已，定级为“Maybe”。対于四级需求，如果时间和资源条件都允许的话，不

4、妨做下去。对于五级需求，止如对它的描述一样，做与不做是“Maybe”。2、全生命周期的需求变更管理各种规模和类型的软件项目的生命周期人致可以分为三个阶段，即项目启动、项目实施、项n收尾。不要以为需求变更的管理和控制只是发生在项n实施阶段，而是要贯穿在整个项目生命周期的全过程中。站在全局和度的需求变更管理，需要采川综合变更控制的方法。（D项目启动阶段的变更预防止如前面强调的，对于任何软件项目，需求变更都无可避免，也无从逃避，无论是项目经理还是开发人员只能枳极应对，而这个应对应该是从项目启动的需求分析阶段就开始To对一个需求分析做得很好的项目來说

5、，基准文件定义的范围越详细清晰，用八跟项目经理提出需求变更的儿率就越小。如果需求没做好，基准文件里的范圉含糊不清，被客八发现还有很大的“新需求空间”，这时候项口组往往要付出许多无谓的牺牲。如果蛊求分析做得好，文档清晰且又有'客户签字，那么后期幺户提出的变更就超出了合同范围，需要另外收费。这个时候，项目经理一定要据理力争，此时这并非耍刻意赚取客户的钱财，而是不能让客八养成经常变更的习惯，否则后患无穷。（2）项日实施阶段的盂求变更成功的软件项廿和失败项h的区别就在丁•项h的整个过程是否是可控的。项忖经理应该树立一个理念，即“需求变更是必然的、可控

6、的，并且是有益的”。项忖实施阶段的变更控制需要做的是分析变更请求，评估变更可能带來的风险和修改基准文件。控制需求渐变需要注意以下儿点:•需求一定要与投入有联系，如果需求变更的成本山开发方來承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这i条：需求变，软件开发的投人也要变。•需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。•小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行止规的需求管理过程，认为降低了开发效率，浪

7、费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。•精确的需求与范国定义并不会阻止需求的变更。并非对需求定义得越细，就越能能避免盂求的渐变，这是两个层面的问题。太细的需求定义对盂求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。•注意沟通的技巧。项H开发过程中的实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也对能来口开发方，因此，作为需求管理者，项目经理需耍采用各种沟通技巧來使项目的各方各得其所。（3）、项目收尾阶段的总结能力的捉高往往不是从成功的经验中來，而

8、是从失败的教训中得來。许多项H经理不注重经验教训总结和积累，即使在项目运作过程屮碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何