无论用多长时间来分析需求，总感觉需求没有完备

　　无论如何研讨，已有的需求总感觉不能百分之百明确

　　至项目开发后期，业务部门和技术部门往往就需求产生纠纷，一般有两种形式：

　　1) 技术部门认为频繁的需求变更不但增加项目压力，更使已有开发工作浪费

　　2) 业务部门认为软件系统不能跟进，影响业务发展

　　造成上述传统需求分析方法困境的原因主要有两点：

　　1) 在项目进行的过程中，业务需求本身也在发展变化，从而引发软件需求变化。

　　2) 业务人员不可能凭空把所有需求都想清楚，只有看到、用到真实的软件之后，才能逐渐把自己的需求弄清楚。

　　虽然一次性需求存在诸多问题，但现实中，技术部门和业务部门往往都希望能在这个阶段将所有问题想清楚。促使团队这样做的深层原因在于：

　　1) 从管理的角度考虑，软件项目需要申请预算

　　2) 从软件开发的角度考虑，需求的每一次变更都需要长的时间和巨大的成本来应对，这是技术部门和业务部门双方都不愿看到的。为了避免项目中进行可能的风险，双方都宁可在项目初期尽量把需求冻结。

　　第一个原因与项目计划方式有关;第二个原因与其说是对策，不如说是对传统开发方法缺陷的妥协：对企业级应用系统来说，早期需求冻结不仅是无法做到，而且还会带来一项隐性的浪费——这种项目开发出来后，可能有20~30%的功能从上线开始，已经不再需要;10~20%的功能的生命周期不超过半年，即费用和人力有相当一部分投入到无用的功能开发中。

　　业务部门和开发团队依赖文档进行沟通的后果往往是理解出现偏差，开发出的系统的不能满足业务部门的真正需求，造成浪费。