The Three Dimensions of Requirements Engineering

L/O/G/O

The Three Dimensions of Requirements EngineeringKlaus Pohl

Liweiheng2012.5.4

www.themegallery.com

目录• 文章核心• 作者简介• 选题原因• 《需求工程》文献阅读列表• 论文框架• 论文正文• 近期的测试案例


AbstractRequirements engineering (RE) is perceived as an area of growing importance. Due to the increasing effort spent for research in this area many contributions to solve different problems within RE exist. The purpose of this paper is to identify the main goals to be reached during the requirements engineering process in order to develop a framework for RE. This framework consists of the three dimensions:

- the specification dimension （需求规格维度） - the representation dimension （表示维度） - the agreement dimension （协议维度）

Looking at the RE research using this framework, the different approaches can be classified and therefore their interrelationships become much clearer. Additionally the framework offers a first step towards a common understanding of RE.



作者简介• 　 Klaus Pohl 教授是杜依斯堡一埃森大学的全职教授，领导着一个软件系统工程研究团队。他从德国亚琛工业大学获得博士学位。他参与了各种各样的技术转让项目和一些关注软件产品线工程各个方面的重要项目。他是 90 多部著作的作者或联合作者。他担任过多个国际、国内会议的主席，例如， IEEE 国际需求工程大会（ RE’02 ），第

27 届国际软件工程大会（ ICSE 2005 ），德国软件工程大会（ SE 2005 ），第 9 届国际软件产品线大会（ SPCL Europe 2005 ），第 18 届国际先进信息系统工程大会（ CAiSE 2006 ）。


作者简介


选题原因• 《需求工程》课程作业的文献列表• 教学材料中出现过论文提出的理论 ( 引用 343次 )• 文章格式工整，内容集中，论点清晰，清楚知道读者的需求。


需求工程• 暂定已经上过的课：

1. 2 月 24 日：软件需求工程原理2. 3 月 16 日：软件需求工程过程3. 3 月 23 日：软件需求建模基础4. 3 月 30 日：面向目标的方法5. 4 月 6 日：面向主体和意图的方法6. 4 月 13 日：基于情景的方法7. 4 月 20 日：问题框架方法8. 4 月 27 日：文档驱动的方法

需求工程概述

代表性方法


《需求工程》文献列表• Research Directions in Requirements

Engineering (263)• Requirements Engineering: A Roadmap (1113)• Revisiting the Core Ontology and Problem in

Requirements Engineering (58)• The Three Dimensions of Requirements

Engineering (343)• Requirement Engineering in the Year 00: A

Research Perspective (574)


Roadmap

本文的标题翻译为“需求工程的路标”，可以说是一篇导航性质的文章。这是一篇关于软件系统需求工程（ RE ）的概述的论文。它描述了RE 实践的主要方向和方法，并提出一些未来的研究方向。

Requirements Engineering: A Roadmap


• 此篇文章介绍了 RE 目前的一些研究和这个领域中的主要活动。文章分章节介绍了有效的需求工程方法的基础（包括认知心理学、人类学、社会学、语言学、认识论、现象学、本体论等等），开始 RE 需要的背景和上下文（包括对项目可能性和相关的风险的分析、对项目价值的评估、进度安排、对技术可行性的详细说明、辨别合适的 RE 过程、选择合适的 RE 活动等等），以及核心的 RE 活动：• eliciting requirements ，需求捕获• modelling and analysing requirements, 需求建模和分析• communicating requirements, 需求交流• agreeing requirements, 需求一致• evolving requirements. 需求变更

Roadmap


RE 未来的挑战• Development of new techniques for formally modelling andanalysing

properties of the environment, as opposed to the behaviour of the software.• Bridging the gap between requirements elicitation approaches based on

contextual enquiry and more formal specification and analysis techniques.• Richer models for capturing and analysing non-functional requirements• Better understanding of the impact of software architectural choices on the

prioritisation and evolution of requirements• Reuse of requirements models• Multidisciplinary training for requirements practitioners.1 、正式建模和环境属性分析的新技术的发展。2 、消除基于情境调查的需求捕获途径、和更正式的规格说明与分析技术之间的分歧。3 、更加丰富地获取和分析非功能性需求的模型。4 、更好地理解需求的优先次序和演化对软件架构的选择产生的影响。5 、需求模型的重用。6 、对需求从业者进行多学科的训练。


Future of RE

