需求工程的质量评价准则

1、需求工程的质量评价准则摘要 : 需求工程是软件系统开发生命周期的初始阶段,其最终结果是得到关于用户需求的准确、全面、形式化的需求描述。虽然人们已经认识到需求工程的质量是整个系统开发的关键,但是目前尚没有确定统一的质量评价体系。从需求工程的基本活动内容出发,结合案例研究和软件开发经验 ,定义了需求工程质量评价的七项准则,并给出了质量因素的评价方法。关键词 : 需求工程 ; 质量评价 ; 系统开发Criteria for Evaluating the Quality of Requirements Engineering Abstract : Requirements Engineering is

2、 the initial stage in the software development life cycle ,whose final product is the precise , complete , formal document about the usersneeds. Although it is well known that the quality of RE is crucial for the success of the wholesystem development , the agreed systemfor evaluating the quality of

3、 RE has not been established. In this paper ,seven criteria are definedand methods for evaluating the quality factors are presented ,in the combination of case study and the authors software development experiences through the basic activities of Requirements Engineering.Key words : Requirements Eng

4、ineering(RE) ; Quality Evaluation ; System Development 1 引言需求工程是随着计算机的发展而发展的,在计算机发展的初期,软件规模不大,软件开发所关注的是代码编写 ,需求分析很少受到重视。后来软件开发引入了生命周期的概念,需求分析成为其第一阶段。随着软件系统规模的不断扩大,需求分析与定义在整个软件开发与维护过程中越来越重要,它直接关系到软件开发的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段,它贯穿于系统开发的整个生命周期。20 世纪 80 年代中期 ,形成了软件工程的子领域需求工程 (Requirements Engine

5、ering ,RE) 。近年来 , 需求工程已成为国际上研究的热点领域之一。需求工程的主要工作是将用户的非形式化的软件需求变为形式化的需求规范(Requirements Specification) 的过程。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应用问题及其环境的理解与分析,为问题涉及的信息、功能及系统行为建立模型,将用户需求精确化、标准化,最终形成需求规范的说明书,这一系列的活动内容即构成了软件需求工程。它是介于系统分析和软件设计阶段之间的桥梁。一方面,需求工程以系统规格说明和项目规划作为分析活动的基本出发点,并从软件角度对它们进行检查与调整;另一方面

6、 ,需求规格说明又是软件设计、实现、测试直至维护的主要基础。所以,良好的分析活动有助于避免或尽早剔除早期错误 ,从而提高软件生产率,降低开发成本,改进软件质量。需求工程是整个软件系统开发过程的第一阶段,其质量将直接影响整个系统开发的成败。据统计,软件项目开发中59 %以上的错误归结为需求工程产生的后果,而且越是在软件开发的后期发现问题,越要花更大的代价去修改和维护系统。比较典型的问题是欠准确的事实数据、遗漏、不一致、描述模糊等等,而这类问题是可以通过早期的质量检查发现并改进的。但是,目前需求工程质量的评价体系还不够完善,这给需求工程的过程管理带来许多困难,所以有必要对需求工程质量评价问题做深入

7、地研究。2 需求工程的内容需求工程是一个综合的系统工程,在需求工程的初始阶段,对系统的理解是模糊的、非规范的 ,有时甚至是错误的,因为参与需求工程的人员在能力和知识方面会有差异,每个人都有自己的理解。需求工程要做的工作就是不断规范用户需求的过程,通过与用户交流、了解用户的业务流程等一系列活动形成需求规范,并对用户不断变化的需求演进给予支持。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程,并最终在验证的基础上完成需求规范。整个需求工程的活动内容可划分为三个阶段:获取、规范和验证,如图 1 所示。图1 需求工程的结构组成(1) 获取 (Elicitation) 是整个需求工程的第一阶段

8、,通过与用户的交流,对现有系统的观察及对任务进行分析 ,从而获得相关的用户信息,为形成软件需求规范奠定基础。它要求系统的需求分析员在做形式化描述之前,充分理解问题域的边界及其特征,然后建立该问题的概念模型。这一阶段的主要任务包括 :鉴别所有的信息源; 获取用户的需求信息; 确定已获得的数据信息与待解决的问题之间的联系;理解已获取的知识的重要性及其对软件需求的影响。要完成这些任务,必须正确运用需求获取技术,准确地捕获用户的各种需求。最典型的方法是同用户面谈 ,利用原型法真实地反映现实世界。最近 ,又出现了知识复用技术,尽量利用在相似问题域中已获得的知识,从而减少需求获取的工作量。(2) 规范 (

9、Specification) 是需求工程的第二阶段,其目的有两点: 对用户需求做形式化表示,形成一个需求规范或叫需求模型(RE Model) , 作为用户与开发者之间的协议; 需求模型将作为软件开发的“蓝图”,开发人员以此为基础进行软件的设计与实现,任何开发人员都不能随意更改。需求规范阶段的主要工作包括:需求信息的分析和处理、知识的合成与组织,其最终结果是形成一个逻辑化的、精确的需求规范,即需求模型。(3) 验证 (Validation) 阶段 ,即检查需求模型是否满足用户的要求。它通常以需求模型为输入,通过符号执行、模拟或快速原型等途径,分析需求模型的正确性和可行性,对于错误的需求规范必须返

