需求工程:基础、原理和技术3

波尔(Klaus Pohl)

计算机科学丛书

7：目标导向基础、8：描述目标:9：场景基础:10：场景类型

第7章 目标导向基础

7.1 动机

在需求工程中考虑并描述目标所需的工作量与所能获取的收益相比是很低的。需求工程中明确考虑并描述目标表有如下益处：

❑对于系统更好的理解：目标对系统的总体愿景进行了精化,阐明了系统对于相关涉众的价值，因此也为系统开发提供了原理性的考虑。

❑需求抽取：目标驱动并指导需求的抽取。

❑可选实现方案的识别和评价：满足一个目标通常存在多种可能的方案。通过将目标分解 为子目标，可以系统化地识别可选的实现方案。

❑识别无关需求：明确考虑目标可以支持对于无关需求的识别。

❑需求的论证：为了实现该目标这个需求必须实现，那么该目标为这个需求的定义提供了合理性证明。

❑需求规约的完整性：将涉众的期望明确地描述为目标为需求规约完整性的检查和证明提供了便利。

❑冲突的识别与解决：冲突解决应当首先关注于解决冲突的目标,而不是由不同的期望导致的需求冲突本身。

❑目标的稳定性：一个目标通常存在多种实现方式。目标常常是不变的。和功能或质量需求相比，目标模型更稳定。

7.2 术语“目标”

目标是关于系统的目的、属性或者使用的意图。

7.3 AND/OR目标分解

系统愿景通常定义了系统的高层目标

其他所有目标都是对系统愿景 的精化。目标精化也被称作“目标分解”。

❑目标的AND分解：父目标G到一组子目标G₁,G₂,…,G₀(n≥2)的分解是一个AND分解，当且仅当为满足父目标G所有的子目标G₁,G₂,…,G,都必须满足。

❑目标的OR分解：父目标G到一组子目标G₁,G₂,…,G。(n≥2)的分解是一个OR分解， 当且仅当G₁,G₂,…,G.中任意一个子目标得到满足就能使父目标G得到满足。

7.4 目标依赖

定义了如下几种目标依赖：

❑“需要”依赖;

❑“支持”依赖;

❑“阻碍”依赖;

❑“冲突”依赖;

❑目标等价。

7.4.1 目标之间的“需要”依赖

“需要”依赖存在于那些相互之间没有分解关系的目标之间。

定义7-1:目标之间的“需要”依赖
如果满足G₂是满足G₁的前提，那么目标G₁“需要”依赖于目标G₂

7.4.2 目标之间的“支持”依赖

 如果目标G₁的(部分)满足能够导致目标G₂的(部分)满足，则G₁和G₂之间存在“支持”依赖。

定义7-2:目标之间的“支持”依赖
如果目标G₁的满足对于目标G₂的满足有正面影响，则G₁支持G₂。

7.4.3 目标之间的“阻碍”依赖

如果目标G₁的(部分)满足阻碍G₂的满足，则目标G₁和G₂之间存在“阻碍”依赖。“阻 碍”依赖可以理解为支持依赖的对立面。“阻碍”依赖不能存在于具有AND分解的目标之间。

定义7-3:“阻碍”依赖
如果目标G₁的(部分)满足阻碍目标G₂的满足，则G₁阻碍G₂。

7.4.4 目标之间的“冲突”依赖

 如果其中一个目标的满足完全排斥另一个目标的满足，则两个目标之间存在“冲突”依赖， 反之亦然。“冲突”依赖描述了一种很强的阻碍，而且是一种对称关系。

定义7-4:“冲突”依赖
 如果：
 (1)G₁的满足排斥G₂的满足，并且
 (2)G₂的满足排斥G₁的满足。
 则目标G₁和G₂之间存在冲突。

7.4.5 目标等价

如果一个目标的满足隐含着另一个目标的满足，则这两个目标之间存在“等价”依赖。“等价”依赖实际上是对称的。

定义7-5:“等价”依赖
 如果：
 (1)G₁的满足导致G₂的满足，并且
 (2)G₂的满足导致G₁的满足。
 则两个目标G₁和G₂是等价的。

第8章 描述目标

目标和目标依赖可以使用自然语言或专用的目标建模语言进行描述。

8.1 目标描述模板

