当与业务人员的争议不可避免时，项目经理一定要坚持原则。如果遇到争议不下的问题，可以提交双方部门领导进行裁决。

　　（1）业务培训。由于金融领域的业务知识专业性非常强，因此完全有必要在项目初期，聘请既懂技术又懂业务的专家，组织开发人员进行有针对性的业务知识培训，避免出现因不熟悉业务知识，而导致需求理解上的失误。

　　（2）需求调研。需求调研有几种方式，常见的有需求讨论会和跟班作业。跟班作业是有效的方式，但消耗资源较多，且受项目成本和项目时间的约束，很少有项目采用。召开需求讨论会，是需求调研的常见做法。

　　会前应做好充分的准备，起草需求调查问题表，将调查重点锁定在该问题表内，否则讨论将会变得漫无边际。在讨论会上要耐心聆听，同时要善于提问，并且要主导讨论内容，否则将无法保证讨论进度。问题表可以有多份，随着调查的深入，问题表将不断地被细化。

　　根据经验，业务人员通常没有耐心回答复杂的论述题，所以问题表应当以选择题、是非题和简答题为主。

　　（3） 需求评审。在需求整理完毕形成文档以后，开发人员好把自己总结的需求，向业务人员比较详细地讲解一遍。这种做法不仅能够大大减少技术人员与业务人员在业务层面的歧义，还可以及时准确地发现潜在的问题。

　　开发部门和业务部门共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有一定的约束力。即便因为业务变化，不得不对项目需求进行大的调整，以至于项目延期，那也不是开发部门的原因，甚至可以以此为依据来拒绝不必要的需求变更。

　　而对于业务人员来说，通过审查这些详细的需求内容，对将要设计的系统也能做到心里有数，消除不必要的疑虑。签字确认后的需求文档可以作为今后产品交付的依据，对双方具有同等的约束力。据统计，需求设计阶段的评审，发现缺陷的有效性，高达到75%，比测试有效20倍以上。

　　（4） 加强需求跟踪。将系统设计、编码、测试等阶段的工作成果（如设计文档、代码、测试用例等）与需求文档进行比较，建立与维护“需求文档?设计文档?代码?测试用例”之间的一致性，确保软件依据需求文档开发。

　　（5） 需求变更控制。需求的变化问题是每个开发人员、每个项目经理都经常遇到的，一旦发生了需求变化，不得不修改设计、重写代码、修改测试用例、调整项目计划等，还必须对需求变更的影响进行评估。的办法是使需求在受控的状态下发生变化，

　　而不是随意变化，依据“需求变更申请???审批需求变更申请???更改需求文档???重新进行需求确认”的流程处理需求的变更，确保需求变更不会失去控制而导致项目发生混乱，每一个小的变化都要严格按照变更管理流程来管理。

　　4、结语

　　需求是软件设计及实现的基础，对于整个软件项目来说至关重要。软件项目需求管理是对需求的获取、组织及记录过程进行的管理，是软件开发成败的关键性因素。为了使软件开发能顺利完成，必须重视需求管理工作，舍得投入一定的人力、物力，

　　采用先进的方法和科学的手段来保证软件开发工作的进行。