1、           需求确认

需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。

在需求调研的过程中，我发现对项目范围的定义和当初了解的存在误差，这也是很正常的，因为未签订合同前，谁也不能做很深入的调研，只能了解个大概要求。但我们的原则是不轻易更改工作范围，只是在原来的框架内做一些小的调整。 而且每次和客户讨论之后，我们都写一份会议纪要，请客户签字确认。但即便如此，对需求的确认也是一件很让人头痛的事情。如何划定边界？做到什么程度就可以了？因为只有提供需求的人才能确定是否真正获取需求，我们都尽量请客户参与讨论并更正。

需求评审会议非常重要，但是以前几个项目的评审会都开得不很理想，大家事先不认真阅读文档，会上乱哄哄的，你说一句，我问一句，往往花费了很多时间，却啥结论也没有。这一次，我吸取了教训，组织了一个非常正规的需求评审会议，将部门领导、公司的业务专家、技术骨干都请来当评审人员。并自行设计了《评审准备表》和《评审记录表》。会前两天提前发了老挝项目的需求文档《老挝TAIS项目方案建议书》、《老挝TAIS项目调研报告》，发放了《评审准备表》，让大家提前将问题记录在评审准备表中，并反馈给我，我一直等到反馈意见收集的差不多了，才召开评审会。评审会开的很成功，效率很高。我让人整理了评审发现的问题，放在了评审记录表中，方便下去追踪。

我使用的评审准备表和记录表如下：

2、           需求变更控制

需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。

    需求变更难以避免，重要的是不能没有章法得变，要遵循一个标准的变更控制程序，使得变化有序起来。

如果不进行变更控制，那么，项目就不能得到及时的警告，常常会因为进度超期、预算超支而陷入泥潭，成为“烂尾”工程。但是变更实在太频繁，如果每次变更都走变更流程，也会大大影响项目进展。按照变更控制流程，需要对变更做影响分析等等。如下所示：

既然变更在所难免，不可能只要有变更就执行严格的变更控制程序，这个过程也是有成本的，所以，和项目组成员讨论的结果，只有重大变更时，才执行变更控制程序。比如影响了项目里程碑的达到，工作量超出了原先估计的30%等等。这样一来，既保证了变更的有序性，又保证了项目进展。

除此之外，我还对需求的稳定度做了一个度量，度量了原始需求的个数，增加、删除、更改的需求个数；并分散在项目各个阶段，如需求分析、概要设计、详细设计、编码阶段、测试阶段等等的需求数，并将每次需求变更的提出人、变更原因，是否走了正式的变更流程都记录了下来。一来是为以后的项目做参考，二来跟客户沟通时也有话说。不至于拿不出令人说服的事实和根据来。

比如这个项目，初始的软件需求共有142个，中间增加了21个，删除了6个，更改了34个。总体需求稳定度在30%左右，对于一个软件项目来说，就很不错了。

老挝项目于2011年12月底结束，项目获得了老挝海关的好评,目前系统运行正常，系统已经融入老挝海关工作流程，成为海关工作不可分割的一部分。公司也收回了该项目所有尾款，实现了公司的价值。在此项目中，我们做到了一下几点：尽早开始需求调研，清晰进行需求定义，随时和客户进行沟通，及时记录需求变更，统计需求变更的影响和工作量。因此，项目进行得很成功，期间克服了很多困难，比如人手紧张，客户方接口人变动等等。但因为工作范围没有什么改变，需求一直在掌控之中，项目一直按计划执行和完成。