四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用，但如果实现了则会更好，定级为“Better”。界面和使用方式的需求，一般在这个档次。
　
　　五级需求是可选性需求，更多的是偶是一种设想，以及一种可能，通常只是客户的的一种个人喜好而已，定级为“Maybe”。
　
　　对于四级需求，如果时间和资源条件都允许的话，不妨做下去。对于五级需求，正如对它的描述一样，做与不做是“Maybe”。
　
　　2、全生命周期的需求变更管理
　
　　各种规模和类型的软件项目的生命周期大致可以分为三个阶段，即项目启动、项目实施、项目收尾。不要以为需求变更的管理和控制只是发生在项目实施阶段，而是要贯穿在整个项目生命周期的全过程中。
　
　　站在全局角度的需求变更管理，需要采用综合变更控制的方法。
　
　　（1） 项目启动阶段的变更预防
　
　　正如前面强调的，对于任何软件项目，需求变更都无可避免，也无从逃避，无论是项目经理还是开发人员只能积极应对，而这个应对应该是从项目启动的需求分析阶段就开始了。
　
　　对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理提出需求变更的几率就越小。如果需求没做好，基准文件里的范围含糊不清，被客户发现还有很大的“新需求空间”，这时候项目组往往要付出许多无谓的牺牲。
　
　　如果需求分析做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候，项目经理一定要据理力争，此时这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。 
　
　　（2） 项目实施阶段的需求变更
　
　　成功的软件项目和失败项目的区别就在于项目的整个过程是否是可控的。
　
　　项目经理应该树立一个理念，即“需求变更是必然的、可控的，并且是有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
　
　　控制需求渐变需要注意以下几点：
　
　　需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。
　
　　需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。
　
　　小的需求变更也要经过正规的需求管理流程，否则会积少成多。

　在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。
　
　　精确的需求与范围定义并不会阻止需求的变更。
　
　　并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。
　
　　注意沟通的技巧。
　
　　项目开发过程中的实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。 

　　与哑铃型管理模式对应的是橄榄型管理模式。

　　通常而言，哑铃型管理模式的企业要力求经常保持四类产品：

　　1.正在市场上销售的产品；

　　2.已经研究成功并不断加以改进、等待适当时机投入市场的产品；

　　3.正在试制的产品；

　　4.正在构思或开始实验的。

　　（二）实现企业管理观念的转轨：由重生产轻开发转为重开发重科研。

　　（三）实现适应市场需求的经营战略转轨：由被动靠市场抢占市场引导市场。

　　（四）实现技术改造投入规模的转轨：由“生计型”投人转为“发展型、扩张型”投入。

　　（五）实现管理方式的转轨：由传统方式管理转为科学管理。

　　很多项目之所以成功，就是总经理亲自带队全程参加整体CRP测试，整整在会议室坐了一个半天。我们说ERP工程是“一把手工程”，如果说一把手的确做到全程参加整体CRP的话，从这一点看那一把手工程就是落到了实处。当然我们的CRP测试必须是用企业真实的数据、真实的流程，得出真实的结果，而不是瞎编几个数据，走个形式。CRP测试的理念必须是以业务流程为主线来测试，测试流程和数据，而不是仅仅测试系统有没有问题。