第一章 引言
1.1 研究背景及意义
在软件工程发展的早期，软件需求分析在很长的一段时间都被人们所忽视，其关注的重点往往都在编码上，但是随着软件规模日渐扩大，也愈加复杂，人们开始逐渐认识到需求在软件开发过程中的重要性，所以获取软件需求就成为了软件开发过程中的主要活动，有了正确有效的软件需求，才能完成满足客户需要的软件系统。调查研究表明，35 000 个开发项目中只有 16%的项目是成功的，大多数项目（64%）是有问题的，还有 20%的项目完全失败。其中导致项目失败最主要的原因就是获取的需求不正确或不明确[2]。也就是说，需求在很大程度上影响了一个软件或待建系统最终能否成功。近些年对于需求进行了大量研究，并为此专门成立了需求工程这一学科，需求工程包括需求诱导、需求分析、需求规格说明、需求验证和软件需求管理。其中需求管理是用来规划和调控所有这些相关活动的。Roger Oberg 等人在研究目前软件项目高失败率的原因时发现一些软件项目失败的原因是延迟交付、预算超支和质量问题，但在遇到类似的软件开发方面的问题时，通常提出的解决方案都是需求管理[3]。在目前我们熟悉的软件生存周期中，第一步就是进行需求分析。需求分析可以帮助我们在软件或待建系统开发之前，确定新系统或产品的目的、范围、意义及功能，只有获得正确的需求，才更有可能使软件项目成功交付。需求工程的方法目前已有了广泛的研究与应用，如基于问题驱动的需求诱导方法，需求分析及获取方法有快速原型法和用例法等，需求验证的方法有基于本体、多视角、测试用例等方法。其中需求分析与获取中的快速原型法可以让用户在短时间内看到软件的作用，但其实这些功能还只是原型，并没有具体实现；而用例法则是对一组动作序列及其变体的描述，系统执行这些动作序列，并向用户提供一个可观测的有价值的结果，由于这些步骤和事件都是用自然语言描述的，就使得软件需求规约更容易阅读，也易于理解，尤其对那些非IT专业人员来说[4]。一般一个用例包含的元素主要有：1）一个显示目标的用例名 2）一个描述主角和系统交互的主场景 3）在执行主场景时可能发生的扩展事件 4）对应扩展事件的备选步骤。所以一个用例可以通过主场景和备选场景来描述，也就是说我们可以使用场景来描述需求。场景说明了系统是如何与最终用户或其他系统进行交互的，更加直观的帮助用户了解系统的作用，进而得到一个明确的业务目标。
.........
1.2 国内外研究现状
使用场景来描述需求在国内外很早就开始了研究，场景这一词的提出可以追溯到 1982 年，Hooper.J.W 和 Hsia.P 在需求识别时候就开始使用场景了。1987年 Lakoff 提出了场景的结构：源（初始状态）-路径（一系列事件）-目标（终止状态）[9]。M.Glinz 在 1995 年曾提出过一种描述场景的语言。到了 1998 年，Rolland 等人提出了场景的定义：场景由一个或多个动作组成，这些动作描述了一条独特的从代理的初始状态到终止状态的路径[10]。他们研究了场景和目标的模型，并将场景进一步精化为三个层次，由上到下依次为上下文层场景、系统交互层场景和系统内部层场景，上一层精化为下一层，每一层场景中还定义了场景之间的关系，例如 AND—场景之间的组合关系，OR—场景之间的选择关系等，对场景的描述越来越具体。不仅如此，1999 年欧洲软件工程学会开展了 CREWS（Cooperative Requirements Engineering With Scenarios）项目，其项目报告在网站上供人浏览。2000 年以后，对场景的研究越来越多。Hermann Kaindl 等人在 2005 年的研究中提出了一个 RETH（Requirements Engineering Though Hypertext）模型，该模型描述了场景与目标、功能、计划、行为等其他影响需求的因素之间的关系[11]。同年伦敦城市大学的 Konstantinos Zachos 和 Neil Maiden 研究 Rich-Media场景，提出了一个 ART-SCENE 元模型，该模型中包含了场景、事件、对象、代理、媒介等多种元素[12]。Zachos 等人还提出了故事板的概念，即场景可以由一块故事板来描述，在故事板上列出各种事件，事件中包含很多代理和动作，通过元模型和 UML 图来表示这些元素和关系，可以清楚的看到多媒介组成的场景，以及与故事板、动作、对象等的关系。2006 年 Hongzhi Liang 等人研究了场景模型和状态模型之间的异同，定义了对比标准，调查了 20 余种不同的表示方法[13]。Thomas 等人在 2008 年的一篇文章里阐述了场景的四种衡量标准，并提出了自动化支持的方法，研发了一个 SMaRT（The Scenario Management and RequirementsTool）工具[14]。
.........
第二章 场景元模型研究与构建
2.1 场景概述
2.1.1 场景的相关研究
场景一词在韦氏字典中的定义为“运动画面的情节”，在多个领域以不同的准则应用了很长时间，如军事战略、市场营销和经济方面。信息系统领域是从人机交互界面开始使用场景的，之后在软件工程上也开始广泛应用。最早的一个能证明基于有效场景设计的应用就是洛杉矶奥运会时的 IBM 的语音留言系统。自此之后，场景开始以各种形式出现。Jarke，Bui 和 Carroll 曾提出过一个关于场景研究的综述，其中既包含了信息系统的观点，也包含了管理决策理论方面的观点，他们指出了场景基于几种准则的有效使用[31]。场景在信息系统中发展的越来越壮大，90 年代的时候就已经可以提供待建系统的社会和环境情况。对于目前的需求分析师来说，编写场景就是描述通过系统和它的环境或用户交互的系统行为。用自然语言来编写主角与系统交互的场景，帮助涉众理解他们编写的需求。其中涉众就是指与整个需求分析相关的所有人员，不仅仅是软件开发人员、客户、需求分析师，还包括项目经理，同领域的专家等。
2.1.2 场景与用例的关系
在软件工程领域，用例作为一种叙事描述，描述了在面向对象设计里的使用、职责和服务，而场景就是用例的具体实现，用例要比场景的抽象层次高。使用抽象化方法在软件工程中有时更容易解决问题，Hizzan 和 Kramer 就定义了计算机科学与软件工程领域中抽象化的概念：抽象化是一种认知方式，为了在某一特殊阶段解决一个复杂的问题，我们只集中于思考问题的基本特征，而忽略其他不相关的细节[32]。用例的概念是：用例是对一组动作序列及其变体的描述，系统执行这些动作序列，并向用户提供一个可观测的有价值的结果。用例包含的元素主要有：1）一个显示目标的用例名 2）一个描述主角和系统交互的主场景 3）在执行主场景时可能发生的扩展事件 4）对应扩展事件的备选步骤。所以一个用例可以通过主场景和备选场景来描述，即一个用例可以用一个或多个场景来表示，我们也就可以通过场景来描述需求。如图 2.1 所示，图中表示了用例的事件流，其中最粗的向下的箭头表示正常事件流的走向，也就是主场景所描述的事件。但是也有一些异常事件流，如图中导致结束的线，除此之外还有一些在主事件流上的箭头代表备选流，一个事件可能由多种选择。整个用例都可以通过场景表示出来，分别为主场景、备选场景和异常场景，以此描述功能性需求。
.......
2.2 场景元模型分析
目前关于场景元模型的研究有很多，也都涉及多个方面，不同的元模型都有其不同的侧重点。本节首先介绍一个关于需求和场景 UML 类图所画的元模型，继而介绍一个场景结构的元模型以及两个侧重点不同的场景元模型。两种侧重不同方面的元模型分别是基于目标的场景元模型和多层面的场景元模型，本节还会详细分析这两个场景元模型中的元素及其关系。
2.2.1 场景与需求元模型
在使用场景描述需求时，不仅要注意待建系统的预期用途，还要考虑与待建系统的交互。如图 2.2 所示为 UML 的类图所画出的场景与需求之间关系的元模型。Hermann Kaindl[11]认为预想的场景描述了待建系统与其环境之间所需的交互，所以要考虑到他们的行为要求，因此在元模型中将需求特别说明，不同于功能需求。
..........
第三章 基于场景元模型获取有效需求的研究............20
3.1 有效需求概述....20
3.2 需求的一致性研究与实现....20
3.2.1 一致性介绍..........20
3.2.2 实现一致性的方法........21
3.2.3 创建术语表实例............23
3.3 需求的可追踪性研究............25
3.3.1 需求变化的原因及影响..........25
3.3.2 可追踪性研究......26
3.3.3 可追踪性的验证............32
第四章 可追踪性工具研究与实例............34
4.1 追踪性工具研究..........34
4.2 基于场景描述需求实例........39
第五章 总结与展望....43
5.1 总结..........43
5.2 展望..........43
第四章 可追踪性工具研究与实例
4.1 追踪性工具研究
对于追踪性的进一步实验研究，本节给出一个追踪矩阵运算工具的原型，通过对该原型的进一步实现可以完成追踪矩阵的运算，以及追踪关系的可视化。除此之外，还实现了一个简单的通过读取文本文档来实现追踪矩阵运算的小工具，可以用来帮助计算追踪矩阵，识别追踪关系。通过GUI Design Studio实现一个可追踪性工具的原型，命名为TraceabilityTool，该原型描述了一个实现追踪矩阵运算的工具以及描绘目标-场景-动作-对象之间追踪关系图功能的工具。如图 4.1 所示为该原型的主界面。可以通过向追踪矩阵中输入目标-场景追踪矩阵、场景-动作追踪矩阵以及动作-对象追踪矩阵，最后得到目标-对象之间的追踪矩阵。通过运行中的运行追踪矩阵计算选项实现或者通过快捷按钮计算，如图 4.2 和 4.3 所示。还可以通过视图切换中的追踪关系界面选项切换到追踪关系界面，如图 4.4为视图切换选项，图 4.5 为界面切换快捷按钮。选择追踪关系界面或按下视图切换按钮就会出现图 4.6 所示的追踪关系图界面，在追踪关系图界面可以实现刻画场景元模型中四种元素追踪关系图，就像图 3.5 一样。
.........
总结
本文主要研究了一种基于场景元模型获取有效软件需求的方法，分析了当前的各种场景元模型的元素及其关系提出了一个新的场景元模型，在所提出场景元模型中的元素之间建立可追踪关系实现需求描述的可追踪性，使用创建术语表的方法保证需求描述的一致性，进而得到有效的需求，最后提出追踪矩阵原型工具以及追踪矩阵运算工具，并通过 ATM 场景实例进行了有效验证。通过本文的工作完成了以下目标和内容：
（1）分析场景和需求之间的关系，确定了在描述需求时使用场景的优势和重要意义。
（2）对现有的基于目标、结构以及多层面的场景元模型进行分析，研究其中的元素及元素之间的关系，提出了一个新的适合于获取有效需求的场景元模型，并绘制了场景元模型图，同时也对所提出的场景元模型的正确性进行了检验。
（3）本文主要研究有效需求的一致性以及可追踪性，使用创建术语表以及在场景元模型中的元素之间建立追踪关系分别实现。使用术语表方法定义场景描述中涉及到的专业词汇、过于抽象或者容易引起歧义的词语，在场景中的元素之间建立追踪关系，通过计算变化追踪矩阵使基于场景所描述的需求具有了可追踪性，对需求的变更管理有着重要的意义。
（4）给出了一个可追踪性工具的原型目标并实现了追踪矩阵运算工具，应用实例进行了验证，实现了通过读取相关追踪矩阵文档计算出目标与对象之间的追踪矩阵，进而得到其中的追踪关系。
（5）应用场景描述的 ATM 机的功能需求证实场景描述需求的意义，便于与涉众进行沟通确认，在使用场景描述时使用术语表中定义的词汇，并且可以将场景中的对象、动作等根据场景元模型建立追踪关系，最终得到有效的软件需求。
..........
参考文献（略）