三级需求是后续重要的需求，如果不被满足会令整体项目工作的价值下降，为了体现项目价值，也是开发人员自已的技术价值的证明，所以定为“Needed”。一般性的重大的有价值的全新模块开发，属于这个级别。

　　以上三个等级是应该实施的，但时间性上可以作优先级的排列。

　　四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用，但如果实现了则会更好，定级为“Better”。界面和使用方式的需求，一般在这个档次。

　　五级需求是可选性需求，更多的是一种设想，以及一种可能，通常只是客户的的一种个人喜好而已，定级为“Maybe”。

　　对于四级需求，如果时间和资源条件都允许的话，不妨做下去。对于五级需求，正如对它的描述一样做与不做是“Maybe”。

　　3、加强需求变更的控制

　　在需求分析阶段工作完成后，需求变更仍可以会发生，因此要加强对需求变更的控制，主要有以下原则：

　　（1）建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

　　（2）制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

　　（3）成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

　　（4）需求变更一定要先申请然后再评估，后经过与变更大小相当级别的评审确认。

　　（5）需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

　　（6）妥善保存变更产生的相关文档。

　　这六大原则看起来简单，但真正实施起来有难度，还需要依据理论知识配合开发项目组的实际工作情况，在实践中不断摸索总结。

　　四、总结

　　软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理，将需求变更的频次大幅度降低，从而为软件项目的顺利实施打下坚实基础。