一份事实上的技术合同。
然而，由于以下几方面的原因，开发人员对《软件需求规格说明书》理解不准确，使得软件开发过程中和交付使用之后不断出现用户不期望出现的问题，软件产品不能准确地按用户的期望工作。
（2） 不严格按需求开发，自以为是。业务人员和技术人员由于知识背景各异，长期受到的训练不同，有很多差别。业务人员在描述问题时常常根据当前的实际做法简略描述，许多细节被忽略。
在实际开发中，个别开发人员可能对业务需求中的一些提法和做法不愿接受，觉得从技术角度看，换一种处理方式可能更合理、更简单。因此，有时个别开发人员可能会在某些处理中按自己“更为合理”的理解去做，其结果是开发的产品不符合业务需求。
（3）不坚持原则，根据个别人的要求变动需求。业务需求是一个业务处理的全面约定，对需求的确认和修改是严肃的事情，不能随意变动需求。在金融软件开发实践中，开发人员有时不能坚持这项原则，对业务人员的一些个别要求不经过管理程序就随意答应。
结果是，最终提交的产品不符合《软件需求规格说明书》的要求，其中变动部分有时连需求提出者和相关管理部门也不掌握。
3、解决的办法
多换位思考，注意沟通的技巧
需求的复杂性是固有的，是无法避免的。每个人的知识都是有限的，所以不要苛求业务人员对IT技术非常精通，交流时尽量使用通俗用语而不是IT术语。在规定时间内，用有限的资源来保质保量地完成项目，让业务部门满意是开发部门的职责。
开发部门应当想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。在与业务人员的沟通中，应当更多地从业务人员的角度考虑问题，应当尽量避免正面冲突，耐心倾听意见，多问一问“您还有什么想法？”，
等业务人员把他的想法都表述清楚以后，开发人员可以迅速评估一下他们的建议，如果实现起来太困难，可以给业务人员一些更加中肯的提议，多用“您看这样行不行？”、“这样也可以达到同样的目的”之类的语言。
当业务人员提出需求变更时，可以站在业务人员的角度来说明需求对整个项目的重要性，比如对项目进度的影响、对系统架构的影响、对系统稳定性的影响以及对系统用户的操作习惯的影响等。
当与业务人员的争议不可避免时，项目经理一定要坚持原则。如果遇到争议不下的问题，可以提交双方部门领导进行裁决。
（1）业务培训。由于金融领域的业务知识专业性非常强，因此完全有必要在项目初期，聘请既懂技术又懂业务的专家，组织开发人员进行有针对性的业务知识培训，避免出现因不熟悉业务知识，而导致需求理解上的失误。
（2）需求调研。需求调研有几种方式，常见的有需求讨论会和跟班作业。跟班作业是最有效的方式，但消耗资源较多，且受项目成本和项目时间的约束，很少有项目采用。召开需求讨论会，是需求调研的常见做法。
会前应做好充分的准备，起草需求调查问题表，将调查重点锁定在该问题表内，否则讨论将会变得漫无边际。在讨论会上要耐心聆听，同时要善于提问，并且要主导讨论内容，否则将无法保证讨论进度。问题表可以有多份，随着调查的深入，问题表将不断地被细化。
根据经验，业务人员通常没有耐心回答复杂的论述题，所以问题表应当以选择题、是非题和简答题为主。
（3） 需求评审。在需求整理完毕形成文档以后，开发人员最好把自己总结的需求，向业务人员比较详细地讲解一遍。这种做法不仅能够大大减少技术人员与业务人员在业务层面的歧义，还可以及时准确地发现潜在的问题。
开发部门和业务部门共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有一定的约束力。即便因为业务变化，不得不对项目需求进行大的调整，以