传统需求分析面临的困境

传统需求分析一般以名为“需求规格说明书”（Requirement Specification）的文档为目标，以固定时长（根据项目规模而定，一般2、3周或者更长）为约束，以完成需求文档为结束。 那么传统需求分析究竟面临那些困境呢？中培教育《需求分析于管理最佳实践》培训专家王老师在这里进行了介绍。

王老师指出，经历过传统需求分析过程的分析师和开发人员都会有类似的感觉：

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

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

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

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

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

王老师指出，造成上述传统需求分析方法困境的原因主要有两点：

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

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

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

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

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

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

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