这篇文章中，作者回顾了现阶段需求工程的研究，并根据新型的软件需求确定了未来的研究的方向。软件系统的成功程度取决于它是否适应用户或环境的需求，软件需求就是由这些组成，需求工程过程就是由这些需求决定的。成功的需求工程需要理解用户、消费者以及利益关系者的需求；理解需要开发软件所处于的环境；要针对利益关系者建模、分析、交涉以及建立文档；要确保文档需求与写上的需求匹配；并且要管理好需求演变。

Research Directions in Requirements Engineering


为什么 RE 困难？需求工程的难度在于几点：• 首先，需求分析开始时的定义就会有缺陷或冲突；• 其次，需求的问题域比软件的解决域的束缚要小；• 再次，需求工程要考虑的方便要有很多，也很复杂；• 另外，在推理环境的过程中，不只要考虑到正常的情况，还要考虑到非正常的情况；• 最后，需求工程不仅要涉及到产品，还要涉及到软件技术。


目前的研究现状• 需求工程目前的研究现状可以使用一个矩阵来表示，研究空间可以大致由五种类型组成：（诱导，建模，需求分析，验证以及需求管理），解决方案可以分成三个种类（符号、方法学以及技术方面）。这篇文章使用这种形式例举出了目前大部分重要的研究以及文献。


未来的研究热点• 未来的研究热点包括一下几点：设计系统的规模方面、安全性方面、容错性方面、系统兼容性方面、需求自管理方面、软件全球化方面、处理方法与工具方面、需求重利用方面以及需求工程技术有效性方面。


A research Perspective

这篇论文是一篇综述性文章，阐述了历史上推动需求工程发展的主要的概念和技术，着重分析了建模对于所有需求工程过程的基础性指导。初步描述了一个复杂的安全挑战系统用于列举一些目前需求工程正在研究的特殊方向，例如目标方向的需求描述、冲突管理、以及解决不规则的需求行为。Requirements Engineering in the Year 00: A

Research Perspective


文章重点• 作者用大量的篇幅介绍了在第一个 25年中，需求工程领域的几个里程碑式的研究。首先是需求建模方法，建模是需求工程过程中的核心过程。在早期一些领域的研究人员提出了一些新的观点，发表了一些很优厚意义的论文。之后出现了代理人的概念；然后是基于目标的推理方法；除了上述正常高质量的推理技术之外，关于冲突管理的其他工作着重强调在目标阶段处理冲突的需要；之后又发展出了基于方案的需求引导和确认，这个方法既有他的优点又有其不足的地方；除了上面的工作之外，还有一些基础性的工作研究；还有一些研究是针对于过程控制的系统反应的特殊领域；最后介绍了需求的重用。


AbstractRequirements engineering (RE) is perceived as an area of growing importance. Due to the increasing effort spent for research in this area many contributions to solve different problems within RE exist. The purpose of this paper is to identify the main goals to be reached during the requirements engineering process in order to develop a framework for RE. This framework consists of the three dimensions:

- the specification dimension （需求规格维度） - the representation dimension （表示维度） - the agreement dimension （协议维度）

Looking at the RE research using this framework, the different approaches can be classified and therefore their interrelationships become much clearer. Additionally the framework offers a first step towards a common understanding of RE.


文章总览• 第一章主要是介绍 RE 的基本概念，它是什么，有哪些方法。（概述）• 第二章则是从抽象层面来分析 RE 过程。关注与初始输入和期望输出，并发现三个主要特征。• 第三章的内容就是第二部分所发现的三个特征导致了这篇论文最核心的部分——需求工程的三个维度。• 第四章介绍这三个维度中的 RE 过程。因此 RE 过程所要达到的目标和过程中出现的问题都可以被分类。• 第五章讲述需求工程的计算机支持。• 第六章对研究成果进行总结。


1 、 introduction• 在文章的第一章，作者强调了 Detection of

requirements （需求检测），它包括需求的引出和捕获，以及验证和确认。为了表示需求，研究者提出了形式化规范语言（例如Z 、 VDM 、 PAISLey ）和知识表示语言（例如RML 、 ERAE 、 TELOS ）。这些语言都有自动推理的优点，但是不能直接将它们应用到 RE ，它们必须从非形式化的 RE 规格中产生或者与非形式化的 RE 规格结合。

• 疑问：如何映射到三个纬度上？ - the specification dimension （需求规格维度） - the representation dimension （表示维度） - the agreement dimension （协议维度）


1 、 introduction

作者认为理解 RE 核心的第一步就是要区别下面两类问题：• original requirements engineering

problems• problems caused by approaches which try

to solve the original problems （第四章）