目标描述模板，该模板由以下这些类型的属性组成:

 ❑作为目标唯一标识的属性;

 ❑管理属性;

 ❑描述上下文引用的属性;

 ❑目标的特有属性,即目标层次、目标描述、与其他目标的依赖关系,以及与场景的关系等；

 ❑描述任何其他附加信息的属性。

目标描述模板
目 标 模 板
编号	描述项	内容/解释
1	标识符	目标的唯一标识符
2	名称	目标的唯一名称
3	作者	描述该目标的责任者的名字
4	版本	目标文档的当前版本号
5	变更历史	对于目标描述的变更列表，包括(每一个变更的)变更时间、作者，如果需要还可以包括变更的原因和主体等
6	优先级	按照所使用的优先级策略设定的目标重要程度
7	关键程度	目标的关键程度，例如对整个系统的成功起关键作用等
8	来源	产生目标的来源，即涉众、文档、系统等
9	责任涉众	负责该目标的涉众的姓名
10	使用涉众	从该目标中受益的涉众
11	目标层次	目标所在的抽象层次的标识符
12	目标描述	按照8.2节中所定义规则来描述目标
13	父目标	对父目标的引用，包括分解类型(AND/OR)
14	子目标	对子目标的引用，包括分解类型(AND/OR)
15	其他目标依赖	与其他目标除分解关系之外的依赖，例如“需要”依赖、“冲突”依赖等
16	相关场景	对描述了满足或未满足目标的相关场景的引用
17	补充信息	关于该目标的附加信息

提示8-1:目标及目标属性的系统化抽取
❑首先设法抽取所有相关目标；
❑避免一开始就捕捉所有的目标属性；
❑定义目标属性时，首先定义基本属性(标识符、名称、来源、责任涉众、目标描述等);
❑然后，为每个目标定义父目标、子目标属性；
❑验证所抽取的目标是否完备、已描述的目标关系是否正确；
❑补充缺失的目标和目标关系，如果需要则对已定义的目标和目标关系进行修改；
❑定义支持目标抽取和验证的场景;
❑在目标模板中添加其他缺失的信息。
注：如果所抽取的信息不属于模板中任何一个属性，则将其加入到“补充信息”部分或在模板中定义新的描述属性。

8.2 目标描述的7个规则

易理解且详细的目标描述能够使得面向目标的需求工程发挥更大的作用。总结了这7个规则。

规则1:简明扼要地描述目标。

规则2:使用主动语态。避免使用被动语态。

规则3:准确描述涉众意图。

规则4:将高层目标分解为更具体的子目标。

规则5:说明目标所创造的价值。

规则6:描述引入目标的原因。

规则7:避免定义不必要的约束。

8.3 目标建模语言及方法

基于模板的目标描述和基于模型的目标描述是互补的。

目标模型定义如下：

定义8-1:目标模型
目标模型是一种描述目标、目标向子目标的分解关系，以及现有的目标依赖关系的概念模型。

目标建模方法在目标建模语言的基础上还提供了下列支持：

❑规则和指南：使其可以有目的地使用目标建模语言的建模元素来建立有意义的目标模型。规则和指南还可以支持工程师使用目标建模语言的建模元素描述已知的事实。

❑管理实践：管理实践为涉众规划、控制建模方法的应用提供支持。

8.4使用AND/OR树和AND/OR图进行目标描述

AND/OR树和AND/OR图是一种常用的支持目标描述的建模语言。

AND/OR 图在AND/OR树基础上进行了扩展，允许一个子目标关联到多个父目标。

8.4.1 使用AND/OR树进行目标建模

AND/OR树由代表目标的结点和代表目标分解的有向边组成。

定义8-2:AND/OR树(AND/OR目标树)
一个AND/OR目标树由代表目标的结点和代表目标间AND分解与OR分解关系的有向边 组成。每一个结点(除根结点外)仅与一个父目标相关联。

直角边表示AND 分解，直线边表示OR分解。

OR分解图

AND分解图

8.4.2 使用AND/OR图进行目标建模

不同于AND/OR目标树中的结点， AND/OR目标图中的结点可以有多条输入边。

定义8-3:AND/OR图(AND/OR目标图)
一个AND/OR目标图是一个有向无环图，其中结点代表目标，边代表目标之间的AND分解和OR分解关系。

8.4.3 AND/OR图中附加的目标依赖

