需求工程的质量评价准则

需求工程的质量评价准则摘要: 需求工程是软件系统开发生命周期的初始阶段,其最终结果是得到关于用户需求的准确、全面、形式化的需求描述。

虽然人们已经认识到需求工程的质量是整个系统开发的关键,但是目前尚没有确定统一的质量评价体系。

从需求工程的基本活动内容出发,结合案例研究和软件开发经验,定义了需求工程质量评价的七项准则,并给出了质量因素的评价方法。

关键词: 需求工程; 质量评价; 系统开发Criteria for Evaluating the Quality of Requirements EngineeringAbstract : Requirements Engineering is the initial stage in the software development life cycle ,whose final product is the precise , complete , formal document about the users’needs. 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 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 author’s software development experiences through the basic activities of Requirements Engineering.Key words : Requirements Engineering(RE) ; Quality Evaluation ; System Development1 引言需求工程是随着计算机的发展而发展的,在计算机发展的初期,软件规模不大,软件开发所关注的是代码编写,需求分析很少受到重视。

后来软件开发引入了生命周期的概念,需求分析成为其第一阶段。

随着软件系统规模的不断扩大,需求分析与定义在整个软件开发与维护过程中越来越重要,它直接关系到软件开发的成功与否。

人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段,它贯穿于系统开发的整个生命周期。

20 世纪80 年代中期,形成了软件工程的子领域———需求工程(Requirements Engineering ,RE) 。

近年来, 需求工程已成为国际上研究的热点领域之一。

需求工程的主要工作是将用户的非形式化的软件需求变为形式化的需求规范(Requirements Specification)的过程。

软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

通过对应用问题及其环境的理解与分析,为问题涉及的信息、功能及系统行为建立模型,将用户需求精确化、标准化,最终形成需求规范的说明书,这一系列的活动内容即构成了软件需求工程。

它是介于系统分析和软件设计阶段之间的桥梁。

一方面,需求工程以系统规格说明和项目规划作为分析活动的基本出发点,并从软件角度对它们进行检查与调整;另一方面,需求规格说明又是软件设计、实现、测试直至维护的主要基础。

所以,良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。

需求工程是整个软件系统开发过程的第一阶段,其质量将直接影响整个系统开发的成败。

据统计,软件项目开发中59 %以上的错误归结为需求工程产生的后果,而且越是在软件开发的后期发现问题,越要花更大的代价去修改和维护系统。

比较典型的问题是欠准确的事实数据、遗漏、不一致、描述模糊等等,而这类问题是可以通过早期的质量检查发现并改进的。

但是,目前需求工程质量的评价体系还不够完善,这给需求工程的过程管理带来许多困难,所以有必要对需求工程质量评价问题做深入地研究。

2 需求工程的内容需求工程是一个综合的系统工程,在需求工程的初始阶段,对系统的理解是模糊的、非规范的,有时甚至是错误的,因为参与需求工程的人员在能力和知识方面会有差异,每个人都有自己的理解。

需求工程要做的工作就是不断规范用户需求的过程,通过与用户交流、了解用户的业务流程等一系列活动形成需求规范,并对用户不断变化的需求演进给予支持。

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程,并最终在验证的基础上完成需求规范。

整个需求工程的活动内容可划分为三个阶段:获取、规范和验证,如图1 所示。

图1 需求工程的结构组成(1) 获取(Elicitation) 是整个需求工程的第一阶段,通过与用户的交流,对现有系统的观察及对任务进行分析,从而获得相关的用户信息,为形成软件需求规范奠定基础。

它要求系统的需求分析员在做形式化描述之前,充分理解问题域的边界及其特征,然后建立该问题的概念模型。

这一阶段的主要任务包括:●鉴别所有的信息源;●获取用户的需求信息;●确定已获得的数据信息与待解决的问题之间的联系;●理解已获取的知识的重要性及其对软件需求的影响。

要完成这些任务,必须正确运用需求获取技术,准确地捕获用户的各种需求。

最典型的方法是同用户面谈,利用原型法真实地反映现实世界。

最近,又出现了知识复用技术,尽量利用在相似问题域中已获得的知识,从而减少需求获取的工作量。

(2) 规范(Specification) 是需求工程的第二阶段,其目的有两点: ①对用户需求做形式化表示,形成一个需求规范或叫需求模型(RE Model) ,作为用户与开发者之间的协议; ②需求模型将作为软件开发的“蓝图”,开发人员以此为基础进行软件的设计与实现,任何开发人员都不能随意更改。

需求规范阶段的主要工作包括:需求信息的分析和处理、知识的合成与组织,其最终结果是形成一个逻辑化的、精确的需求规范,即需求模型。

