CMM 1.1版本中第一个KPA（关键过程域）就是需求管理。虽然在CMM2级的标准文本中对需求管理的论述篇幅最少，但它却是最容易让开发人员和项目经理提出疑问的一个KPA。如何进行有效的需求管理？笔者将需求管理的基本原则与方法总结为以下几点：

● 必须与需求工程的其它活动紧密整合

　　谈需求管理一定不能脱离需求工程。从完整意义上讲，需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理。狭义上，需求管理关心的是需求管理过程的建立，在企业或项目组中需要有一套规范的需求管理过程。而实际上从项目经理的角度上看，可能还有50%甚至更多的精力是用于关注结果的，所以对需求内容的管理与对需求形式的管理是密不可分的。

● 需求必须是文档化的、正确的、最新的、可管理的、可理解的

　　需求必须有文档来记录，该文档必须是正确的，是经过验证的，是在受控的状态下变更的。而很多开发人员往往会问：“简单的系统就不用写需求了吧？”其实简单的系统未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了。有一次，笔者安排2名开发人员编写一个简单的单据录入模块。由于这两名开发人员以前均做过类似的系统，所以笔者仅给出了数据库的设计，并简单讲了一下模块的需求。然而，当系统交付时，才发现与想象中的系统差距非常大，很多需求在提出者看来是理所当然的，却被开发人员全部忽略了。

● 只要需求变化了，需求变更的影响就必须被评估

　　无论需求变化的程度如何，只要需求变化了就必须进行评估，这是基本的原则。此外，在一个项目组中必须明确定义一个需求管理员，由他负责整个项目的需求管理工作，确保在发生需求变更时，受影响的产品能得到修改并与需求的变更保持一致，受影响的其它组也必须与客户协商一致。

● 需求必须分优先级 需求的优先级可能比需求本身更加重要

　　在每一次产品开发过程中，都会遇到这样一个问题：负责产品需求的领域专家罗列了长长的功能列表，每个功能似乎都是不可或缺的，而当排出进度表后，却发现工期是公司不能接受的，没办法，必须裁剪需求。没有需求就不会有产品，而没有产品就没有利润。如果需求过多，反而可能是陷阱——只有投入，没有产出。一个好的项目需求，必须有需求的优先级，便于进行项目的整体平衡。 ● 需求一定要分类管理

　　在做工程项目的时候一定要将需求分出层次，不同层次的需求侧重点是不一样的，描述的方式是不同的，管理的方式也是不同的。比如说，在企业里高层领导提出来的是目标性需求，中层管理人员提出来的是具体的业务流程的需求，而作业人员提出来的是更侧重于操作性的需求。对于目标性的需求可能采用简短的几句话就可以描述清楚，但这是项目的决策性需求，需要很稳定，不能轻易更改，在确定的时候需要慎之又慎