定义8-4:AND/OR目标图中的“需要”关系
从目标G₁到目标G₂的“需要”关系表示一个“需要”依赖。“需要”关系由 G₁到G₂的有向边表示，它表示为了满足目标G₁,目标G₂必须被满足。

定义8-5:AND/OR目标图中的“互斥”关系
 目标G₁和目标G₂之间的“冲突”关系刻画了一个“冲突”依赖(见定义7-4)。它表示一 个目标的满足会阻碍另一个目标的满足。“冲突”关系由G₁与G₂之间的无向边表示。

冲突关系

需要关系

8.5  i*

 i*框架是一种全面的、用于目标和目标依赖分析及描述的方法。i*的基本思想是：一个参与者(actor)依赖于其他参与者来实现自己的目标。

8.5.1 i*框架中的建模元素

i*基于建模语言GRL(面向目标的需求语言)。

i*中的对象

 i*提供如图8-5左部的5种对象：

❑参与者：一个参与者是与待开发系统相关的人或系统。i*将参与者细化成以下3个子概念

 –主体(agent):主体是具有具体的物理表示的参与者；

 –角色(role):角色定义了参与者在特定上下文中的行为。一个参与者可以拥有多个角色，一个角色也可以被分配给多个参与者；

 –身份(position):身份是通常由一个主体扮演的一组角色的集合。一个主体可以具有多个身份。

❑目标：描述参与者期望达到的现实世界的某种特定状态。目标并不会指定如何达到这种状态。

❑任务：描述完成某些事情的特定方式。

❑资源：资源是参与者达到某个目标或完成某一任务所需要的(物理或信息)实体。

❑软目标：软目标是参与者希望达成的现实世界中的某种条件，与(硬)目标不同的是，要达到的相关条件的准则并没有严格定义。软目标通常是其他某个元素(即目标、 任务或资源)上的一种质量属性。

i*对象

i*中参与者之间的依赖

i*中的依赖刻画了依赖者与被依赖者之间的关系。依赖者和被依赖者都是参与者。

依赖者依赖于被依赖者来达成某个目标、完成某个任务或使用某个资源。

依赖对象(dependum)是被依赖者必须提供而依赖者所依赖的一种对象。

i*区分了4种类型的依赖:

❑目标依赖：目标依赖表示一个参与者(依赖者)依赖于另一个参与者(被依赖者)实现一个 所定义的目标(依赖对象)。依赖者假设被依赖者达成了目标，但并不指定是如何达成的。

❑任务依赖：任务依赖表示一个参与者(依赖者)依赖于另一个参与者(被依赖者)完成 分配给该参与者(被依赖者)的某个任务(依赖对象)。任务依赖表明了被依赖者必须完 成所分配的任务来达到某个目标，但是并没有说明为何要完成这个任务。

❑资源依赖：资源依赖表示一个参与者(依赖者)依赖于另一个参与者(被依赖者)所提 供的物理或者信息资源(依赖对象)的可用性。

❑软目标依赖：软目标依赖表示一个参与者(依赖者)依赖于另一个参与者(被依赖者)来完 成某个能导致特定软目标(依赖对象)实现的任务。软目标实现的准则并没有明确地给出。通

常，被依赖者提供多个实现该软目标的可选方案，而该软目标是否实现由依赖者来决定。

依赖关系

i*中对象间的关系

3种链接关系:

❑目的—手段链接：目的一手段链接描述了一个参与者为什么要达成某个目标、完成某个任务或使用某个资源。

❑贡献链接：贡献链接表示某个任务或其他目标对于软目标的正面(+)或者负面(-)影响。描述了一个任务或者软目标对满足某个软目标是否存在正面或者负面的影响。它并没有精确定义对其提供了何种支持或者所支持的程度。

❑任务分解链接：任务分解链接将任务及其组成部分联系起来，这些组成部分可以是子目标、子任务、资源或软目标的任意组合。任务分解可以包含必须完成的子任务、必须实现的子目标、所需的资源以及定义任务质量目标的软目标。

链接关系

8.5.2 策略依赖模型

i*框架区分两种目标模型:策略依赖模型(SDM)和策略原理模型(SRM)。

策略依赖模型(SDM)刻画了不同参与者之间的依赖。

它记录了哪些参与者依赖哪些任务、目标、软目标以及其他参与者提供的资源。

一个SDM包含一组参与者(结点)和一组参与者之间的依赖关系(边)。

