需求工程分析方法

(一)概述

在系统开发的早期阶段,需求被定义成是一个关于应该实现什么的规格说明。它们是关于系统行为或系统特性和属性的描述,也可以是对系统开发过程的约束。系统需求往往分为功能性需求和非功能性需求。

在软件工程领域,需求工程是进行用户需求分析的理论和方法。需求工程是随着计算机的发展而发展的。在计算机发展的初期,软件规模不大,软件开发所关注的是代码编写,需求分析很少受到重视。后来软件开发引入了生命周期的概念,需求分析成为其第一阶段。随着软件系统规模的扩大,需求分析与定义在整个软件开发与维护过程中越来越重要,直接关系到软件的成功与否,需求分析活动不再仅限于软件开发的最初阶段,它贯穿于系统开发的整个生命周期。20世纪80年代中期,形成了软件工程的子领域——需求工程(requirement engineering,RE)。

需求工程是指应用已证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科;它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档。

1.Karl认为需求工程要分3个阶段来进行需求分析。

(1)信息获取阶段:信息获取阶段负责将信息从不同的用户角度不加选择地收集到一起。信息的收集过程通常采用采访交谈的方式,对被需求系统所涉及的客户对象进行采访。这种采访是开放式的,从管理者到一般的普通操作人员都能够表示他们自己的需求目标。但是在这样的过程中难免会有需求上的冲突和矛盾,需要召集不同类型和观点的人在一起讨论合适的解决方案,并最终就存在矛盾的需求问题达成一致的意见。通过信息获取阶段的工作,需求分析人员得到的应该是一个粗糙但目标明确的需求描述文档。

(2)需求建模阶段:需求建模的目的是通过对待开发软件系统预期实现目标的分析,识别出所有相关的概念和关系,建立需求模型。建立需求模型需要有一套完善的需求分析理论的支持。如统一建模语言(unified modeling language,UML)是一种为分析而向对象应用提出的理论模型,自动规约的知识获取(knowledge acquisition in automated specification,KAOS)方法是另一种以目标分析为核心的理论模型。

(3)需求报告产生阶段:基于完全的需求信息获取和有效的需求建模阶段的工作,设计者最终将提交出待开发软件系统的需求分析报告。这一报告重点在于分析系统的组件对象、领域约束和行为需求,以及从模型中抽取出的基本的领域概念字典和涉及的资源信息等。其中作为分析结果的需求模型必须是一致的,表示矛盾的同一概念或关系。同时整个需求的表达是明确的,不能包含模糊的二义表示。这就需要在需求建模过程中对于一些本质非离散的概念和关系采用严格的形式化方法将其明确地表示出来。需求报告在获得了委托人和开发方一致公认的前提下,将作为下一步设计开发的规范文件,并成为衡量设计是否达到需求要求的唯一标准。

2.Herb Krasner定义了需求工程的五阶段生命周期,这5个阶段是需求获取、需求分析、需求规格说明、需求验证和需求管理。

(1)需求获取:需求获取的过程就是通过需求调研,获得清晰、准确的需求。需求调研应尽可能做得全面细致,可以对即将要实现的业务有深刻的了解,帮助系统建设者更好地理解系统功能,同时在设计上也可以将系统做得更加灵活,提高系统的可扩充性。

(2)需求分析:需求分析的过程就是将收集到的调研信息加以处理并理解它们。把调研信息分成不同的类型,同时将用户需求同可能的系统需求相联系,然后将用户信息结构化,编写成文档和示意图,作为让用户代表评审并纠正存在错误的一个书面文档。重复详述需求,以确定用户目标和任务,并把它作为使用事例,进行深入收集和分析,消除任何冲突或不一致性,拟订出详细的使用事例,使其融合到必要的功能需求中,为编制测试用例做准备。进行需求分析时,尽量理解用户表达他们需求的思维过程,充分研究用户执行任务时做出决策的过程,并提取出潜在的逻辑关系。

(3)需求规格说明:需求分析的最终成果是形成一份经用户和开发小组对将要开发的产品达成一致的协议,也就是需求规格说明书。需求规格说明书综合了业务需求、用户需求和软件功能需求。此文档是从包含用户需求的使用实例派生出来的功能需求文档,同时增加描述产品的非功能性方面的需求,包括质量属性和外部接口需求。

(4)需求验证:需求规格说明书完成后,并不能说已经完成了需求分析阶段的工作,只有以结构化和可读性方式编写完这些文档,并由项目的风险承担者评审通过后,这个阶段工作才告完成。需求验证的主要内容有:需求约定正确描述了预期的系统行为和特征,系统需求符合业务需求或其他来源的要求,需求是完整和高质量的,所有对需求的看法、观点是一致的,需求为产品设计、构造和测试提供了坚实的基础。

(5)需求管理:支持系统的需求演进,如需求可跟踪性问题。有效的需求管理需要对变更带来的潜在的影响及可能的成本费用进行评估;对项目风险承担者进行协商;对软件开发各阶段进行需求状态跟踪。

3.卢梅等对5个阶段进行了重新界定,将需求工程活动划分如下。

(1)需求获取:通过与用户的交流,对现有系统的观察及对任务进行分析,从而开发、捕获和修订用户的需求。

(2)需求建模:为最终用户所看到的系统建立一个概念模型,作为对需求的抽象描述,并尽可能多地捕获现实世界的语义。

