在CMM 1.1版本中第一个KPA（关键过程域）就是需求管理。虽然在CMM2级的标准文本中对需求管理的论述篇幅最少，但它却是最容易让开发人员和项目经理提出疑问的一个KPA.如何进行有效的需求管理？笔者将需求管理的基本原则与方法总结为以下几点：
● 必须与需求工程的其它活动紧密整合谈需求管理一定不能脱离需求工程。从完整意义上讲，需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理。狭义上，需求管理关心的是需求管理过程的建立，在企业或项目组中需要有一套规范的需求管理过程。而实际上从项目经理的角度上看，可能还有50%甚至更多的精力是用于关注结果的，所以对需求内容的管理与对需求形式的管理是密不可分的。
● 需求必须是文档化的、正确的、最新的、可管理的、可理解的需求必须有文档来记录，该文档必须是正确的，是经过验证的，是在受控的状态下变更的。而很多开发人员往往会问：“简单的系统就不用写需求了吧？”其实简单的系统未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了。有一次，笔者安排2名开发人员编写一个简单的单据录入模块。由于这两名开发人员以前均做过类似的系统，所以笔者仅给出了数据库的设计，并简单讲了一下模块的需求。然而，当系统交付时，才发现与想象中的系统差距非常大，很多需求在提出者看来是理所当然的，却被开发人员全部忽略了。
● 只要需求变化了，需求变更的影响就必须被评估无论需求变化的程度如何，只要需求变化了就必须进行评估，这是基本的原则。此外，在一个项目组中必须明确定义一个需求管理员，由他负责整个项目的需求管理工作，确保在发生需求变更时，受影响的产品能得到修改并与需求的变更保持一致，受影响的其它组也必须与客户协商一致。
● 需求必须分优先级 需求的优先级可能比需求本身更加重要在每一次产品开发过程中，都会遇到这样一个问题：负责产品需求的领域专家罗列了长长的功能列表，每个功能似乎都是不可或缺的，而当排出进度表后，却发现工期是公司不能接受的，没办法，必须裁剪需求。没有需求就不会有产品，而没有产品就没有利润。如果需求过多，反而可能是陷阱——只有投入，没有产出。一个好的项目需求，必须有需求的优先级，便于进行项目的整体平衡。
● 需求一定要分类管理在做工程项目的时候一定要将需求分出层次，不同层次的需求侧重点是不一样的，描述的方式是不同的，管理的方式也是不同的。比如说，在企业里高层领导提出来的是目标性需求，中层管理人员提出来的是具体的业务流程的需求，而作业人员提出来的是更侧重于操作性的需求。对于目标性的需求可能采用简短的几句话就可以描述清楚，但这是项目的决策性需求，需要很稳定，不能轻易更改，在确定的时候需要慎之又慎。
 【责编:runlz】 |
 |
|
|
 |
|