8.5.3策略原理模型

策略原理模型(SRM) 详细描述了每个参与者，因此支持对SDM中所定义的参与者及其外部关系的推理。

SRM刻画了每一个参与者的内部原理结构。SRM通过目标、任务、资源和软目标以及这些对象之间的目的——手段链接、任务分解链接和贡献链接等方面来定义参与者的内部结构。

SRM提供了一种对涉众利益以及如何满足进行建模的方式。

KAOS模型空缺

第9章 场景基础

目标是描述涉众意图以及说明为什么要开发该系统的原理的重要手段。涉众在解释自己所想要的东西时，最自然的方式就是使用场景。通过使用场景，涉众可以通过具体、示范性的交互序列进行需求交流。

场景描述了一个目标(或者一组目标)被满足或者未被满足的一个具体实例。它提供了一个或多个目标的具体细节。一个场景通常定义了一系列为满足目标而执行的交互步骤，并将这些交互步骤与系统上下文联系了起来。

9.1 场景作为中间层抽象

场景充当介于抽象模型和现实之间的中间层抽象。

涉众可以根据所预期的在需求工程过程中的场景使用方式，来选择合适的场景描述抽象层次。

充当中间层抽象的场景

9.2 场景作为一种将需求置于上下文中的手段

需求只存在于特定的语境之中。场景特别适用于记录关于上下文的信息

场景中记录的典型上下文信息包括参与者、角色、目标、前置条件、后置条件、资源以及位置。

其中所描述的各类上下文信息包括：

❑参与者：参与者是与系统交互的人或其他系统。场景会指出每个交互步骤所涉及的参与者。场景还会记录参与者的一些重要特性，如他们的意图和角色。

❑角色：角色刻画了一种特定类型的参与者。因此，角色可以对场景中的参与者进行分类。角色可以按照具有该角色的参与者与系统所具有的关系或责任进行定义。

❑目标：场景描述了对目标的满足。

❑前置条件：前置条件是指为了执行某场景，在执行该场景前必须满足的一些条件。

❑后置条件：后置条件是指，在执行完某个场景之后，系统内部或者系统上下文应该满足的条件。

❑资源：资源是一种场景执行前必须满足的特殊前置条件。

❑场所：场景的场所是指执行该场景的现实或虚构的位置。

9.3 为每个上下文刻面开发场景

一个场景可以描述与一个或者多个上下文刻面相关的信息：

❑主体刻面：场景可以用来描述系统中所表达的相关上下文对象的信息更新。

❑使用刻面：场景被用于刻画使用工作流。

❑IT系统刻面：场景可以被用来刻画如维护、备份之类的过程。

❑开发刻面：场景可以被用来描述修改该系统的工程师与系统之间的交互序列。

需求工程中所开发的场景主要是使用场景。

第10章 场景类型

场景可以按照多种不同的标准进行分类。

一个场景可以描述系统及其上下文的当前状态或期望状态，由此可以区分出当前状态场景和期望状态场景。

场景可以是正面的或负面的。正面场景描述了能够使某一目标或一组目标满足的交互序列。负面场景则描述了那些导致某一目标或一组目标无法满足的交互序列。

不当使用场景(也称作不当使用案例)描述了具有恶意的参与者以违背系统意图的方式使用系统的交互序列。

场景的目的可以是描述、探究或解释交互序列。描述性场景用于表示支持需求抽取的交互序列。探索性场景描述了可能的替换实现方式。解释性场景为特定的交互或交互序列提供背景和原理性解释。

按照场景的抽象层次，区分实例场景、类型化场景和混合场景。实例场景描述了具体的参与者之间的具体交互序列。类型化场景对具体参与者及其交互进行了抽象。混合场景同时包含上述两种内容。

根据场景中所包含的上下文信息的范围，我们可以区分系统内部场景(A类型)、交互场景(B 类型)和上下文场景(C类型)。系统内部场景描述了系统内部的交互。交互场景描述了系统边界上的交互，即系统和外部参与者(人或系统)之间的交互。上下文场景描述了系统边界上的交互以及与系统上下文相关的附加信息。

主场景描述了满足一组特定目标的一般方式。可替换场景描述了满足一组特定目标的其他可能途径。例外场景描述了系统如何对异常事件进行响应以避免(关键性的)系统失效。

10.1当前状态场景和期望状态场景

