前沿技术课程报告

武汉大学计算机学院2010级硕士研究生课程软件工程前沿技术研究方向主讲老师：彭蓉学院：计算机学院学号：2010206350006姓名：程胜需求工程中需求获取方法综述摘要：随着社会信息化的飞速发展，计算机软件变得愈来愈复杂、规模也越来越庞大，软件工程的研究也日益深入，软件需求则逐步成为贯穿于整个软件开发过程的核心因素，而需求获取则成为需求工程领域的新热点。

需求获取是软件生命周期的初始阶段，也是决定软件成败的关键因素之一，由于需求不清或错误导致软件失败的案例越来越多，所以如何快速、准确地获取软件需求成为软件行业研究的重点。

通过需求建模来获取需求，目前有用例驱动的交互式需求获取、基于UML的需求获取、基于领域本体的需求获取方法、基于Event-B的软件形式化需求获取方法、基于RGPS的网络式软件需求方法等需求获取方法。

这几种方法都有自己的独特的获取需求的方法，侧重于获取过程中的不同的方面，从不同角度方向、不同领域来克服需求获取中的困难，提高需求获取的准确性。

关键字：需求工程、需求获取方法、用例驱动、UML、领域本体、Event-B、RGPS一、引言需求工程是随着软件工程的发展而产生的。

在软件开发的初级时期，软件规模不大，软件开发所关注的是代码编写，软件需求很少受到重视。

在引入软件生命周期的概念后，需求工程成了软件生命周期的第一阶段。

随着软件系统规模的扩大，以及为了解决“软件危机”而引起的软件工程技术与方法的发展，需求工程在整个软件开发与维护过程中就显得越来越重要了。

人们普遍认识到，充分研究软件需求可以避免开发系统时的盲目性，能够直接关系到软件的成功与否。

随着软件工程的研究和应用的逐渐深入，人们同时认识到软件需求不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

许多项目开发过程中出现的诸多问题都与需求工程阶段没有合理完整的进行需求获取、分析有关。

由此可见，需求工程对于项目开发尤其是大型项目的研发的至关重要的作用。

需求工程的准确含义，没有严格统一的表述。

一种比较常用的解释如下：需求工程是指应用已证实有效的技术、方法进行需求分析、确定客户需求，帮助分析人员理解问题并确定目标系统的所有外部特征的一门学科；它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档；并对用户不断变化的需求演进给与支持。

需求工程可以分为需求开发和需求管理两部分。

需求开发包括需求获取、需求分析、编写需求规格、需求验证；这些子学科涵盖了为软件和软件相关产品收集、评估和记录需求相关的所有活动。

需求管理包括需求变更控制、版本控制、需求跟踪、需求状态跟踪等内容。

需求工程中如何快速获取和准确地理解、表达用户需求，即需求获取，是长期困扰软件开发者的难题。

一方面，软件开发者由于不了解应用领域，只能被动地等待领域用户提供信息，他们常常抱怨用户需求不全，经常变化，使他们无所适从；他们还难免对领域用户的描述产生错误的理解，因而得出不适当的需求模型，导致软件开发半途而废。

另一方面，领域用户通常不知道如何按软件开发的要求去描述他们的需求，而且，他们一开始常常对自己的需求仅有一个模糊的认识，如果没有任何提示和引导，就不可能立刻给出正确而完整的需求描述。

确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细地说明一个系统的真正需求。

一个不完整的需求获取和管理过程，会对项目的生命周期产生多米诺骨牌的效应。

用户需求的缺失会导致系统需求的缺失，从而导致设计单元及功能的缺失，并最终导致系统不能实现预期的功能，或者需要在后期花费较大的代价来修正或补充这些功能，导致项目延期、产生严重的质量问题或超出项目预算。

因此，及时、准确地获取用户需求，是决定软件项目能否取得成功的关键步骤之一。

二、需求获取及需求建模需求获取就是通过不断交流沟通使软件开发者和领域用户对目标系统形成共识。

现今国内外提出了数种需求获取的方法，从不同角度方向、不同领域来克服需求获取中的困难，提高需求获取的准确性。

获取需求存在诸多困难主要原因如下：（1）缺乏领域知识、应用领域的问题常常是模糊的，不准确的；（2）存在默认的知识，即难以描述的日常知识（常识问题）；（3）存在多个知识源，而且多个知识源之间可能有冲突。

通过需求建模可以来获取项目需求，明确需求细节。

目前需求建模方法针对软件范型不同主要分为结构化需求建模和面向对象需求建模，涉及功能需求分析和非功能需求分析。

通过对各种需求工程方法的研究，目前影响力较大的需求建模方法，分别是面向目标的需求建模方法，基于领域本体的需求建模方法以及面向特征的需求建模方法。

1、面向目标的建模方法面向目标的建模方法侧重于对早期需求进行分析和建模，试图帮助开发者理解领域中不同角色的动机和期望，可对功能和非功能需求目标识别分析。

面向目标的建模方法，在需求阶段的主要任务是要确定软件系统需求相关者想要实现的各项目标，建立实现这些目标所需要的服务和约束条件的规格说明，并将需求按职责分配给相应的主体来完成。

该方法将“目标”看作软件需求的源头和依据，以目标为需求获取的基本线索，诱导需求提供者按目标的分解、精华和抽象关系，逐步构建系统目标与(或)树。

