标准管理系统非功能性需求分析

2014年6月第40卷总第179期2014年第3期SichuanBuildingMaterialsDOl：10.3969/j.issn.1672-4011.2014.03.137标准管理系统非功能性需求分析李响(辽宁省标准化研究院,辽宁沈阳110004)作者简介:李响(1981-)，女，辽宁铁岭人，硕士研究生，高级工程师，主要从事标准化工业与消费品研究工作。摘要:根据标准管理系统业务背景的特点，结合研究院实际情况，对标准管理的非功能性需求从五方面进行了详细的阐述，并分析了日常标准管理工作的的非功能性需求。关键词:标准管理系统;易用性;稳定性;可维护性;可扩展性;安全性中图分类号:TB497文献标志码:B文章编号:1672-4011(2014)03-0328-020前言辽宁省标准化研究院对标准管理系统的需求,分为功能性需求与非功能性需求,本文根据标准管理系统业务背景的特点,结合研究院实际情况,对标准管理的非功能性需求从五方面进行了详细的阐述。1易用性需求易用性是以用户为中心,结合视觉、交互、情感等综合感受,使软件更简易、高效地适应用户的使用需求和习惯。应用系统建设过程中,建设人员认为系统已涵盖了业务需求,功能比较齐全,也尽可能的采用了先进成熟技术,进行了界面原型设计并经用户反复确认,并且通过了性能测试、系统测试及用户接受测试。在系统上线后,终端用户时常感觉系统视觉效果差、不易理解、不好用、不易于操作,但因强制使用要求,用户只能被动接受。分析其原因,主要是需求规格说明书中对易用性要求不易衡量、新系统使用改变了原有工作习惯、用户心理预期与实际系统不同造成的心理落差等客观原因,但从系统建设角度看,还是项目建设人员对易理解性、易学习性和易操作性分析不够,系统易用性设计不足。目前,企业管理软件作为一项产品已经发展成熟,其功能足以完成大多数商业任务,而且越来越专注于行业。然而,对用户而言,大部分企业软件依然复杂而且不容易使用。根据之前对英国和美国300位资深IT人士进行的一次调查显示,只有大约64％的人正在使用其企业应用系统的核心功能。约一半的人表示他们不需要所有功能,而五分之一的人则解释说这些功能没有用起来的原因是他们根本没时间去学习如何用。部分企业组件在易用性方面有很大的障碍,这些结构性障碍包括。1)供应商将其收购的多个产品集成到一个组件中,迫使用户必须学习多种不同的界面和架构,缺乏统一性。2)模块在组件各部分之间不能实现信息的顺畅流动(例如从采购到财务)。3)应用程序非常连贯性,或者供应商的业务模式无法支持客户拥有集成的企业应用程序搜索工具。4)复杂的架构难以帮助系统拥有更加用户友好的界面。这可能是当前部分供应商面临的最大问题,因为如果不支持全面开发的面向服务的架构(SOA),则仅仅为优化用户界面的目的,软件供应商就可能有必要对其应用程序重新进行全面开发。供应商可能会通过销售额外产品来解决易用性的问题,例如在销售应用程序时搭售搜索工具。但这些工具不仅会带来更高的许可成本,而且会产生繁重的集成工作从而保证功能的实现。由于难以承受高额费用,只有少量客户会去使用这些技术,因而也失去了其本身的市场效应。软件系统的功能现在已经非常商品化,而未来将不同供应商和产品区分高下的根本因素将是功能是否易懂,以及其在客户组织内是否易于普及使用。企业应用系统的用户正变得越来越习惯使用那些基于Web的,高度简化且功能非常强大的应用程序,并希望自己的企业系统也具备同样的界面和使用方式。公司的首席信息官(CIO)希望他们能够像在网上冲浪一样轻松浏览、了解自己的企业情况。伴随商业环境愈加复杂,软件必须进一步简化。在中型市场中,只有那些能够精简其应用程序,具备良好易用性的软件供应商才可以存活。以上就是本系统的易用性需求,需要充分考虑用户的实际情况和具体感受。2稳定性需求客户提出的需求多种多样,在软件使用过程中,由于业务的变化及对软件的熟悉程度,原来的一些功能可能满足不了客户的需要,迫使客户提出很多易用性或完善性的需求,这些需求处理不好就成为软件稳定性的一种隐患。国内很多ERP产品在有些功能上是完全相同的,就连思路也是大同小异,很少有创新的东西,一家出来后,不出一年,另一家也会出来,产品更新换代非常快。由于图一时之利,产品不稳定也就在所难免。项目是任何软件公司赖以生存的根本,现在国内大部分的软件企业都是做项目起家,根据项目逐渐提炼,最终形成产品,所以说产品的很大一部分改动源于项目,只要项目上有需求,都要想办法解决,这也是很多软件企业的宗旨。但这种现象也造成了不可估计的损失,产品越改需求越多,越改越乱、越改越不稳定,不仅导致项目周期拖延,还对产品造成致命的冲击,最终越陷越深。软件厂商分析设计方面。搭建系统架构在此阶段完成,包括需求规格说明书、详细规格说明书、企业管理等文档的编写。在软件企业里一般分析设计人员由资深的软件开发人员兼任,但往往这部分人跟客户交流的机会少,缺少·823·2014年6月第40卷总第179期2014年第3期SichuanBuildingMaterials一线项目经验,设计出的软件也是参考了很多竞争对手的资料或实施、售前人员反馈的需求及平常自己的一些经验而来,在开发阶段可能问题不大,但在客户使用后,进入维护阶段就经不起考验了,使用一段时间后,最终可能要推倒重来。软件厂商开发方面。开发阶段最常见的问题是没有设计文档就写程序,等程序写完后再补设计文档,这样往往造成代码冗余,严重者往往会推倒重来,做无用功。所以开发阶段能否按照分析设计阶段编写的文档严格执行很关键,能否理解设计者的思路也很重要,这个阶段的工作直接会影响到产品的发版及以后的维护工作。另外此阶段的单元测试也很重要,不愿测自己写的程序也是开发人员的通病。综上所述,本系统应尽量避免上述问题的发生,这样开发出来的标准管理系统才具有良好的稳定性。在开发复杂系统时,尽可能地将组件或者服务单独实现,以便隔离相对独立自系统。这点很重要,化整为零的策略不但使系统功能解耦合,而且整个系统越发容易开发、调试、测试,因而也越发稳定。比如BerkeleryDB机制等都是独立的子系统,完全独立于整个系统;另外Linux的打印服务程序也被分开成几个独立的自任务,这种隔离必然提高了整个服务程序的稳定性,因为减少了突发或者恶意交互,提高了系统容错性。错误的定位和隔离都大大优于单模块程序。3可维护性需求所谓软件的可维护性其实说简单了就是软件代码可被修改的容易程度。代码反复修改的情况不可避免,这种软件的不断演化过程———具体就是修正错误;适应新环境;满足新需求———虽然将软件的功能变得越发强大,但是事实上这些改变总是或多或少地有悖于当初的设计初衷,因此势必慢慢的蚕食软件的基础架构和代码质量———造成的结果是让代码越来越难看懂,健壮性越来越脆弱,修改一个bug的代价越来越大。鉴于这个矛盾,MartinFowler提出的代码重构主要就是从代码编写角度出发,提高代码的维护性,以便能更好适应软件演化。对于耦合问题,无论是过程语言程序,或者是面向对象程序。模块之间(类或文件)或包之间(对过程语言没有包的概念,可将某个功能集合放在一个文件夹下,如linux内核各种子目录,将其类比成包)的关系是依赖与被依赖。比如工具包(math,pthread,std容器等)一般都不依赖其他包,而且设计抽象,这些包属于稳定包,不能经常改动,因为细微的改动就可能会影响依赖其所有组件。而处于接近用户的模块或包则多依赖于稳定包,它们不被其他模块或包所依赖,这些包可以被经常被改动且影响不会扩散。尽量不要循环依赖或者相互依赖。相互依赖的危害性很大,任何一个包改变都会引起连锁反应。因此依赖应该是单向的。另外从模块接口设计角度讲,引用外部方法时,可将外部方法作为变量传入本函数作用域,再加以使用。这样做可以降低模块代码间的耦合性,有利于软件的后期维护。综上所述,本系统的可维护性需求是高内聚,低耦合。4可扩展性需求可扩展性是软件系统本身的属性,或者进一步说是设计的属性、代码的属性,因为我们经常说设计的可扩展性、代码的可扩展性。那与之相对应的是什么呢?是变化,软件环境的变化(可能是业务环境,运行环境)导致软件要进行改动才能满足新的需求,这种系统本身适应变化的能力就是可扩展性。当需求改变或者增加新需求的时候,可能会修改多个类文件,可能还涉及配置文件,前台页面文件。这种改动,肯定要引起重新编译和部署,肯定是需要停机的。这种改动涉及的面积广,需要预先经过很细致的分析,改完之后需要面积很大的回归测试以保证修改不会引入新的问题。程序的模型越是抽象,越要求可扩展性。客户在需求描述的初始阶段往往对自己的业务模型并不熟悉。他们对自己的需求很难抽象出一个精确的模型来,这使得他们只能给出一个模糊的抽象的业务模型。拙劣的程序员往往将用户给的模糊模型根据自己的理解后,定义出一个自己认为准确和精确的模型。在软件开发完成后,客户就会往往发现这不是其所要,或只是其中情况的一种,于是不断地增加功能。程序设计的时候由于模型抽象层次不高,造成的灵活性和可扩展性比较差,这时程序员就要重新开发软件。因此,一个好的程序员不仅仅是写一段美观高效的代码,更重要是要有出众的设计能力。良好的设计能给现实带来很好的可扩展性。高级的程序员首先应该是一个高级的程序设计师,这样的程序员不仅要有良好的需求分析能力,还要有高超的模式设计能力。在获知抽象的业务模型后,如何设计程序使其具有高度的灵活性和可扩展性是每个程序员都关心的问题。让一个程序具有可扩展性的方法不外乎以下几种方式：1)程序级别的可扩展性,主要通过参数化配置程序低级别的可扩展性。2)高度可配置性,包括各种属性文件和XML配置文件。3)脚本。脚本是扩展复杂功能的利器,但对客户的要求也比较高。通常应该是面向开发人员的工具产品或在产品部署之前由现场实施人员来完成。4)插件系统或模块化平台。插件系统平台从理论上提供了无数的可扩展性。在获知辽宁省标准化研究院的标准管理业务模型的基础上,再考虑上述的一般软件的扩展性需求,就是本系统的可扩展性需求。5安全性需求安全已经成为管理软件不能回避的重大问题。相对于一般的管理软件,标准管理系统对安全性的要求更高。网络中的应用系统面临的风险多种多样,因此要充分考虑各种安全机制的结合,引入防火墙、入侵检测、漏洞扫描、信息加密以及数据备份等安全技术,确保系统的安全运行、数据的安全保密。6结语综上所述,标准管理系统依据上述易用性、稳定性、可维护性、可扩展性、安全性五项非功能性需求开发,势必能更好的满足用户需求,加强软件的实用度,大大提高使用者的工作效率。[ID：001168]·923·标准管理系统非功能性需求分析作者：李响作者单位：辽宁省标准化研究院,辽宁沈阳,110004刊名：四川建材英文刊名：SichuanBuildingMaterials年，卷(期)：2014(3)被引用次数：1次引用本文格式：李响标准管理系统非功能性需求分析[期刊论文]-四川建材2014(3)