银行信息系统需求分析的指导原则及实践

随着计算机软件服务手段的日益丰富以及银行业不断加快向以客户服务为中心转型的进程，银行信息系统的建设从最初的简单报表、简单记账等若干个小系统到现在几十个甚至上百个系统投入运行服务。系统需求的复杂度使得在信息系统的建设过程中特别是用户验收测试过程中或多或少会出现一些现象：业务人员认为系统功能不能满足最初的要求，从而使得系统建设出现延期、妥协后的变形、最终用户抱怨等一系列的不良后果。虽然出现这些现象的原因是多方面的，但是深层次的原因其实是需求分析不清晰、不到位。

        现在业界存在很多流行的需求分析方法以及相应的软件过程、软件项目管理理论及实践，但是大部分人的观点或者流于普适形式或者偏重理论领域，不能完全适合银行信息系统的建设实践。笔者认为银行信息系统的需求分析是以若干指导原则为基准、以结构良好的需求文档为核心的以达成开发者与使用者共识的实践过程。

一、需求分析指导原则

        1.需求分析文档化
        需求分析是一个开发者与使用者达成共识的过程。在这个过程中，不可避免地会发生业务人员与开发人员的变更，而不同的业务或开发人员知识领域、业务水平、操作习惯都不尽相同，为避免人员的变更引发业务理解的偏差而导致银行的信息系统建设走弯路，就必须做好需求文档，以便业务人员与开发人员对业务的理解有根有据。同时银行系统大都不是孤立的系统，会和其他系统进行信息交互，此时也有必要使用需求文档记录双方约定的功能与责任。

        2.需求分析文档偏技术化的语言
        银行业务人员特别是与开发人员讨论需求的业务人员大都是银行业务骨干，经验比较丰富，并且很长时间一直在使用各种银行软件系统，可能还经历过各种业务系统的各种版本，对于银行信息系统的界面元素、操作习惯基本已经一清二楚，反观开发人员则一般比较年轻，缺少银行业务知识，并且也缺乏必要的沟通技巧，所以在需求讨论过程以及需求文档的编制过程中可以采用稍偏技术化的语言以增进讨论的效率及效果。同时也要防止业务人员过度介入，因为业务人员虽然已经能够以偏技术化的思维描述需求了，但还是不能从系统整体上充分理解软件的内涵，往往会出现业务人员直接要求开发人员实现某个具体到开发阶段的需求，这可能会影响开发人员的开发工作。

        3.需求分析要有足够的人员及时间
        需求分析的一个重要特点是不能出现“模棱两可”的需求，开发者与使用者对要开发实现的产品应达成明确的的共识。这似乎很简单，但是因为种种原因，两者达成明确共识并没有想象中那么容易，常常出现需求不足、需求过多等诸多问题，进而影响整个项目的后续开发。这就要求需求讨论要有足够的时间，足够的人员参与，相关人员要进行充分有效地沟通，准确清楚地用语言和文字进行需求表达，最后共同完成高质量的需求分析。

        4.以功能需求为主要讨论对象
        需求分析应主要面向功能性需求。需求分析包括功能性需求分析与非功能性需求分析，虽然非功能性需求分析做得不充分会影响整个系统建设进度，但是从实践效果来看，每个系统的非功能性需求大致都一样，比如安全性要求（部分安全性要求需要功能性需求支持）、可靠性、可修改性、可维护性、性能要求（主要依靠数据库应用优化）等，每个系统针对非功能性需求的解决方案也基本比较成熟，采用的技术框架、模型也应有一定的理论支持，而功能性需求的差异是明显的，因为每个系统都面向不同的业务流程，可以说每个系统都基本完全不同，所以需求分析应把主要精力放在功能性需求分析上面。

        5.采用界面原型法
        在需求讨论前期，用户的界面需求大都很模糊，甚至没有自己的理想模型，用户提出的要求也很难量化。而利用界面原型，用户可以感性地认识到未来系统的界面风格以及操作方式，从而迅速判断系统是否符合自己的期望，是否满足自己的操作习惯，是否能够满足自己工作的需要。因此应用界面原型法来讨论用户界面需求，可以将需求调查的周期尽量缩短，并尽可能满足用户的要求，还可以帮助用户尽快完善自己的理想模型，进而减少系统开发的风险。界面原型的最终版本，有的可以原封不动地被开发继承，有的略加修改就可以成为最终系统的一个组成部分，这样也有利于缩短系统建设周期。特别是在大型项目的开发中，由于对项目需求的分析难以一次完成，应用界面原型法效果更为明显。

        6.重视数据字典的建设
        从需求分析时就应着手建设数据字典。数据字典从狭义上看是“对系统用到的所有数据项和数据结构的定义，以确保开发人员使用统一的数据定义”。现在我们把数据字典的理解扩展到需求阶段：数据字典定义为在需求分析过程中业务人员与开发人员达成共识的数据项与数据结构定义。好的数据字典可以消除语言的二义性和不一致性，在需求分析过程中我们有相同或者相近的数据项，在不同的使用范围内有着相同或者相近的含义，这在开发时容易造成开发人员的困惑，以至于引起数据混乱甚至丢失的情况，比如“属性”、“性质”、“类型”、“状态”、“分类”等含义模糊的词语，有时候这种模糊是致命的。这就要求我们在需求分析开始的时候就做好数据字典的建设，使得数据项的定义原子化，数据结构的定义对象化，并且全局唯一，如果采用中文无法清晰地表示数据含义，可以使用英文单词进行辅助定义以示区分。

 1 2 3 下一页 尾页

扫码即可手机
阅读转发此文