项目纷争的原因很多，有逾期不能完工的、有质量达不到指标的、由甲方不能提供有效支持的、有项目成果不符合实际需求的等等。从结果上讲，主要是因为其中一方认为项目目标不能达到导致的，当然，由于自身的技术和管理上的原因导致目标不能达到，这部分纷争比较容易沟通、判定和解决，而比较容易引起纷争却又棘手的往往是由于项目目标理解上不一致导致的。软件项目的主要目标中进度和成本指标一般都有明确的定义，分歧较少，而对于范围和质量目标弹性较大，不易界定，如果合同签订时，这些指标标定义模糊不清、主观性较强、为以后的项目实施埋下隐忧。
因此，在项目实施之初，做好需求分析是减少软件项目纷争的首要前提。因为只有准确理解并完整描述甲方的需求目标，双方达成共识，才不至于发生矛盾纷争。但是，在实际操作中要真正做到需求分析全面与描述准确并非易事，因需求分析受以下几方面的影响：
1、 需求提出的局限性。
一般代表甲方提出需求是技术部门的负责人，大部分对整个企业或其它业务领域并不熟练，这样造成需求不清，特别是涉及整个组织运作的集成系统，由于负责人职位问题，很少能够熟知全局业务运作，所提出的需求的完整性因人而异。况且，有些业主持有甲方的“霸主”态度，总说以后不行再改、再加，或者要求加上“一些有关的功能”等模糊意义的需求。这样导致需求分析者未能全面准确的掌握需求源泉。
2、 需求描述的复杂性。
需求的完整描述不仅面面俱到，内部的关联性很强，错综复杂。所以需求描述很花费人力和时间的，一个稍大一点的软件项目需求描述就上百页，并且需求描述粒度会因客户的要求而不同，粒度小的需求描述就更多。
3、 需求审查的随意性。
甲方面对如此繁杂的需求分析与描述举行的需求评审会，专家和由各个业务客户往往因为会议组织安排问题和时间仓促问题而流于形式，并不能对需求描述作深入细致的分析。
4、 需求分析的时间性。
不管是甲方还是乙方的上层，都希望项目能够真刀真枪的干起来，而不想在这样“纸上谈兵”的需求方面花费太多的时间。一些资深专家普遍认为，需求分析阶段的时间应不少于整个项目阶段的20-30%，但迫于各种现实情况匆匆走过场的大有人在。
文章来源于领测软件测试网 https://www.ltesting.net/
