论金融软件的项目需求管理

1、论金融软件的项目需求管理    关键词:需求管理 过程 原则 1 金融软件需求管理的概念 软件工程理论认为,在软件生命周期中需求分析(RequirementsAnalysis)是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的,高质量需求对软件开发往往起到事半功倍的效果,在后续阶段改正需求分析阶段产生的错误将付出高昂的代价。 需求分析的过程,是分析用户的需求的过程,是全面理解用户的各项要求,并且准确地表达所接受的用户需求的过程。如果投入了大量的人力、物力、财力和时间开发出来的软件并不是用户真正需要的东西,那么所有投入都是徒劳,开发出

2、来的东西不能得到用户的认可,从而造成重新开发,这样不仅影响项目进度,而且严重影响项目组人员的积极性。 需求管理是调度、协调需求工程活动,如获取、分析、规约及验证,并编制文档的整体过程。在实际工作中,伴随着需求的改进,需求工程的各阶段有时是交织在一起的,其最终结果是产生需求分析文档软件需求规格说明书,相当于最终用户和开发机构之间的技术合同书。它既是开发者开发软件系统的依据,也是最终用户验收软件系统的依据。 2 需求管理过程 2.1 需求统一入口 金融软件项目有很多应用,而每个应用实施是相对独立、同步的。如此一来,就难以整体把握需求,洞悉相互关联。集中一点归集,实现需求统一入口,归集各种渠道而来的

3、需求,并结合优先级、需求明确粒度等抽取规则,确立需要进入下一环节的需求。 2.2 需求分类 按业务范围可分为资产负债管理、客户关系管理、财务绩效管理、风险管理和监管合规管理五大类;按支持方式可以分为系统应用支持和业务条线/部门两大类;按工程实现方式可以分为接口、报表和完整业务应用实施三类需求。 2.3 需求分解 不同的需求分类对应着不同的管理方法,而管理方法的基础则是进行需求分解,需求分解的好坏将决定需求管理的效果。需求分解的益处包括以下几点:便于对需求点进行全程跟踪,包含业务定义、数据分析、数据校验、设计、开发、测试及各阶段问题、计划的执行情况、迭代管理等;有利于实现内部协作的共享与监督管理

4、;以需求细化为基础,能对不断优化的需求及需求变更进行规范管理;有助于指标、报表甚至功能的复用。 需求分解的方法和粒度因需求类型的不同而有差异。接口类需求按照接口表与字段两个维度进行分解;报表类需求以报表指标为粒度进行分解,分解时需先结合指标维度进行最细层拆分,再根据维度的共通性、实现的难易、取数的规则等进行适当的合并;综合类需求则需要对具体功能模块不断进行分解,分解的合理性与需求分析的规范性是分不开的,目前综合类的需求以需求分析文档为主,结合需求管理工具进行管理。 2.4 需求分析 需求分解后就可以进行需求分析工作,在分析中关注的是如何使分析的过程更为有序、高效和严谨。 2.5 需求确认 需求

5、分析完成后就需要进行需求确认,即由需求提出方对需求进行评审和确认,是项目转入实施阶段的关键。 2.6 需求基线与变更管理 在需求获取确认后,需求即被打上一条基线。被基线化的需求可以是一个应用的完整需求,也可以是部分需求。基线化后,需求的变化即纳入变更管理。一个新的需求变更会重新循环到需求统一入口这一环节。 需求变更是软件开发人员最为头疼的事情,但不得不承认,软件的需求变更必然存在。外部环境改变、业务规则变化、人员更迭、沟通不畅等,都是需求发生改变的诱因。随着优化需求的不断增加、数据与功能的复用和整合日渐增多,需求变更会逐渐成为需求管理的一个重点。需求变更需从影响性分析和变更评估开始,直到变更完

6、成,也需要经过一个完整的过程管理。需求变更管理也是保障需求与最终产品一致性的关键环节。 2.7 需求跟踪管理 需求基线化工作的结束标志着开发实施阶段的开始,在实施过程中,由于沟通、人员、能力、知识等各种原因,会发生各阶段产品与需求的偏差,为使需求在各环节的流转保持一致和可回溯,就需要进行对需求的跟踪管理,通过需求与设计、设计与开发、需求与测试之间的需求跟踪矩阵进行持续的跟踪管理,发现问题及时沟通并反馈,以保障需求没有遗漏、没有重复、没有偏差地传递到最终产品。对数据仓库的应用需求而言,跟踪矩阵大多是以数据的流转过程和数据间的关系为核心进行体现。 3 金融软件需求管理的一般原则 为做好金融软件的开

7、发和管理,要特别重视软件需求管理,金融软件需求的管理要符合需求工程的一般要求。 3.1 对需求的约束 软件需求直接关系到软件产品的质量。一个好的软件需求应具有如下特性: 完整性:要从全局出发,不能单纯从本业务考虑问题。一方面要完整地反映该项业务,另一方面还要全面反映本项业务同其它关联业务的联系。        准确性:准确无误,无二义,各项要求、业务做法、每种处理的详细流程、数据等方面的要求等明确定义,不能摸棱两可、含糊不清。 通用性:业务需求要具有较广泛的适应性,要能够适应大部分分支机构、适应大部分业务处理情况,

8、减少以后各分支机构对系统的修改要求。 前瞻性:业务需求要具有前瞻性,要能够反映该项业务当前的发展状况(包括同业情况)和发展趋势。系统要留有可扩充的余地。 稳定性:一定时限内相对稳定、不变。 权威性:业务需求要具有权威性,能被普遍接受,并具有很强的约束力。 可行性:需求在技术实现和经济负担上要符合实际,切实可行。 安全性:金融业在社会经济生活中的特殊性对金融软件的安全性提出了较高的要求,从需求的提出就应充分考虑软件的安全性问题,要有专门负责安全生产或稽核的人员全程参与需求管理及软件开发。 在金融软件开发的实践中,业务需求要全面符合上述要求比较困难。一般由应用部门综合考虑各点有求,并有所侧重。但是

9、,为了保证软件产品的质量,还是应该尽量满足各项要求。 3.2 对需求管理的约束 金融软件的需求管理是一个综合性的过程,应做到以下几点: 负责制:应用部门和开发部门都应实行,两个部门都要有专门的机构负责从本部门的角度进行需求管理,由专人负责,有专门的部门领导负责协调,并对需求中出现的各种问题和错误负责。需求管理涉及后续各个方面,直接关系到软件产品的最终质量,因此必须强化需求负责制,确保需求及其变更始终处于良好的管理之下。 规范化:规范化是现代管理工作的基本要求。强调规范化管理,可以避免非程序性、随意性等多方面问题。金融软件需求管理同样应遵循科学规范的原则。在需求管理中,对需求的获取、需求分析、需求分析的描述(软件需求规格说明书及其它文档)、需求的变更等需求管理的各方面制定相应的管理规范,并在工作中加以完善,坚持执行。 严肃性与灵活性:业务需求的提出及变更是一件严肃的事情。需求管理的目标之一,就是减少需求的变动,维护需求的相对稳定性。需求的每一处变动,都会对后续的开发工作产生影响,甚至导致某些工作推倒重来。因此必须维护需求的严肃性,不允许随意变更需求的内容。如确有必要,应经过变更需求的管理程序。对于业务上某些不影响原则问题的细节调整,开发部门可以根据开发工作的实际情况,在符合需求的大框架内予以满足,并将变更的内容及时归档记录,作为软件需求规格说明书的附件,从而在需求管理上