面向目标方法的主要特点是目标树为需求活动提供了一种表示结构和自顶向下的需求分析方法，有助于将零碎分散的需求信息组织成易于理解的层次结构，多种目标分解方式使得不同的设计方案得以兼顾和考虑。

更为重要的是，将目标与形式化方法结合，能够为需求工程以及软件产品的正确性和完整性提供可靠的保证。

面向目标的方法，考虑组织中参与者的主动需求，不仅分析单个参与者的目标分解，更研究参与者之间的各种依赖关系，如目标依赖、任务依赖、资源依赖和软目标依赖。

面向目标的方法主要有以时序逻辑为基础的基于自动规约的需求获取方法KAOS、面向目标和过程分析的非功能需求框架NFR、i半建模框架以及建立在目标基础上的开发方法——TROPOS方法。

2、基于领域本体的建模方法本体论是一个哲学概念，用于描述事物的本质.知识工程学者借用这个概念，是为了解决知识共享中的问题。

人们发现，知识难以共享常常是因为大家对同一件事用了不同的术语来表达。

于是人们提出，如果能找出事物的本质，并以此统一知识的组织和知识的表达，使之成为大家普遍接受的规范，就有可能解决知识共享中的问题。

简而言之，本体是对于知识的描述。

就需求工程而言，本体的作用体现于：本体作为需求规格说明，即建立特定领域的本体，利用这个本体为建立多个目标应用系统的需求提供知识库。

此时，本体可以看作一个公共的领域模型，作为建立领域内应用系统需求规范和系统开发的基础，能够进行知识重用。

ODE方法是一种比较典型的基于本体领域分析方法，包含三个部分：领域分析、领域模型到对象模型的映射和Java构建开发。

ODE方法的基本步骤包括：建立目标和需求规范；基于本体捕获领域概念，标识和组织相关领域实体，利用图形化描述的模型来促进领域专家的交流；用一种形式化的语言清晰地描述本体模型；评估本体以检查它们是否满足需求规范；最后对所有本体加以文档化。

从领域本体模式中导出面向对象的模型时，ODE中提供了一个包括指示、设计模式和转换规则的系统化方法，指示可以指导从本体结构到面向对象相应部分的映射，设计模式和转换规则可以用来映射本体中的公理到面向对象的相应部分。

3、面向特征的建模方法面向特征的领域分析(Feature Oriented Domain Analysis, FODA)是由K．Kang等人在20世纪90年代提出的一种全面的领域分析过程描述，用于识别特定领域中一系列应用系统的显著特征，针对领域进行共性和个性的研究，抽取领域模型，从而建立可复用的软件体系结构。

其基本思想在于，从领域的具体应用系统中，抽象出具有代表性的功能，组成领域模型，从而为以后的应用系统开发奠定基础[7]。

随后，K．Kang等人对FODA方法进行了扩展使之应用于软件复用领域，提出了面向特征的软件复用方法(Feature Oriented Reuse Method, FORM)，并且在基于构件的开发中用FORM辅助开发软件体系结构和可重用构件，确定了在软件开发中面向特征方法的作用和意义。

面向特征的领域分析以“特征”作为组织需求的基本单元，通过分析领域具有的可复用特征和特征之间的依赖关系，建立领域的特征模型。

领域设计则以特征模型为输入进行领域软件体系结构的构造。

同时，通过定制对特征模型的复用也是形成单个软件产品需求模型的有效手段。

三、几种需求获取方法目前，使用比较广泛、研究比较热门的几种需求获取方法有：（1）用例驱动的交互式需求获取（2）基于UML的需求获取（3）基于领域本体的需求获取方法（4）基于Event-B的软件形式化需求获取方法（5）基于RGPS的网络式软件需求方法1、用例驱动的交互式需求获取多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求。

Ivar Jacobson(1992)把这种看法系统地阐述成用例的方法进行需求获取和建模。

虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中。

用例（use case）是指系统为了向参与者提供某些有价值的结果而执行的动作序列，这个序列是在与系统的对话中完成的新的活动。

用例代表的是外部执行者所理解的系统功能。

涉及到参与者即角色。

用例中的关系有扩展（Extend）、包含（Include）和泛化（Generalization）.用例驱动的交互式需求获取方法：（1）功能性需求的获取：获取用户需求，定义问题范围，收集用户需求，确定参与者和用例。

参与者是指所有存在与系统外部并与系统进行交互的人或其他系统，从需求获取信息获取参与者。

首先要确定系统范围（System Scope）和系统边界（System Border）, 系统的范围与边界取决于开发的目标、任务和规模；确定参与者的种类，参与者有三大类也就是三种角色:用户、其他系统和时间。

（2）用户需求用例的获取：获取用例的最好办法是考虑每个参与者需要系统为他做些什么，即参与者的目标。

最后进行用例求精（Use Case Refinement）。

用户需求决定了系统的功能需求，为了获取这些功能需求，必须要对用户需求阶段获取的大粒度的抽象用例进行求精，通过细化用例的事件流，得到用例的所有场景的集合，而这些场景中各个步骤就是功能需求的来源。

用例驱动的关键在于提供准确的Actor以及相关的用例信息。

因而我们设计出相应的用户填写的内容，让用户填写它所关心的功能需求的描述，基本以获取用例驱动相关信息为主。

填写完所需内容我们可以往需求获取表格中添加，当然，由于是交互的过程，我们需要对需求进行反复的修改，因而我们允许进行修改、删除等操作。