随着我国金融电子化建设的深入，金融软件产品越来越多，软件开发规模越来越大。如何提高软件开发的效率和质量已成为金融软件开发的核心问题。笔者认为：需求管理是关系到金融软件产品质量的关键，对业务发展具有深远影响。软件需求质量的好坏直接关系到软件产品的开发质量和生命力。

　　一、金融软件需求管理的内涵
　　软件工程理论认为，在软件生命周期中，需求分析（Requirements Analysis）是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的，高质量需求对软件开发往往起到事半功倍的效果，所谓“磨刀不误砍柴功”。在后续阶段改正需求分析阶段产生的错误将付出高昂的代价。为此，研究人员对需求分析的过程进行了长期深入的研究，并将需求分析逐渐发展成一个独立的分支——需求工程(Requirements Engineering)。主要内容有需求获取、需求分析、需求规约、需求验证和需求管理。其中需求获取是需求分析员与系统的最终用户一起工作以明确用户需要的过程，需求分析是提炼用户的需要和约束的过程，需求规约是清楚、准确地编写用户需要和约束文档的过程，需求验证是保证系统需求完整、正确、一致、明白的过程，需求管理是调度、协调需求工程活动，如获取、分析、规约及验证，并编制文档的整体过程。在实际工作中，伴随着需求的改进，需求工程的各阶段有时是交织在一起的，其最终结果是产生需求分析文档——《软件需求规格说明书》，相当于最终用户和开发机构之间的技术合同书。它既是开发者开发软件系统的依据，也是最终用户验收软件系统的依据。
　　金融电子化建设的核心是金融软件的开发和使用，而最终目的是使用，它是银行电子化建设的重中之重。目前我国金融系统的应用软件多为自身的软件开发部门单独或与外部机构合作开发，只有少量软件是直接购买的商业软件产品。不论哪种情况，对需求管理都是最为重要的内容。
　　金融软件的开发过程是由应用部门根据业务需要提出需求，开发部门按照需求进行开发，最终由应用部门进行验收并投入使用。具体过程如图：
 
　　1.应用部门提交《业务需求书》；
　　2.开发部门同应用部门的相关人员一起对《业务需求书》进行分析，并以某种模型(如数据流图)表示出来，形成《软件需求规格说明书》；
　　3.双方主管领导代表本部门对《软件需求规格说明书》签字确认。开发部门依据《软件需求规格说明书》开发相应的业务处理系统并提交给应用部门；
　　4.开发部门根据应用部门后续提交的业务需求变更，及时进行分析。分析结果经双方认可并签字后作为原《软件需求规格说明书》的附件，并由开发人员对软件进行调整；
　　5.应用部门对软件产品进行验收，合格后投入使用。
　　上述过程中1是需求获取，2实际上是将需求分析、需求规约、需求验证结合在一起进行。《业务需求书》相当于应用部门给开发部门提交的一份任务书，不能作为最终的开发依据。原因在于：《业务需求书》是对业务处理的描述，其内容经常是模糊的、不准确的，很多细节往往没有给出，特别是一些经验性的、常识性的要求常常被忽略，性能上的要求有时也无法实现。《软件需求规格说明书》是双方人员共同对《业务需求书》进行深入理解、详细分析并完善之后，采用形式化的模型描述的，其中增加了《业务需求书》中缺乏的细节，排除了《业务需求书》中错误的、模糊的内容，合理安排《业务需求书》的各项性能指标，以完整清晰的方式对要开发的业务处理系统进行全面描述，是开发的最终依据。
在整个过程中，应用部门和开发部门作为互相配合的双方，各有不同的分工。双方的密切配合和良好交流是产生高质量业务需求、获得优秀软件产品的重要保证。