10、回其前一阶段进行修改,或者进行更详细地系统需求分析,获取更多的需求资料,从而完善需求模型。验证主要进行两方面的工作:准备实验环境和数据; 进行实验并分析实验结果。从表面上看 ,获取、规范和验证三个阶段是串行的。实际上,验证阶段可以被视为与获取和规范阶段同步进行 ,其目的是要保证在需求工程的所有活动中始终保持问题处理的正确性。假如在获取阶段发现错误,则必须及时解决,才能进入到下一步规范阶段,否则将来会花费更大的代价去维护需求模型。因此,验证不仅仅是检验需求的正确性,更重要的是发现需求模型中的所有问题并及时修改。有些需求工程研究人员不把验证作为一个独立的阶段,原因也在于此。不管怎样,我们还是把验证

11、同其它需求活动区分开,因为无论是在需求工程理论还是在实际系统开发中,验证都是相当重要的一个环节。总之,需求工程的三个阶段是互相关联的,缺一不可。规范是需求工程活动的核心 ,它控制需求获取和验证。一方面 ,在形成需求规范时,若需要更多的知识将会触发获取处理;另一方面 ,问题域的任何变化都可能引起需求规范的变化,这必然导致获取工作的重新进行。然而,对于相同的问题形成的需求模型可能多种多样,它们对其后进行的系统设计与实现会产生不同的影响。那么哪种模型更好呢? 换句话说 ,如何评价其质量呢? 这将是本文研究的核心问题。3 质量评价准则需求工程的主要目标是开发者与用户就系统需求达成共识,生成需求模型。在

12、需求工程的过程管理中 ,迫切需要一套科学的质量度量标准来保证需求工程的质量最优,但由于需求分析的方法很多,如实体 2联系法、数据流图法、面向对象方法等,目前尚没有统一的定量标准。笔者拟结合软件开发经验和对需求工程的案例研究,给出质量评价的一般准则及其质量因素的评价方法,使需求工程的过程管理科学化。31正确性正确性是指建立的需求模型应符合所用建模技术的规则。例如,在实体 2联系法中 ,应使用标准的E2R 图画法 ,定义属性的数据类型、长度及取值范围,每个实体定义一个主键。一方面 ,正确性要保证系统中的所有元素(如 E2R 图中的实体、联系、属性) 被完全地定义,若不完全就会在后续阶段中出现问题

13、,导致开发者进行猜测或重新做用户调查;另一方面 ,正确性要保证需求模型无冗余,因为冗余会导致存储空间浪费,容易造成数据的不一致性,给编程和维护工作带来困难。总之 ,正确性检查属于技术问题,它并不能说明需求模型是否完全表达了用户需求。评价正确性时,可以按照建模规则去检查,或使用软件工具(如 CASE) 自动检查。 当然 ,也可以请其他不参与该项目的同行校对,发现错误及时更正。32 完全性完全性是指需求模型中是否包含了用户所需的所有功能,这是最基本的要求,若不能满足 ,其它任何质量问题都无从谈起。因为需求分析的不完全,即使后面的设计与实现再好,也不能满足用户的要求。并且 ,在系统开发后期增加或更改

14、用户需求,将会成倍地增加开发代价。因此,完全性评价是需求工程质量的关键。改进需求分析的完全性将有助于提高软件开发的生产率,但评价完全性问题却很难。因为用户有时不能完全表达其所有需求,开发者又没有预见,致使软件完成后才发现,维护代价相当大。为了及时发现问题,开发者最好跟班作业,对用户的业务进行深入地了解,从而对需求模型的完全性作出评价。具体评价方法可采用用户审阅、样例分析、业务规则验证、进程映像等方法。33简单性简单性是指需求模型中的构件数要尽可能少,或者说其复杂度要低。举一个简单的例子,若有两个需求模型可描述同一问题域,则按照简单性准则选用构件数较少者。因此,构件数可以作为模型简单性的一个测度

15、。较简单的需求模型将使开发者更易于理解,系统也会更容易实现。但是,不同的系统分析方法,形成的需求模型的构造不同,这给需求模型的复杂度分析带来一定困难。在E2R 图分析法中 ,构件数可以认为是实体数和联系数的总和;而在面向对象方法中,可以采用 Chi2damber 和Kemerer 提出的 WMC (Weighted Methods perClass) 的值来度量。但是需求模型的复杂度,仍然是待研究的主要问题之一。34适应性适应性可以看作需求模型与用户的独立性,即当用户需求发生变化时,需求模型可以不做修改或只进行微小调整。适应性是需求工程质量评价的最关键因素之一,但在实际系统开发中往往不被重视。