2 、 the RE Process• 从抽象层次来看 RE 过程，它的核心本质是实现输入到期望输出的转变。 -2.1 the Desired Output -2.2 the initial input of the process


2.1 output• 需求工程最终是一个系统的规格说明书。这个规格说明作为软件生命周期的下一阶段的基础。因此， RE 过程的输出的一个特点就是，系统的规格说明能够被识别。 RE 过程的基本结果，就是一个预期的完整规格说明。• 如果系统规格说明用自然语言描述，不同的人对同一个规格说明会有不同的理解，这会导致我们所不希望的设计和实现，为了避免对规格说明的不同解释，越来越多人建议使用一个规范的语言来描述系统的规格说明。而形式化语言能够实现推理。因此 RE 过程的结果应该使用形式化语言来表示。• RE 过程最后需要在最终规格说明上意见统一，以避免过多的错误修正的代价。• 总之， RE 过程的期望输出，就一份是所有涉及到的人员都认可的，使用形式化语言描述的完整的系统规格说明。


2.2 input• 初始输入：• 在 RE 过程最开始，有关系统的知识是粗糙的。一些特征很明显，但是另外一些特征很模糊。由于参与到 RE 过程的利益相关者角色多种，他们的技能和知识不同，因此他们对系统各有自己的理解。最开始，有些人从自己角度用自然语言来描述系统，有些人只是给出一些想法，有些人只是使用自然语言做一些笔记，或者干脆只是画一些草图。所以，在 RE 过程最开始，最主要采用的是非形式化的描述。• 总之，在 RE 过程最开始输入，是从不同视角对系统的非形式化语言描述。


3 the three Dimensions从初始输入和期望输出，可以得到 RE 过程的三个主要目标：• improving an opaque system comprehension into a

complete system specification; (specification)• transforming informal knowledge into formal

representations; (representation)• gaining a common agreement on the specification out of

the personal views;(agreement )



3.1 the specification Dimension• First of all, a requirement specification is supposed to state what a

system should do and not how.Additionally, the specification must be unambiguous, complete, verifiable, consistent, modifiable, traceable and usable during operations and maintenance.

• Secondly a differentiation between two kinds of requirements can be made: functional requirements and non-functional requirementsThe functional requirements specify what the software must do.non-functional requirements can be further divided into performance, design constraints, external interface and quality attributes.

• Beside this classification of requirements a distinction between vital requirements and desirable requirements should be made. Vital requirements must be completely accomplished by the system, whereas desirable requirements may be relaxed and need not be met within the stated limits. (vital > desirable )


3.1 the specification Dimension• Summarizing the first main goal of RE, as identified by many

researchers, is to build a requirements specification, according to the standard and/or guideline used.

• The degree of the specification (opaque to complete)is captured by the specification dimension.


3.2 the representation Dimension• Summarizing, during the RE process different representation

languages are used. At the beginning of the process the knowledge about the system is expressed using informal representations, whereas at the end of RE the specification must also be formally represented.

• The second main goal of the RE process is threefold. • First, different representations must be offered. • Second, the transformation between the representations (e.g.,

informal to semi-formal, informal to formal) must be supported. • Third, the different representations must be kept consistent. (保持一致 )


3.3 the agreement Dimension

• Summarizing, the agreement dimension is as important as the representation and specification dimension. We have pointed out that several specifications expressed in different representation formats may exist at the same time.

• Further we showed, that the coexistence of different views has positive effects on the RE process. Thus, allowing different views and supporting the evolution form the personal views to a common agreement on the final specification is the third main goal of RE.


4 the RE process within 3D

The main goals of the RE process can be sketched as follow (cf. section 3 for details) :• develop a complete system specification out of a opaque system

understanding• providing integrated representations and support the transformation

between them• accomplish a common agreement on the final specification allowing

personal views.




• So the trace of the RE process is an arbitrary curve ( 任意的曲线 ) within the cube spanned by the three dimensions

• The initial input is characterized as opaque personal views of the system represented using informal languages,

• whereas the desired output is characterized as formally represented, complete system specification on which agreement was gained


需求工程的三维视图

非形式非形式形式

规格

说明

表示

模糊

一般

完全

表示维

内容维

接受度维

• 表示维（代表需求的可维护、可验证的程度）–非形式的：自然语言–半形式的：图形语言（如：

UML ， DFD ，等）–形式的：数学或逻辑语言（如：

Z ，等）

• 内容维（代表需求工程的进行程度）– 模糊的客观世界现象– 明确的需求规格说明