　　二、金融软件需求管理的一般原则
　　为做好金融软件的开发和管理，要特别重视软件需求管理，金融软件需求的管理要符合需求工程的一般要求。
　　1.对需求的约束
　　软件需求直接关系到软件产品的质量。一个好的软件需求应具有如下特性：
　　完整性：要从全局出发，不能单纯从本业务考虑问题。一方面要完整地反映该项业务，另一方面还要全面反映本项业务同其它关联业务的联系。 
　　准确性：准确无误，无二义，各项要求、业务做法、每种处理的详细流程、数据等方面的要求等明确定义，不能摸棱两可、含糊不清。
　　通用性：业务需求要具有较广泛的适应性，要能够适应大部分分支机构、适应大部分业务处理情况，减少以后各分支机构对系统的修改要求。
　　前瞻性：业务需求要具有前瞻性，要能够反映该项业务当前的发展状况（包括同业情况）和发展趋势。系统要留有可扩充的余地。
　　稳定性：一定时限内相对稳定、不变。
　　权威性：业务需求要具有权威性，能被普遍接受，并具有很强的约束力。
　　可行性：需求在技术实现和经济负担上要符合实际，切实可行。
　　安全性：金融业在社会经济生活中的特殊性对金融软件的安全性提出了较高的要求，从需求的提出就应充分考虑软件的安全性问题，要有专门负责安全生产或稽核的人员全程参与需求管理及软件开发。
　　在金融软件开发的实践中，业务需求要全面符合上述要求比较困难。一般由应用部门综合考虑各点有求，并有所侧重。但是，为了保证软件产品的质量，还是应该尽量满足各项要求。 
　　2.对需求管理的约束
　　金融软件的需求管理是一个综合性的过程，应做到以下几点：
　　负责制：应用部门和开发部门都应实行，两个部门都要有专门的机构负责从本部门的角度进行需求管理，由专人负责，有专门的部门领导负责协调，并对需求中出现的各种问题和错误负责。需求管理涉及后续各个方面，直接关系到软件产品的最终质量，因此必须强化需求负责制，确保需求及其变更始终处于良好的管理之下。
　　规范化：规范化是现代管理工作的基本要求。强调规范化管理，可以避免非程序性、随意性等多方面问题。金融软件需求管理同样应遵循科学规范的原则。在需求管理中，对需求的获取、需求分析、需求分析的描述（《软件需求规格说明书》及其它文档）、需求的变更等需求管理的各方面制定相应的管理规范，并在工作中加以完善，坚持执行。
严肃性与灵活性：业务需求的提出及变更是一件严肃的事情。需求管理的目标之一，就是减少需求的变动，维护需求的相对稳定性。需求的每一处变动，都会对后续的开发工作产生影响，甚至导致某些工作推倒重来。因此必须维护需求的严肃性，不允许随意变更需求的内容。如确有必要，应经过变更需求的管理程序。对于业务上某些不影响原则问题的细节调整，开发部门可以根据开发工作的实际情况，在符合需求的大框架内予以满足，并将变更的内容及时归档记录，作为《软件需求规格说明书》的附件，从而在需求管理上体现出一定的灵活性。

　　三、金融软件需求管理的组织保证
　　1.建立需求管理机制
　　建立专门的软件需求管理负责部门，对需求的提出、业务需求内容的编写、审核、需求分析、相关部门的协调、文档的管理等进行统一管理。 
　　2.加强部门之间的交流
　　为获取高质量的业务需求，加强应用部门与开发部门之间以及应用部门相互之间的的交流是关键。应用部门提出某项业务需求时，应同时考虑到与其他部门业务处理上的联系，使提出的需求更加全面。另外，还必须增加稽核部门对软件需求及系统开发的参与。
　　3.加大对业务的研究
　　好的需求应具有前瞻性。应用部门应建立业务研究机制，督促有关部门对业务发展状况、同业情况、相关业务的发展趋势、国际国内宏观经济环境的变化对该业务可能带来的影响、本机构的长远发展规划等诸多方面进行研究，从而保证需求具有一定的先进性，在一定时期内可以很好地满足业务的发展。
　　4.实行需求专人负责制
应用部门和开发部门应指定专人负责业务需求管理、协调等具体事宜，并承担相应的责任。