当前状态场景支持在系统上下文中对于已有系统的建模，期望场景支持对于期望系统的建模。

当前状态场景

在创建已有系统模型的过程中，场景可以用于描述对当前系统的使用。用于支持当前状态建模的场景称作陈述性场景或当前状态场景。

期望状态场景

描述期望的系统 使用的场景被称作祈使式场景或期望状态场景，因为它们描述了一种所期望的但暂未实现的事实。

陈述性和祈使式场景是变更定义的重要驱动力。

10.2 正面和负面场景

正面场景

正面场景描述了能够使得与该场景相关(如果场景成功执行)的一组目标(即涉众意图) 得到满足的期望交互序列。

定义10-1:正面场景
正面场景描述了满足与该场景相关的一个目标或一组目标的交互序列。

负面场景

负面场景描述了未能实现某些所规约的系统目标的交互序列。

定义10-2:负面场景
负面场景描述了那些未能实现与该场景相关的一个或一组目标的交互序列。一个系统可以允许或禁止出现负面场景。

存在两种基本的负面场景类型：

❑允许的负面场景：对于允许出现的负面场景，系统需要支持其中所描述的交互序列，即 使某些目标无法得到满足。

❑禁止的负面场景：对于禁止的负面场景中，无法满足相关目标是不能容忍的。涉众必须采取适当的措施来防止所禁止的负面场景中所描述的交互序列的执行。

建议在需求工程中同时使用正面场景和负面场景。

10.3 不当使用场景

滥用(abuse)场景或不当使用(misuse)场景描述了违背系统目标的系统使用方式。

不当使用场景(有时也被称为不当使用案例)描述了恶意的参与者以违背涉众意图的方式使用系统的交互序列。

不当使用场景的执行表示了对于系统、涉众或系统上下文中其他系统的一种威胁。

定义10-3:不当使用场景
不当使用场景文档化了这样的一个交互序列，在该交互序列中具有敌意的参与者以违背涉众意愿的方式使用系统。

当待开发系统在根本上需要处理安全性和保密性问题时，不当使用场景将尤为重要。

10.4 描述性、探索性和解释性场景

描述性场景

描述性场景描述了相关的过程或工作流。描述性场景主要支持目标及面向方案的需求的抽取和精化。

探索性场景

创建探索性场景是为了对可能的候选方案进行探究和评价，从而支持方案的选择。利用探索性场景，涉众通常可以在需求工程早期就对可能的候选方案对系统使用的影响进行评价。

解释性场景

解释性场景用来解释某个目标、候选方案或交互序列。解释性场景通常包括对单个交互以及整个交互序列的原理解释。解释性场景还可以包含不同涉众的可选视图。

提示10-1:描述性、探索性和解释性场景
❑使用描述性场景说明目标和需求的含义，特别是用于详细描述创新性的想法和方案；
❑使用探究性场景支持决策。特别是当决策准则未知的时候，探索性场景有助于发现可 能的决策准则。如果多个不同的涉众从各自角度分别描述探索性场景，那么涉众间的 不同视角将变得清晰；
❑使用解释性场景说明复杂的事实。此外，使用解释性场景向未参加系统开发的人员说 明系统的附加价值。

10.5 实例和类型化场景

如果场景内容是在具体或实例层次上，该场景被称为实例场景。如果场景在抽象的或类型化层次上进行描述，那么该场景是类型化场景。

实例场景

实例场景描述了具体参与者之间具体的交互序列。实例场景中的交互描述了具体的输入和输出。实例场景中的参与者是具体的人，或具体的系统。实例层次的场景在文献中也被称为“用户故事”或“具体场景”。

类型化场景

类型化场景对特定交互序列中具体的参与者、输入和输出进行了抽象。类型化场景中使用的是参与者类型。类型化场景通过输入和输出的类型来描述交互。类型化场景的内容是对实际过程、人员、系统以及特定输入和输出的抽象。类型化场景也被称作“抽象场景”或“概念化场景”。

混合场景

混合场景同时包含实例层次和类型层次的内容。

混合多种抽象层次的原因如下：

❑场景的重要内容应该在实例层次上详细描述，不那么重要的内容应以一种抽象的方式描述；

❑未完全理解的内容在实例层次上描述。场景中已被充分理解的内容在类型层次描述；

❑冲突或可能发生冲突的内容在实例层次描述，以支持涉众间的交流和冲突解决。