(3) 验证(Validation) 阶段,即检查需求模型是否满足用户的要求。

它通常以需求模型为输入,通过符号执行、模拟或快速原型等途径,分析需求模型的正确性和可行性,对于错误的需求规范必须返回其前一阶段进行修改,或者进行更详细地系统需求分析,获取更多的需求资料,从而完善需求模型。

验证主要进行两方面的工作:●准备实验环境和数据;●进行实验并分析实验结果。

从表面上看,获取、规范和验证三个阶段是串行的。

实际上,验证阶段可以被视为与获取和规范阶段同步进行,其目的是要保证在需求工程的所有活动中始终保持问题处理的正确性。

假如在获取阶段发现错误,则必须及时解决,才能进入到下一步———规范阶段,否则将来会花费更大的代价去维护需求模型。

因此,验证不仅仅是检验需求的正确性,更重要的是发现需求模型中的所有问题并及时修改。

有些需求工程研究人员不把验证作为一个独立的阶段,原因也在于此。

不管怎样,我们还是把验证同其它需求活动区分开,因为无论是在需求工程理论还是在实际系统开发中,验证都是相当重要的一个环节。

总之,需求工程的三个阶段是互相关联的,缺一不可。

规范是需求工程活动的核心,它控制需求获取和验证。

一方面,在形成需求规范时,若需要更多的知识将会触发获取处理;另一方面,问题域的任何变化都可能引起需求规范的变化,这必然导致获取工作的重新进行。

然而,对于相同的问题形成的需求模型可能多种多样,它们对其后进行的系统设计与实现会产生不同的影响。

那么哪种模型更好呢? 换句话说,如何评价其质量呢? 这将是本文研究的核心问题。

3 质量评价准则需求工程的主要目标是开发者与用户就系统需求达成共识,生成需求模型。

在需求工程的过程管理中,迫切需要一套科学的质量度量标准来保证需求工程的质量最优,但由于需求分析的方法很多,如实体2联系法、数据流图法、面向对象方法等,目前尚没有统一的定量标准。

笔者拟结合软件开发经验和对需求工程的案例研究,给出质量评价的一般准则及其质量因素的评价方法,使需求工程的过程管理科学化。

3．1正确性正确性是指建立的需求模型应符合所用建模技术的规则。

例如,在实体2联系法中,应使用标准的E2R 图画法,定义属性的数据类型、长度及取值范围,每个实体定义一个主键。

一方面,正确性要保证系统中的所有元素(如E2R 图中的实体、联系、属性) 被完全地定义,若不完全就会在后续阶段中出现问题,导致开发者进行猜测或重新做用户调查;另一方面,正确性要保证需求模型无冗余,因为冗余会导致存储空间浪费,容易造成数据的不一致性,给编程和维护工作带来困难。

总之,正确性检查属于技术问题,它并不能说明需求模型是否完全表达了用户需求。

评价正确性时,可以按照建模规则去检查,或使用软件工具(如CASE) 自动检查。

当然,也可以请其他不参与该项目的同行校对,发现错误及时更正。

3．2 完全性完全性是指需求模型中是否包含了用户所需的所有功能,这是最基本的要求,若不能满足,其它任何质量问题都无从谈起。

因为需求分析的不完全,即使后面的设计与实现再好,也不能满足用户的要求。

并且,在系统开发后期增加或更改用户需求,将会成倍地增加开发代价。

因此,完全性评价是需求工程质量的关键。

改进需求分析的完全性将有助于提高软件开发的生产率,但评价完全性问题却很难。

因为用户有时不能完全表达其所有需求,开发者又没有预见,致使软件完成后才发现,维护代价相当大。

为了及时发现问题,开发者最好跟班作业,对用户的业务进行深入地了解,从而对需求模型的完全性作出评价。

具体评价方法可采用用户审阅、样例分析、业务规则验证、进程映像等方法。

3．3简单性简单性是指需求模型中的构件数要尽可能少,或者说其复杂度要低。

举一个简单的例子,若有两个需求模型可描述同一问题域,则按照简单性准则选用构件数较少者。

因此,构件数可以作为模型简单性的一个测度。

较简单的需求模型将使开发者更易于理解,系统也会更容易实现。

但是,不同的系统分析方法,形成的需求模型的构造不同,这给需求模型的复杂度分析带来一定困难。

在E2R 图分析法中,构件数可以认为是实体数和联系数的总和;而在面向对象方法中,可以采用Chi2damber和Kemerer 提出的WMC (Weighted Methods perClass) 的值来度量。

但是需求模型的复杂度,仍然是待研究的主要问题之一。

3．4适应性适应性可以看作需求模型与用户的独立性,即当用户需求发生变化时,需求模型可以不做修改或只进行微小调整。