(3)形成需求规格:生成需求模型构件的精确的形式化的描述,作为用户和开发者之间的一个协约。

(4)需求验证:以需求规格说明为输入,通过符号执行、模拟或快速原型等途径,分析需求规格的正确性和可行性。

(5)需求管理:支持系统的需求演进,如需求可跟踪性问题。

综上所述可以看出,无论是三阶段还是五阶段的需求工程过程理论,其中需求建模都是非常重要的一步。目前,在需求工程领域,主要有如下几种需求建模方法。

1.结构化方法 结构化需求分析大多使用自顶向下、逐层分解的系统分析方法来定义系统的需求。在结构化分析的基础上,可以做出系统的规约说明,由此建立系统的一个自顶向下的任务分解模型。它的特点是利用数据流图帮助人们理解问题,对问题进行分析,即很自然地用图形工具来模拟数据处理过程。典型的结构化建模方法数据流图,可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况,是一种全面描述系统逻辑模型的一种工具。

2.面向对象方法 面向对象方法的形成最初是从面向对象程序设计语言开始的,随之才逐渐被应用到系统分析和系统设计方法中。面向对象分析与设计的实质是一种系统建模技术。其面向对象思想的实质是从系统的组成上来进行分解。这种对问题进行自然分割,利用类及对象作为基本构造单元,以更接近人类思维的方式建立问题域模型的方法,使设计出的软件尽可能直接地描述现实世界并具有更好的模块性、可重用性和可维护性,从而控制软件的复杂性和降低开发维护费用。UML是美国Rational公司开发的一种用于描述、可视化和构架软件系统的建模语言,它不仅统一了面向对象建模方法的基本概念,而且吸取了面向对象技术领域中其他流派的长处,从而更具综合性,并最终统一为标准的建模语言。

3.面向目标方法 面向目标的需求分析方法也是近几年才兴起的一种方法,它与面向对象和事件驱动的需求分析方法相比更接近于现实世界,与系统的目标和功能更加紧密相关。与过去的需求分析方法不同,面向目标的方法不仅描述系统的状态和行为,即回答“What”和“How”方面的问题,而且描述了底层的原理,即回答了“Why”的问题。

4.场景实例法 场景是由一些智能体(Agent,包括外部用户、外界激励和外部的一些功能实体)来初始化的,包括事件和改变系统状态或触发新事件的特定激励。基于场景方法包括场景的获取、表示、验证、原型化等过程。当需求分析人员和用户均对最终的场景满意时,场景分析过程完成。

5.形式化方法 形式化方法是基于数学方法来描述目标软件系统性质的一门技术,它用严格的数学符号和数学法则对目标软件系统的结构与行为进行有效的结合、分析和推理。它为系统的说明、开发和验证提供了一个框架,有利于发现目标软件系统需求中的不一致性、不完整性等方面。它的研究与应用推动了软件需求分析自动化的进程,使软件需求的获取和分析更加严密、精确。

(二)需求工程分析方法的不足

需求工程作为系统分析人员理解问题并定义目标系统的所有外部特征的一门学科,在理论上和实践中都取得了很大的成果。但是,需求工程的建模仍旧存在着一些不足,体现在如下几个方面。

1.需求工程的模型集中在对系统的数据和功能的分析上。需求建模的结果就是形成需求规格说明书,这份说明书是从包含用户需求的使用实例派生出来的功能需求文档,同时增加描述产品的非功能性方面的需求,包括质量属性和外部接口需求,主要用来指导系统的建设。这就导致了分析人员在分析用户需求时,会过多地考虑实现的问题,有可能导致对不易实现的需求的忽略,也就是需求缺失。另外,用户需求还会涉及更深的社会层,仅就功能和数据分析难以体现这方面的需求。因此,在进行需求分析的时候,应该集中精力在用户的业务领域,抓住用户需要系统完成的目标,寻找达到目标所要完成的任务,挖掘隐性需求,这样才能达到对用户业务领域的需求的完整捕获。

2.利用需求工程的理论和方法建立需求模型时,很少考虑到变化的因素对系统的影响。这些因素虽然在建设系统时并不是至关重要的,但是一旦发生变化,将影响系统的使用,甚至导致系统的失败。从对以往信息系统的分析上来看,变化主要来自于两个方面,一是环境的变化,二是用户本身业务需求的变化。对于这两个变动的因素,在需求分析的过程中应当尽量识别,反映出变化的趋势,并在系统建设时考虑适应变化的机制。

3.需求工程的建模方法没有很好地考虑到今后需求重用的问题。利用结构化方法、面向对象方法、面向目标方法和场景实例法分析得到的用户需求的表达没有统一的规格,而利用形式化方法表达的需求虽然是基于数学方法的描述,但是这种形式化描述的目的是发现目标软件系统需求中的不一致性、不完整性等方面,验证框架的合理性。在进行需求分析时,很少重用以前类似需求的相关知识指导,一来导致在建设每个系统之前,都要投入大量的人力、物力去分析需求,加大系统建设的工作量;二来以前对类似需求进行分析的经验教训不能为新建设系统所用,以前系统的分析结果不能指导新系统的建设。

针对以上需求工程分析方法中的不足,有必要研究一种新的用户需求模型,使其关注于业务需求领域,考虑到影响系统变化的因素,同时利用用户需求模型指导需求分析。