提示10-2:在实例层次上描述场景内容
为了确定场景内容是否应当在实例层次上描述，应检查如下方面：
❑是否由于未充分理解相关内容而需要对其进行详细考虑；
❑相关内容中是否存在潜在的冲突；
❑相关内容是否非常重要。

10.6系统内场景、交互场景和上下文场景

系统内部场景(A类型化场景)

系统内部场景(A类型化场景)只关注系统内部的交互，即发生在系统边界之内的交互。

定义10-4:系统内部场景(A类型化场景)
系统内部场景只描述系统内部的交互，即系统不同部分之间的交互序列。

交互场景(B类型化场景)

交互场景描述了系统与系统参与者之间的交互序列。交互场景以一种面向使用的方式描述了系统如何嵌入到上下文之中。交互场景通常表示为用况。

定义10-5:交互场景(B类型化场景)
交互场景描述了系统与系统参与者(即系统上下文中的人和系统)之间的交互。

上下文场景(C类型化场景)

上下文场景(C类型化场景)除了描述系统及其上下文之间的直接交互外，还会描述上下文信息。

定义10-6:上下文场景(C类型化场景)
上下文场景描述了系统与系统参与者之间的直接交互，以及与系统使用或系统自身相关的附加上下文信息，例如参与者以及系统的非直接用户之间的交互。

提示10-3:A类型、B类型和C类型化场景
❑可能的话应总是在需求工程中使用上下文场景(C类型化场景),即以上下文信息丰富场景描述；
❑在上下文场景中描述重要的上下文方面，由此将面向方案的需求与上下文联系起来。只要需要，都应记录与场景及单个交互步骤相关的背景信息，例如场景的原理性解释、场景所创造的价值等；
❑从上下文场景(C类型化场景)中派生出系统内部场景(A类型化场景),以支持体系结构设计，即通过系统内部场景对上下文场景进行精化或细化。

10.7 主场景、可替换场景和例外场景

主场景

主场景描述了满足某一目标最常见的一种交互序列。主场景描述了满足目标的标准方式。

定义10-7:主场景
主场景描述了满足一组特定的目标通常需要执行的交互序列。

可替换场景

描述了对原始场景中的交互的修改后流程。某个主场景的可替换场景仍然满足与该主场景相关的目标。

定义10-8:可替换场景
可替换场景描述了可以替代主场景执行的交互序列，该交互序列的执行同样能满足与主场 景相关的目标。

例外场景

例外场景描述了系统应当如何响应在其他场景执行过程中，某些交互步骤上发生的异常事件。

定义10-9:例外场景
例外场景描述了当异常事件发生时代替其他场景(主场景、可替换场景或例外场景)执行的交互序列。异常事件的发生导致与原始场景相关的一个或多个目标无法得到满足。

建议将每个可替换场景和例外场景都与相关的主场景联系起来。

提示10-4:主场景、可替换场景和例外场景
❑为每一个主场景，定义系统必须支持的可替换场景；
❑此外，定义已知的例外场景，以应对已知的错误状态；
❑描述主场景中的哪些交互步骤可以被可替换场景替换；
❑描述例外场景应当被执行的条件。

10.8用况：场景的分类

 面向对象软件工程首次提出了用况(也叫用例，use case)的概念。用况将一个主场景与相应的可替换场景和例外场景组织在一起。

定义10-10:用况
一个系统、子系统或者类通过与外部对象交互以提供某种有价值的服务的过程中所能够执行的动作序列(包括变体序列和错误序列)的规约。

一个用况包括：

❑上下文信息：用况中的上下文信息包括与该用况相关的涉众目标、用况执行的前置和后置条件等;

❑主场景：每个用况只有一个主场景,该场景描述了满足与用况相关的一个或一组目标的典型交互序列；

❑可替换场景：一个用况可以有一个或多个可替换场景。

❑例外场景：一个用况可以有一个或多个例外场景。

用况场景

将由用况显式或隐式定义并且可以导致用况按照预定的方式终止的所有交互序列的集合称为用况场景。

定义10-11:用况场景
用况场景是由用况中所定义的主场景、可替换场景和例外场景所产生的，并且可以导致用况按照预定的方式终止的合法交互序列。其中，终止意味着与该用况相关的目标得到了满足或者该用况按照预定义的方式中止执行。