为什么会出现这个问题，我想首先的问题就是，客户的需求是解决其业务问题，从大的方面来说假设分成1－2－3－4，这个一般没有问题，如果出了问题客户也能够同意进行调整。而做需求分析的时候除了业务问题以外，最主要加入进来的确实操作习惯，那么我们可以大致这样来进行划分：
决策层（花钱的）：我们遇到这样几个问题，需要解决，花多少钱
管理层（操作层的上级）：为了解决这个问题，我们应该分成这些步骤，并且还有哪些问题
操作层（用户）：要做这个事情，我希望********
在签合同的时候，我们往往会做到第一层和第二层，并且第一层应该弄的比较清楚，第二层往往是开发商带一些猜测，而客户的管理层也不重视，认为反正后面还有需求分析呢。这就埋下了祸根，而操作层一般是完全不会涉及的。时间、成本等也不允许进行涉及。
等到需求分析的时候，我们要从决策层开始，分析其需要解决的问题，进入到管理层，由于每个企业都存在管理层意见不太统一的情况，因此如何把持住成了一个很难的问题，进入操作层以后，我们就会迷失在巨大的操作需求中。
另外，客户往往有一种我已经花钱了，所以什么你都的替我解决。又给你增加了一大堆不在决策层考虑的范围之内的事情，操作层有的时候也会给你一大堆的难题进行解决。如果碰上客户之见有一些矛盾，你就会更加痛苦。
再次，软件开发商的一些现场人员，对项目的目标（决策层的要求）把握不准，不能通过合适的沟通方法将客户领导的意图不断的强化到管理层和操作层，导致理解偏差。
第四，软件开发商的现场人员不能有效的、清晰的表达出合同范围和需求范围变化的情况、趋势，这些被淹没在大量的、繁琐的文档之内。到需求分析结束的时候，又急于开展进一步的工作，导致双方都匆忙确认。
这几个问题是非常严重的。我不想都展开讲解决方案，只讲2个方面情况，1，从行业发展的角度讲，如有可能应该鼓励客户将需求与实施分开成两个项目，独立完成。这需要行业人士的不断呼吁，客户的认识提高等。
第二个方面，只涉及如何使客户和开发商都对项目的范围有非常清晰的认识并且在需求分析过程中进行强化、比对。开发商必须要建立2个工具，一是决策层提出的问题，要精炼好，制作成宣传标语贴在进行需求分析的会议室或者随时带着，作为检验我们是否脱离目标的工具，随时使用。二是开发商一定要在开始进行需求分析时，制作好项目的合同WBS，并且获得客户的认可，以此为基础进行需求分析与调研。保证不偏离WBS，如果发生偏离，随时进行检讨与纠正。在需求分析结束以后，制作新的项目的WBS，二者进行比较分析，将其对工作量、工期、成本、质量等的影响与客户交代清楚，并达成一致以后，方进行后续的工作。
由于我们的需求工程师天生就喜欢将事情做的完美，因此自己也会加入一些范围外的东西，并且他们不太在意对项目的影响，有时候会在现场对客户进行一些承诺，导致项目范围扩大。因此每个企业都必须对需求工程师做出资质的要求，进行培训，并考核合同工作量与需求工作量的变化，并且明确告诉需求工程师，他没有获得有关授权，不能对客户进行承诺。以此来约束需求工程师。
当然我们应该针对上面所讲的问题，拟定相应的解决方案，这里就不一一探讨，先谈谈上面这一点。