　　四、目前金融软件需求管理中的问题
　　在金融软件产品的开发中，应用部门是产品的需求提出者和最终用户，开发部门是产品的提供者和维护者。他们的分工不同，但需从不同方面、相互配合完成需求管理。需求管理是软件开发周期中最费时的阶段，而需求分析中又常常存在许多问题，主要有：
　　1.来自应用部门的问题
　　需求不明确：在需求描述中，应用部门使用的往往是业务语言，经常根据撰写人对业务处理的理解，用日常说法加以描述。这种描述常常省略了一些经验性、常识性的内容，相关的背景内容（如法律、法规等外部约束）也大都不加说明，缺乏计算机处理所需要的很多细节。业务人员可以处理，但计算机却无法处理，这样的需求是不明确的。技术人员也常常由于无法准确理解这些业务做法和要求，导致对需求产生理解上的歧义，给开发造成失误。另外，应用部门有时对所要的处理系统只能提出一个笼统的需求，具体包括哪些业务处理功能自己也说不清楚，这样的需求根本无法实现。
　　需求缺乏远见：这是需求管理中另一个常见的问题。一般包括两个方面：(1)应用部门对自己的业务缺乏研究，不了解该业务当前的发展状况和发展趋势以及宏观经济形势的变化，甚至也不了解下属使用部门的各种业务变化和业务扩展，因而提出的需求缺乏前瞻性和通用性，甚至有些根本就是错误的做法，只能在很短的时期内满足使用，常常是开发部门还在按照《软件需求规格说明书》开发时，就不断有新的需求变更提交过来。有时产品使用不久就要大动手术。导致开发部门无法按照既定的进度工作，经常调整程序甚至返工，严重影响进度，加大了开发人员的工作压力，也影响了产品质量。(2) 应用部门对关联业务的变化缺乏了解，因而关联业务的变化导致业务需求不断变化。这主要是由于同相关部门缺乏必要的交流造成的。以上两种情况还产生另外一个问题：应用部门提出的多个业务需求缺乏综合考虑，各自为战，据此开发的各个应用系统彼此缺乏关联，导致业务处理系统数量繁多，缺乏综合性。这在业务系统整合时弊病暴露无遗，是我国早期金融电子化建设的最大通病。 
　　需求缺乏权威性和严肃性：需求管理是很严肃的事情，好的需求会产生优秀的业务软件，不好的需求则相反，这方面实际例子很多。仔细分析经常变动的软件系统就可以证明。在金融软件开发中，随意变更需求是比较普遍的现象。例如，经过双方签字认可的需求，可能由于某个人的要求而改变，也可能出现几个人要求按各自的意见变动的情况；也可能出现由于人员的变化引起思路变化，从而要求需求加以变化的情况；还可能发生在不同的分支机构要做不同的变动的情况。虽然有些变动是必需的，但在提交需求前缺乏全面的、权威的审核认定是其中的重要原因，从而给软件产品的开发、维护带来严重问题。 
　　需求可行性不强：金融软件的应用是为业务的持续发展和拓展服务的，但由于应用部门对金融软件开发中的技术特点了解不够，常常会在需求中提出一些不切实际的要求，以致无法实现，最终不得不修改需求。开发时间短、强度大是最常见的问题，即使开发人员加班加点，但有些需求还是无法在要求的时限内完成，单纯追求进度导致软件产品质量下降，为以后的使用造成隐患；有些指标、做法和其它要求或无法实现，或勉强可实现但实际上不适合计算机逻辑处理，或不符合上级机构的整体发展规划等，都给需求管理造成困难。金融软件的开发有其自身的规律，需求也必须遵循这些规律。
　　2.来自开发部门的问题
　　对需求理解不准确：这是一个常见问题。经过需求分析之后产生的《软件需求规格说明书》是软件产品开发的依据，也是应用部门最后验收的依据。原则上说，《软件需求规格说明书》是开发者和用户之间的一份事实上的技术合同。然而，由于以下几方面的原因，开发人员对《软件需求规格说明书》理解不准确，使得软件开发过程中和交付使用之后不断出现用户不期望出现的问题，软件产品不能准确地按用户的期望工作。这些原因主要有：(1) 对《软件需求规格说明书》理解不深，特别是其中的一些业务处理方法和处理原则理解不深、不准确，对涉及到的有关政策规定等背景知识了解很少。因此，对《软件需求规格说明书》的一些要求理解有偏，没有同业务人员取得事实上一致的理解；(2) 由于开发部门人员变动，后加入的人员由于时间紧和知识背景的限制，有时无论是对需求的整体还是对需求的各部分之间的有机联系都缺乏清楚深入的理解，因此不能准确地实现业务需求；(3) 开发人员对具体业务做法不了解，在开发过程中按自己的理解去做，导致出现偏差。上述问题产生的结果是：(1) 导致开发工作返工，影响开发的进度；(2) 交付用户的软件产品存在错误，不能很好地按用户期望的方式工作。
　　不严格按需求开发，自以为是：开发部门是服务和技术支持部门，金融软件产品的开发必须符合用户的需要，而不能以自己对系统的理解代替用户的要求。分不清自己的职责，按自己的理解而不是业务上的理解去做，是缺乏服务意识的表现。业务人员和技术人员由于知识背景各异，长期受到的训练不同，有很多差别。这些差别表现在：由于金融业务处理本身比较简单，业务人员在描述问题时常常根据当前的实际做法简略描述，许多细节被忽略，一些常识性的、经验性的知识隐含于其中。事实上，业务人员在日常处理上也正是这样做的，处理起来很灵活。技术人员处理问题则往往很“较真”，必须把每一个细节都清楚无误地描述出来，在实际开发中，个别开发人员可能对业务需求中的一些提法和做法不愿接受，觉得从技术角度看，换一种处理方式可能更合理、更简单。因此，有时个别开发人员可能会在某些处理中按自己的“更为合理”的理解去做。这种问题的出现，表现了个别技术人员还没有树立真正的服务观念，缺乏对业务人员的尊重和理解，缺乏同业务人员的深入交流。其结果是开发的产品不符合业务需求，软件产品不完全符合客户实际需要。
　　不坚持原则，根据个别人的要求变动需求：业务需求是一个处理业务的全面约定，对需求的确认和修改是严肃的事情，不能随意变动需求。在金融软件开发的实践中，开发人员有时不能坚持这项原则，对业务人员的一些个别要求不经过管理程序就随意答应。这其中的深层原因在于，技术人员没有树立工程化的思想，没有软件工程和需求管理的观念。同时，也缺乏对业务需求严肃性的认识。结果是，最终提交的产品不符合《软件需求规格说明书》的要求，其中的变动部分有时连需求提出者和相关管理部门也不掌握。
　　3.缺乏稽核部门的介入
我国金融电子化建设中一个普遍的问题就是缺乏稽核人员的参与，直到目前也仍然存在。往往是系统已经投产使用了，稽核部门才知道有这么一个系统，对系统的整体了解、功能实现、安全机制、内控原则、具体操作的了解都非常滞后，因而对系统的一些安全点、隐患、漏洞也就难以发现，更不用说提出对系统改进的合理化建议了。笔者认为稽核应从软件需求开始就全程介入整个软件开发过程，包括系统验收、投产和后续管理。

　　结束语
　　金融软件的需求管理是关系到金融软件产品质量的关键，对业务发展具有深远影响。它是整个开发项目中最重要的工作，需要应用部门和开发部门密切配合，并按需求工程的要求和开发工作的规律进行。良好的需求管理会减少开发工作中不必要的调整，保证开发工作的顺利进行和最终投入使用，从而降低开发成本。