在CMM^®1.1版本中第一个KPA是需求管理，是CMM^®2级的标准文本中论述篇幅最少的一个KPA，这也是在CMM^®2级中最容易让开发人员与项目经理提出疑问的一个KPA：为什么需求需要管理？如何进行有效的需求管理？

1为什么需要需求管理？
需求是整个项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题：
 需求的描述方式问题Ø
如何使项目组的开发人员、客户、最终用户等各个方面各个层次的人员能够清楚的读懂需求文档？曾经有多个项目经理向我抱怨，在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。这能怪客户吗？问题出在需求是如何描述的？需求管理的评审会是如何组织的？不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。

 需求的完备程度问题Ø
需求如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，而建立一个基线。

 需求开发的工期问题Ø
在需求上花费了大量的时间（而不是人*工时，因为需求阶段人多了也没有作用），客户、软件公司是否能够忍受？为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已！他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。

 需求的细致程度问题Ø
需求到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。

 需求的变化问题Ø
在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多，如：
 一开始没有识别全，需要增加需求；²
 业务发生了变化，需求必须变化；²
 需求错误；²
 需求不清楚；²
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。
难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是“项目需求的渐变”（Project Scope Creep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。

2 需求管理的目标

在CMM^®1.1中，需求管理的目标定义为：
1) 把软件需求建立一个基线供软件工程和管理使用。
2) 软件计划、活动和工作产品同软件需求保持一致。
软件需求作为软件工程的基线是很容易理解的，而作为管理的基线可能有些人无法理解。从需求阶段稍微向下一个阶段延伸就会发现，软件需求是软件项目策划的基础，只有有了明确的项目需求，才能保证计划中的任务识别的比较全面，否则计划的可行性就大打折扣了。当然，需求改变了，软件计划、软件的开发活动、工作产品等就必然要发生变化，计划、活动与工作产品必须与需求保持一致。
其实需求管理还有一个更高的目标：
3) 软件需求的复用。
笔者曾经遇到过一位领域专家，他在有20多年的领域工程经验，积累了大量的领域需求，可是在其每进行一次产品开发时，他总是感到他所理解的需求无法为与他配合的分析人员、设计人员所接受。当我们一起来讨论这个问题的时候，共同的一个观点就是：没有对需求进行有效的管理，已经形成的需求文档没有很好的复用。所以需求管理一个很重要的目标应是提高软件需求的复用率。

3 需求管理的基本原则与方法
（1）必须与需求工程的其他活动紧密整合
就象在上面讨论的那样，谈需求管理一定不能脱离需求工程，从完整意义上讲，需求工程包括了：需求获取、需求分析、需求描述、需求验证、需求管理，狭义的需求管理指已经建立了软件需求后，需求变更的管理，而广义的需求管理自需求获取阶段已经开始了。需求管理的难易层度、好坏和需求的获取的质量、需求分析的质量、需求描述的方式、需求验证的充分性是密不可分。从狭义上来讲需求管理关心的是需求管理过程的建立，在企业或项目组中需要有一套规范的需求管理过程，而实际上从项目经理的角度上可能还有50%甚至更多的精力是关注结果的，所以对需求内容的管理与对需求形式的管理是密不可分的。

（2）需求必须是文档化的、正确的、最新的、可管理的、可理解的
笔者曾经被紧急委派主管一个已经进入了编码后期阶段的项目，该项目已经换过2次项目经理了，这是第3次更换项目经理了，用户方的IT部经理马上来找我抱怨：“我已经是第3次来给你们讲补货申请的处理规则了！”。我只能表示抱歉，因为我无法找到原来的需求描述，这是一个变更的需求，前任的项目经理讲他只是将当时与用户交流的需求记到2页草稿纸上，不幸的是，那2页珍贵的手稿现在已经找不到了！更不幸的是，该IT部经理是在转述业务部门的需求，当软件开发完毕后，业务部门讲“这不是我们最初给IT部反映的需求，我们说的不是这样的！”。
所以需求必须有文档来记录，该文档必须是正确的，是经过验证的，是在受控的状态下变更的。而很多开发人员会提这样一个问题：简单的系统就不用写需求了吧？这是很多开发人员不写需求的借口“这么简单，说说就行了！”。其实简单的系统未必简单，想清楚、写清楚、说清楚才说明真正把需求整理清楚了。有一次，我安排2名开发人员编写一个单据录入的模块，仅给出了数据库的设计，简单说了一下模块的需求，这两名开发人员以前均做过类似的系统，在大家看来这是一个很简单的系统，不需要太多的沟通，然后，当系统交付时，才发现想象中的系统与现实的系统差距是如此之大，在需求提出者看来是想当然的问题，开发人员却全都忽略了！

（3）只要需求变化了，需求变更的影响就必须被评估
在上面我们谈到需求渐变的问题，无论需求变化的多少，只要需求变化了就必须进行评估，这是基本的原则。控制需求渐变需要注意以下几点：
 需求一定要与投入有显示的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。²
 需求的变更要经过出资者的认可，需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量的“小”的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。²
 小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。²
 精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。²
 注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更“精致”，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。²

在一个项目组中必须明确定义需求管理员，由他负责整个项目的需求管理工作，确保在发生需求变更时，受影响的工作产品必须修改并与需求的变更保持一致，受影响的其他组和客户必须协商一致。

（4）需求必须分优先级
需求的优先级可能比需求本身更加重要。在我进行的每一次产品开发过程中，都遇到过这个问题：负责产品需求的领域专家罗列了长长的功能列表，每个功能都是需求的，都是不可或缺的，当排出进度表后，发现工期是公司不能接受的，没办法，必须裁剪需求。因此，没有需求就不会有产品，没有产品就没有利润，需求过多，反而可能是陷阱，只有投入，没有产出。一个好的项目需求，必须有需求的优先级，便于进行项目的整体平衡。

（5）需求一定要分类管理
在做工程项目的时候一定要给需求分出层次，不同层次的需求侧重点是不一样的、描述的方式是不同的、管理的方式也是不同的。比如说在企业里高层领导提出来的是目标性需求，中层管理人员的管理人员提出来的是具体的业务流程的需求，而作业人员提出来的更侧重于操作性的需求。对于目标性的需求可能采用简短的几句话就可以描述清楚，但这是项目的决策性需求，需要很稳定，不能轻易更改，在确定的时候需要慎之又慎。目标性需求对于双方所有的人都是约束，而且它不仅仅含有软件需求，更重要的是对整个系统的需求。对于业务需求而言也是基本稳定的，它一般覆盖系统的局部，可以比较详细的用文字描述出来，需求之间的关系错综复杂，这类需求一般也变化比较多，需要分析人员、需求管理者花费较大的精力来描述、来管理。操作性需求最适合采用原型的方法来描述，可以比较直观的刻画出来，尽管变化多，但是很少有结构性的变化。对于需求还可以从其他方面来分类，如：功能性需求与非功能性需求、技术性需求与非技术需求等，对需求的分类管理有助于我们把握需求的本质，分析不同类需求的特点，根据不同类的需求的特点采用不同的管理方法。