最近一直在想需求变更控制的事，资料也查了不少，可是查来查去，内容都差不多，无非是需求变更是一定要控制的，并且要经过申请、审批、执行、确认等流程， 几乎所有的资料给出的都是这样的内容，更多的，除了后面的流程之外，甚至连为什么要做控制都没说明。下面说说我的理解。因为所管理的项目几乎都是以合同为 基础的外部客户项目，所以讨论内容仅限于此类项目中，由客户提出的需求变更的管理。
为什么要做需求变更的管理？
进行需求变更管理的主要原因有两个，一个是防止范围蔓延引起的进度、成本、质量上，甚至严重时导致项目全面失败的问题；另一个是为以后留下筹码，以后要求 追加费用也好，或者让客户看到我们送给他们的人情也好，总之是为了使以后与客户相关的工作更顺畅。除了这两个原因之外，当然还有一些不是特别重要的原因， 比如使需求、设计、开发、测试之间对变更的理解一直等等。
需求变更管理的流程
需求变更管理的流程，在绝大多数的资料中，第一步都是提出变更申请。事实上，在此之前，还有至少一件事要做，就是与客户一起，约定变更管理的流程，最好在 合同中约定，至少也要在启动会上约定。而变更申请的提出，也应该按照约定的流程来，不是由客户的任何一个角色直接提给项目组中的任何角色，而是客户处提出 的所有需求变更，都归总到客户处的需求变更负责人处，由负责人判断哪些需要作为需求变更提出，哪些不需要提出，需要提出的需求变更，由负责人提交给项目经 理。
项目经理收到需求变更申请之后，要做的第一件事，不是审批，而是详细了解需求变更提出的前因后果和客户想通过需求变更解决什么问题，了解清楚这些之后，首 先尽可能寻找系统外解决问题的办法，若实在找不到，或者系统外解决办法可行性太低时，再进行变更工作量的评估和影响的分析，分析完之后，才能进行变更的审 批。在所有的审批人中，销售人员起到很重要的作用，因为销售要给出变更所需费用的来源，并要给出承诺，否则变更没办法继续。其他审批人则根据自己的角色和 职责进行审批即可。
审批完成之后，是执行环节。对绝大多数的变更，都可以不用马上执行变更动作，可以几个变更作为一批一起执行，一方面可以降低频繁变更对项目工作的影响，另一方面对一些客户一时兴起变过来过不久又变回去的变更可以起到拦截作用。
再之后是确认，需求变更之后的原型，需要在修改完之后就确认，而最终变更结果，则在系统验收时，统一确认。
此博客来自：http://blog.csdn.net/violet200211/article/details/8612189
虽然针对需求是如何变更的没有说具体的流程，配置管理是怎么管理的，但是觉得文章只是给出一个大题的思路非常好。
（转）需求变更管理