• 接受度维–代表某个需求相关者的观点– 得到全部需求相关者的认可


模型的形式• 自然语言形式

– 绝对的表达能力和灵活性– 非常难以捕获模型的语义– 用于需求抽取，或为便于沟通进行模型的标记等方面比较好

• 半形式化表示（如：图，表，结构化英语等）– 捕获结构和一定的语义– 可以实施一定的推理，一致性检查，模拟，等等

• 比如：图、表、结构化英语、等等• 形式化表示

– 非常精确的语义，外延推理成为可能– 离开应用领域还有很长的距离

• 注意：需求形式化主要是为了认知的考虑，因此与计算机科学的形式化有点不同

能选择各种不同的概念框架


• 影响 RE 过程的五个因素：• 方法和方法论（结构化分析 VS 面向对象）• 工具• 社会因素（工作的环境）• 认知技能（用户和需求分析师）• 经济限制



• 因此，在 RE 过程中，要区别是起初的问题（ Original RE problems ），还是上面五个因素导致的问题。上面五个因素导致的问题可以用 SA- 图、 ER- 图或者数据字典来很好的描述。 Original RE problems指由那三个维度导致的问题，例如需求捕获、需求抽取、不同描述之间的转换、不同观点的结合。



5 Computer Support for RE• For improving the result of the RE process

in one of the three RE dimensions• for guiding the process of RE 为了支持整个 RE 过程，必须要开发一个合适的过程模型来，来指导这三个维度中的RE 过程。• for easing the influences on the process



6 总结• 在本文中我们介绍了需求工程框架。首先，我们专注于需求工程过程的本质。我们定义需求工程过程的初始输入为使用非正式的语言表达不清晰的个人观点。 ‘希望的输出“，勾勒出一个使用达成了一致的正式语言表示的完整的系统规格说明书。基于这种特性确定了需求工程的三个主要目标。


6 总结• 三个主要目标如下：• 1 、 gaining a complete system specification out of the

opaque views available at the beginning of the process, according to the standard and/or guideline used.

• 2 、 offering different representation formats, supporting the transformation between the representation (e.g., informal to semi-formal, informal to formal) and keeping

the various representations consistent,• 3 、 allowing various views and supporting the evolution

form personal views to common agreement on the finial specification


总结• Out of these, the three dimensions of RE were gained:

specification, representation and agreement dimension.• Looking at RE using these three dimensions we

identified the main tasks and goals to be reached within each dimension during the RE process. But RE is not only driven by its goals, it is also influenced by the environment. We identified five main factors influencing requirements engineering: methods and methodologies, tools, social aspects, cognitive skills and economical constraints.


总结• Accordingly existing research and

computer support was briefly sketched by distinguishing between computer support for improving the specification in one of the three RE dimension, for guiding the process of RE and for easing the influences on RE.


6 总结• this framework is used for classifying RE

problems and for making process guidance possible. The framework itself should be seen as a first attempt to accomplish a common understanding of RE within the community. It should serve as a basis for discussing research topics and identifying the main problems of RE.


测试案例• （ 1992年） Performing Rights

Society （演出权益协会） PROMS项目，花费 1100万英镑之后被放弃。其中糟糕的需求工程是项目失败的一个主要因素，包括未能以普通人能够理解和检查的形式表达软件需求。• （ 1990年） Wessex Regional

Information Systems Plan （地区信息系统） , RISP 项目，花费 4300万英镑后被放弃。其主要原因包括缺乏对项目范围的清晰定义。

与客户沟通的问题

需求的边界问题


测试案例• （ 1993年） London Stock

Exchange （伦敦股票交易） TAURUS 项目，花费 7500万英镑后被取消。许多问题源于未能协调不一致的需求。

• （ 1992年） London Ambulance Service Despatch System （伦敦救护车服务派遣系统），在运行两天后被关闭，源于对社会服务领域的需求没有分析清楚。

不一致需求的管理问题

需求不清晰的问题


测试案例• Swanick Air Traffic Control （空中交通控制），计划在 1998年完成，但 2001年还未完成（额外开支 1.8亿英镑）。主要原因包括：没有得到完整的需求规格说明就开始系统实现的工作。

需求没弄清楚就匆忙开始后续工作


近期的测试案例2008年 6 月 30 日，北京奥运门票系统在提交使用的当天即发生瘫痪；原因之一是对系统用户数的预测不足

2012年春运！

L/O/G/O

Thank You!

Documents

The Three Dimensions of Requirements Engineering