16、很多需求分析人员就事论事,以完成系统的基本功能为目标,而忽略了其功能扩充或改变的可能性 ,这将会给系统维护造成困难。适应性评价要分析哪些需求将来可能改变、它们出现的可能性及其对需求模型的影响。由于系统未来可能发生的变化很难预测,所以适应性评价有一定困难。具体评价可采用如下几种方法: 高层管理者评审。因为适应性评价涉及组织发展的战略目标,一般的业务工作人员无能为力,只有高层决策者才能把握企业未来的发展方向。行业专家评审。这些行业专家应该是业务咨询或学术专家,他们能更好地把握企业的发展方向,能够对潜在的市场变化及其可能性作出预测分析。技术专家评审。有经验的需求分析专家可以基于系统结构对系统的适应性

17、作出评估,虽然他们并不一定熟悉企业的业务,但是可以从需求分析的技术角度评价系统的适应性。35集成性在一个大的企业信息系统开发中,通常包括多个应用子系统,这些子系统之间的数据一致性问题显得格外重要。集成性就是指某个应用子系统与企业信息系统中其它应用系统之间的数据一致性,以减少应用系统之间的数据冲突。由于在某些项目开发中,各应用子系统的需求分析是相对独立的,这就不可避免地造成数据重复、系统之间接口复杂等问题。要防止出现类似情况,应尽可能地重复利用已有的数据资源或者进行适当的扩充,以适应新系统的要求。其次,对数据项的定义要保持命名和格式上的一致。特别强调的是要用全局的观点看待数据,使需求模型具有通用

18、性。集成性的评价可采用如下几种方法:通过局部应用与全局应用模型的比较,发现数据冲突和结构冲突。将数据项向已有的数据源做映像,查看是否存在数据共享和重用的可能。让该应用系统以外的其它业务部门审阅,检查数据定义是否具有共性。36理解性顾名思义 ,理解性是指需求模型的结构和描述易于理解。只有通俗易懂,才能更好地同用户交流。如果用户很难理解需求分析结果,他们就不可能检验需求模型是否完全准确地表达了他们的需求内容。另外 ,应用开发人员对需求模型的理解也至关重要,因为他们负责系统的设计与实现,不充分理解系统的需求,会使软件系统的实现结果同用户要求出现偏差,造成软件生产率下降。评价理解性常可采用以下方法:用

19、户审阅。这是最常用的一种方法,检验需求模型的可理解性。但这种方法有一个缺点,用户可能只关心他们所熟悉的业务操作,而没有充分理解模型所表达的含义。样例分析。更有效的方法是让用户去使用这个模型,分析一个业务样例,来检验他们对模型的理解程度。应用开发人员审阅。虽然系统设计和编程人员不像需求分析人员那样熟悉用户的业务要求,但他们能有针对性地找出哪些地方描述得不清楚。同时,这一步也是应用开发人员认识需求模型的过程 ,有利于他们即将进行的设计工作,保证整个系统开发阶段的平稳过渡。37实现性实现性是指需求模型可以在规定的时间、经费预算和项目的技术约束下完成整个软件开发。这就要求我们在需求模型中不要出现这样或

20、那样的假设,不要忽略各种实际因素,特别是技术和经费,以免到开发后期追悔莫及。评价可实现性主要应用下面两种方法:应用开发人员审阅。他们会重点审查系统实现的一些潜在问题,从技术和经济角度分析系统实现的可行性 ,发现问题可及早修改。开发代价估计。这是对需求模型的实现性进行定量测量的方法,通常质量越好代价越大,降低代价就要牺牲质量。只有权衡两者的关系,才能使系统的可实现性达到最佳。总之 ,实现性是需求工程质量的最重要因素之一,实现可能性极小的需求模型,其它质量因素再好也无用。4 结论本文给出了七种质量评价准则,针对影响需求工程质量的主要因素论述了质量评价的主要方法。通过上述分析和实际的案例研究,发现这

21、些准则之间并不是相互独立的,而是相互关联、 相互制约。例如简单性 ,不仅有利于提高系统的适应性,而且易于实现,因为系统结构越复杂就越难以适应系统的改变 ,系统实现所需的代价也会越大。但从另一个角度说,适应性的提高反而会降低可实现性和可理解性 ,因为适应性较强的系统所要求的软件实现难度较高,而且由于通用的系统不如特定的用户系统那样,用户易于接受和理解。可见,如何准确把握这些评价准则的度,仍然是今后需求工程要研究的核心问题。参考文献 :1 S R Chidamber ,C F Kemerer. A Metrics Suite for Object Oriented Design J IEEE Transaction