引言

随着我国金融行业的不断发展，金融软件产品越来越多，软件开发规模也越来越大。目前我国金融系统的应用软件多数为自身的软件开发部门单独开发，或与外部厂商合作开发，少量软件是直接购买成熟的商业软件产品。

如何提高软件开发的效率和质量已成为金融软件开发的核心问题。需求管理是关系到金融产品质量的关键，软件需求质量的好坏直接关系到软件产品的开发质量和生命力。

1、需求管理的重要性

需求管理是通过调查与分析，获取用户需求并定义产品需求，在业务部门与开发部门之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。在软件系统开发过程中，

有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改系统真实需求而产生的。开发软件系统最困难的部分就是准确说明开发什么，最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其他软件系统的接口。

软件项目需求管理，贯穿软件项目开发的全过程，它是处在软件开发链的中心地位，在计划、设计、实施、验收、投产跟踪各个阶段，都与需求管理有关。

需求管理的原则：

①需求一定要分类管理；

②需求必须分优先级；

③需求必须文档化；

④需求一旦发生变化，就必须对需求变更的影响进行评估；

⑤需求管理必须与需求工程的其他活动紧密整合。

2、面临的主要问题

在金融软件产品的开发中，业务部门是产品的需求提出者和最终用户，软件开发部门是产品的开发者和维护者。目前大多数国内银行，都是各个业务部门直接对口软件开发小组，在金融软件的开发实践中，

需求管理中常常存在许多问题，这些问题来自业务部门和开发部门两个方面。

2.1 来自业务部门的问题

（1） 需求不明确。业务部门在需求描述中，使用的往往是业务语言，技术人员常常由于无法准确理解这些业务做法和要求，导致对需求产生理解上的歧义，给　开发造成失误。

还有一种较为常见的情况，业务部门对所要设计的处理系统只能提出一个大概的需求，具体要包括哪些业务处理功能自己也说不清楚，这样的需求更是无法实现。

（2）需求缺乏远见。一方面，业务部门对自己的业务缺乏研究，不了解该项业务当前的发展状况、发展趋势以及观经济形势的变化，甚至不了解下属使用部门的各种业务变化和业务扩展，因而提出的需求缺乏前瞻性和普遍性；

另一方面，业务部门对关联业务的变化缺乏了解，因而关联业务的变化导致业务需求不断变化，这主要是由于相关部门缺乏必要的交流造成的。以上两种情况还产生另外一个问题：业务部门提出的多个业务需求缺乏综合考虑，据此开发的各个应用系统彼此缺乏关联，

导致业务处理系统数量繁多，缺乏整体综合性，这在业务系统整合时弊病暴露无遗。

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

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

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

2.2 来自开发部门的问题

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

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

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

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

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

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

3、解决的办法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4、结语

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

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