（3）需求缺乏权威性和严肃性。需求管理是一件严肃的事情，好的需求会产生的业务处理软件，不好的需求效果则相反。在金融软件开发中，随意变更需求是比较普遍的现象，虽然有些变动确属必要，但在提交需求之前缺乏全面、权威的审核认定则是其中的重要原因，

　　从而导致需求的经常变动，难以管理，给软件产品的开发、维护带来了严重问题。

　　（4）需求可行性不强。金融软件的应用是为业务的持续发展和拓展服务的，应该满足业务需求。但是，由于业务部门对金融软件开发中的技术特点了解不够，常常会在需求中提出一些不切实际的要求，以致无法实现，终不得不修改需求。

　　2.2 来自开发部门的问题

　　（1） 对需求理解不准确。经过需求分析之后产生的《软件需求规格说明书》是软件产品开发的依据，也是业务部门后验收的依据。原则上说，《软件需求规格说明书》是开发者和用户之间的一份事实上的技术合同。

　　然而，由于以下几方面的原因，开发人员对《软件需求规格说明书》理解不准确，使得软件开发过程中和交付使用之后不断出现用户不期望出现的问题，软件产品不能准确地按用户的期望工作。

　　（2） 不严格按需求开发，自以为是。业务人员和技术人员由于知识背景各异，长期受到的训练不同，有很多差别。业务人员在描述问题时常常根据当前的实际做法简略描述，许多细节被忽略。

　　在实际开发中，个别开发人员可能对业务需求中的一些提法和做法不愿接受，觉得从技术角度看，换一种处理方式可能更合理、更简单。因此，有时个别开发人员可能会在某些处理中按自己“更为合理”的理解去做，其结果是开发的产品不符合业务需求。

　　（3）不坚持原则，根据个别人的要求变动需求。业务需求是一个业务处理的全面约定，对需求的确认和修改是严肃的事情，不能随意变动需求。在金融软件开发实践中，开发人员有时不能坚持这项原则，对业务人员的一些个别要求不经过管理程序随意答应。

　　结果是，终提交的产品不符合《软件需求规格说明书》的要求，其中变动部分有时连需求提出者和相关管理部门也不掌握。

　　3、解决的办法

　　多换位思考，注意沟通的技巧

　　需求的复杂性是固有的，是无法避免的。每个人的知识都是有限的，所以不要苛求业务人员对IT技术非常精通，交流时尽量使用通俗用语而不是IT术语。在规定时间内，用有限的资源来保质保量地完成项目，让业务部门满意是开发部门的职责。

　　开发部门应当想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。在与业务人员的沟通中，应当更多地从业务人员的角度考虑问题，应当尽量避免正面冲突，耐心倾听意见，多问一问“您还有什么想法？”，

　　等业务人员把他的想法都表述清楚以后，开发人员可以迅速评估一下他们的建议，如果实现起来太困难，可以给业务人员一些更加中肯的提议，多用“您看这样行不行？”、“这样也可以达到同样的目的”之类的语言。

　　当业务人员提出需求变更时，可以站在业务人员的角度来说明需求对整个项目的重要性，比如对项目进度的影响、对系统架构的影响、对系统稳定性的影响以及对系统用户的操作习惯的影响等。