| 需求工程:基础、原理和技术4 |
| 波尔(Klaus Pohl) |
| 计算机科学丛书 |
| 11：描述场景、12：使用目标和场景的优势 |
第11章 描述场景
11.1 叙述性场景
叙述性场景使用自然语言描述交互序列。
在需求工程中，叙述性场景是支持系统及其上下文知识抽取的重要手段。在叙述性场景内，信息可以在不同抽象层次上进行交流。
提示11-1:叙述性场景使用叙述性场景为了：
❑抽取与上下文相关的信息；
❑抽取与目标和需求相关的信息。
通过结构化文本场景以及定义可替换场景、例外场景、描述性场景和解释性场景，来对叙 述性场景的重要方面进行细化。
11.2 结构化场景
通过结构化的方式描述交互步骤和/或上下文信息，可以显著改进使用自然语言描述的场景的可读性和可理解性。
11.2.1 场景步骤的结构化描述
两种对于场景交互序列的结构化文本描述方法：
❑枚举场景步骤；
❑交互序列的表格化描述。
枚举场景步骤意味着将各个交互步骤分离出来并按顺序编号。
表格化描述，每一个场景步骤都在一个单元格中被描述，表格中每一列表示一个参与者。场景步骤分行逐一编号、描述，并且按照交互顺序从上至下执行。每个场景步骤显示在与执行步骤的参与者所对应的列中。如果需要，还可以在一行中显示多个交互步骤，以表示这些交互是并行执行的。
提示11-2:场景的结构化描述
在最终的主场景、可替换场景和例外场景文档中使用表格式描述。为每个交互步骤进行编号，并且按照启动步骤或由负责步骤的参与者将它们输入到对应的列中。
注解：不要过早使用表格式描述。首先尽量发挥叙述性场景的优势，从而能够抽取丰富的需求内容，例如面向方案的需求、目标、上下文信息以及进一步的交互步骤。随后，通过表格的方式更加准确地定义场景的交互步骤。表格式的描述同样简化了开发过程中对于场景的进 一步使用。
| 表11-2 使用自然语言的场景描述模板 | ||
| 场 景 模 板 | ||
| 编号 | 描述项 | 内容/解释 |
| 1 | 标识符 | 场景的唯一标识 |
| 2 | 名称 | 场景的唯一名称 |
| 3 | 作者 | 场景描述的作者名 |
| 4 | 版本 | 当前场景描述版本号 |
| 5 | 变更历史 | 当前场景的一系列变更记录，包括每次变更的时间、版本号、作者，需要的话还可以包括变更的原因和主体 |
| 6 | 优先级 | 根据所使用的优先级技术，指明所描述场景的重要性程度 |
| 7 | 关键性 | 场景的关键性，例如直接影响系统的成功 |
| 8 | 来源 | 场景的来源类型(涉众、文档或系统) |
| 9 | 负责涉众 | 负责该场景的涉众 |
| 10 | 简述 | 对场景的简要描述(大约1/4页) |
| 11 | 场景类型 | 基于第10章中的场景类型进行分类，例如上下文场景、交互场景、系统内部场景等 |
| 12 | 目 标 | 执行当前场景应当满足的目标，包括指向相关目标定义的标识符相关规则: ❑明确地对场景目标进行命名(规则10); ❑关注于目标的实现(规则11) 目标描述规则: ❑简明扼要地描述目标(规则1); ❑使用主动语态(规则2); ❑准确描述涉众意图(规则3); ❑将高层目标分解为更具体的子目标(规则4); ❑说明目标所创造的价值(规则5); ❑描述引入目标的原因(规则6); ❑避免定义不必要的约束(规则7) |
| 13 | 参与者 | 指明主要参与者和其他参与者相关规则: ❑明确命名参与者(规则9) |
| 14 | 前置条件 | 在场景开始执行之前必须满足的一系列先决条件 |
| 15 | 后置条件 | 在场景执行之后必须满足的一系列条件 |
| 16 | 结果 | 对于在场景执行期间所产生的输出的描述 |
| 17 | 场景步骤 | 详细的场景交互序列：叙述性/顺序编号/表格式相关规则 ❑使用一般现在时(规则1); ❑使用主动语态(规则2);” ❑使用主谓宾句式结构(规则3); ❑避免情态动词(规则4);” ❑每句话只描述一个交互(规则5); ❑对每个场景步骤编号(规则6);” ❑每个场景只有一个交互序列(规则7); ❑从“远角视图”描述场景(规则8); ❑明确命名参与者(规则9); ❑关注于说明目标是如何满足的(规则11) |
| 18 | 质量 | 对质量需求的交叉引用 |
| 19 | 相关场景 | 与当前场景相关的其他场景 |
| 20 | 补充信息 | 关于当前场景的其他信息 |
11.2.2 场景参考模板
提示11-3:系统化的场景描述
❑避免立即完成场景的所有属性描述；
❑抽取出一组初始的基本场景，即对于这些场景只填写基本属性，如标识符、名称、来 源、负责涉众、简述和场景类型；
❑将场景所满足的目标与相应的场景关联起来；
❑确保对每一个相关场景都进行考虑，例如通过检查系统定义的每一个目标是否都能找到满足目标的场景；
❑如第二步那样描述丢失的场景；
❑完成场景模板中剩余的属性，完成场景描述。
注意：当抽取一组初始的基本场景时，可能会收集到一些超出基本场景描述所需的信息。 此时，不要丢弃信息，而是进行记录以供此后完善信息时使用。
11.3 用况描述模板
用况（用例）描述可以类似于场景描述那样使用参考模板。用况的参考模板是在使用自然语言的用况结构化描述专家知识基础上定义的。
提示11-4:用况模板
❑通过使用参考模板，你可以利用关于用况描述的专家知识，即需要描述的信息类型以及这些信息的组织和呈现方式。因此，要确保最终每个用况都是基于一个通用的参考模板进行描述的。
❑初始时，使用标准用况模板。另一方面，当积累了足够的使用用况模板的经验后，可以考虑根据所属项目或组织的特殊需要对参考模板进行调整。
❑如果你暂时没有填写模板中某项属性的信息，那么填写“TBD”(待定)来表明这个属性需要在此后某个时间再次考虑。
| 提示11-5:系统化的用况描述 ❑避免立即完成用况的所有属性描述； ❑首先抽取出一组初始的基本用况。对于这些用况，先填写基本属性，如名称、来源、负 责涉众、简述、目标和主参与者； ❑定义用况之间以及用况和系统目标之间的关系； ❑确认所描述的用况集合是足够完整的，例如通过检查用况和系统目标之间的关系来确定； ❑完成一组用况描述后，为每个用况定义主场景、结果和“其他参与者”; ❑随后，识别可替换场景和例外场景； ❑最终，完成用况描述中的剩余描述项。 注意：抽取基本用况时，你可能会收集到超出基本用况描述所需的信息。此时，不要丢弃 这些信息而是进行记录以供以后使用。 |
| 表11-4 用况描述参考模板 | ||
| 用 况 模 板 | ||
| 编 号 | 描述项 | 内容/解释 |
| 1 | 标识符 | 用况的唯一标识符 |
| 2 | 名称 | 用况名称 |
| 3 | 作者 | 用况描述的作者名 |
| 4 | 版本 | 当前用况版本号 |
| 5 | 变更历史 | 一系列用况变更记录，包括每次变更的时间、版本号、作者，需要的话还包括变更原因和主题 |
| 6 | 优先级 | 用况的重要性程度和级别 |
| 7 | 关键性 | 用况对于整个系统成功的关键性 |
| 8 | 来源 | 用况的来源类型(涉众、文档或系统) |
| 9 | 负责涉众 | 负责该用况的涉众 |
| 10 | 简述 | 对用况的简要描述(大约1/4页) |
| 11 | 用况层次 | 当前用况描述细节层次，例如分为概览、用户级、功能组级等 |
| 12 | 目标 | 执行用况场景应当满足的目标，包括指向相关目标定义的标识符相关规则 ❑对场景的目标明确地命名(规则10); ❑关注于目标的实现(规则11)目标描述规则 ❑简要描述目标(规则1); ❑使用主动语态(规则2); ❑精确描述涉众意图(规则3); ❑将高层目标分解为具体的子目标(规则4); ❑陈述目标的附加价值(规则5); ❑描述引入目标的原因(规则6); ❑避免定义不必要的限制(规则7) |
| 13 | 主参与者 | 指明主要参与者(从用况的执行中受益最多的参与者)。主参与者通常会启动用况的执行 相关规则： ❑明确命名参与者(规则9) |
| 14 | 其他参与者 | 确定用况中其他所有参与者相关规则： ❑明确命名参与者(规则9) |
| 15 | 前置条件 | 在用况启动执行之前必须满足的一系列必要条件 |
| 16 | 后置条件 | 在用况执行之后应该满足的一系列条件 |
| 17 | 结果 | 对于在用况执行期间产生的输出的描述 |
| 18 | 主场景 | 对用况主场景的描述相关规则 ❑使用一般现在时(规则1); ❑使用主动语态(规则2);” ❑使用主谓宾句式结构(规则3); ❑避免情态动词(规则4);” ❑每句话只能描述一个交互(规则5); ❑对每个场景步骤进行编号(规则6);” ❑每个场景只包含一个交互序列(规则7); ❑从“远角视图”描述场景(规则8); ❑明确地命名参与者(规则9);” ❑关注于目标满足过程的阐述(规则11) |
| 19 | 可替换场景 | 描述用况的可替换场景相关规则❑见描述项18—“主场景” |
| 20 | 例外场景 | 描述用况的例外场景相关规则❑见描述项18—“主场景” |
| 21 | 质量 | 对质量需求的交叉引用 |
| 22 | 与其他用况的关系 | 与其他用况关系(例如扩展、包含、泛化关系等)的简要描述 |
| 23 | 补充信息 | 关于当前用况的附加信息 |
11.4 场景描述的11条规则
将这些规则分为：
❑关于场景的语言和语法的规则；
❑关于场景结构的规则；
❑关于场景内容的规则。
语言和语法规则
规则1:使用一般现在时描述场景。场景描述了示例性的交互过程。使用一般现在时可以 使交互描述更加生动、更加容易理解。
规则2:使用主动语态描述场景。使用主动语态使得交互的执行者或发起者更加清晰。所描述的场景将每个动作分配给执行该动作的人或系统，由此避免了与交互发起方相关的歧义。
规则3:使用主谓宾句式结构。关注于场景的本质部分。
规则4:避免使用情态动词。
结构规则
规则5:明确地将每个交互与其他交互区分开。避免在同一句子中描述多个场景。
规则6:为每个场景步骤编号。对各个场景进行唯一编号能够提高场景的清晰性并有利于对场景步骤的引用。
内容规则
规则7:每个场景只包含一个交互序列。
规则8:从外部视角描述场景。避免描述不必要的场景细节。
规则9:明确地命名相关参与者。
规则10:明确陈述场景目标。场景描述了一次成功或失败的目标满足过程。
规则11:关注于证明目标是如何被场景满足的。描述场景是如何成功满足。避免描述不必要的信息，即无助于说明目标满足过程的信息。
11.5顺序图
常用的基于模型的场景描述语言是消息序列图。
统一建模语言(UML)通过顺序图支持交互序列的描述。UML顺序图基于消息序列图。
一个顺序图描述了一组角色之间的消息交换序列。
UML顺序图中的角色可以表示一个待开发的系统、系统的一部分，或者一个外部参与者。
顺序图中的每个角色都表示为一条生命线，即表示角色在一段时间期间内的存在性的一条垂直线。角色生命线上的竖条表示角色在这段时间内是激活的。
消息表示为生命线之间的水平箭头。由一条生命线到另一条生命线的消息表示相应角色之间的一次交互。UML区分不同类型的消息，表示为不同的箭头样式。
提示11-7:使用顺序图描述场景
❑使用顺序图对已经充分理解的主场景、可替换场景和例外场景进行结构化的描述；
❑对可替换场景和例外场景使用能表明其特征的名称；
❑使用顺序图时，关注于对满足目标有贡献的交互；
❑避免在过于细致的(如算法)层次上描述交互，反之以一种远角视图进行描述；
❑如果顺序图过于复杂，使用组合片断“ref”将顺序图划分为多个图；
❑避免大量使用“alt”、“break”等组合片断，因为这违反了“每个场景只包含一个交互序列”的规则;
❑恰当使用注释可以让阅读、理解顺序图更加容易。
**注：顺序图主要用于对主场景（主要的交互活动）进行结构化描述。顺序图体现的重点是在参与者之间以时间为尺度，顺序上的信息交互。一般情况下，顺序图用于描述相对简单的交互顺序过程，不体现过度复杂算法。顺序图原则上支持通过使用选择交互块来进行分支候选路径，但不被建议这么做，因为会违反场景交互规则尽量单一的规则。所以，用顺序图最适合的就是阐明一个操作过程的时序梗概，用于大致说明情况。
纵向的轴为各参与者的生命线，生命线从上往下，表示时间在顺序方向上的流动。生命线上的方块表示时序上的激活期，激活期表示响应消息并工作，并给出反馈的一个时间段过程。
消息是有方向的，由参与者到接受者。分为同步（实心箭头）和异步（线性箭头）两类。同步消息发送到给目标，必须等候反馈，否则发送者会阻塞。异步消息发送给目标，不会阻塞等待反馈。消息反馈（虚线箭头）是从激活期工作结束后，反转消息方向，向原先消息发送方的一个回应消息。
11.6 活动图
UML顺序图强调的是系统与一系列用户随着时间的交互序列。
活动图则侧重于描述在多个场景之间的控制流。
活动图的主要关注点是控制流，即不同参与者的活动以及这些活动可能的顺序。
图11-4 UML活动图中的重要建模元素
活动图是一种控制流图。
活动图特别适合于描述主场景、可替换场景以及例外场景的相互关系和执行条件。决策点描述了主场景与可选场景、例外场景之间的控制流分支。
提示11-8:在活动图中描述多个场景的控制流信息
❑使用活动图来描述：
—-多个场景之间的控制流；
—-主场景、可替换场景以及例外场景之间的关系。
❑在存在许多可替换场景和/或例外场景的情况(即存在许多合法的执行线程时)下，尤其应当使用活动图。
❑在如下情况下应当避免使用活动图来描述场景间的控制流信息：
—-主场景的交互序列未被很好理解；
—-可替换场景和例外场景还没有得到充分理解，以及(或者)它们与主场景的关系还不够清晰。
11.7 用况图
用况图不适合用来描述系统与参与者之间的交互(序列)。
然而，用况图却特别适合用于系统中不同用况之间以及参与者与用况之间关系的可视化描述。
用况图中最重要的建模元素：
❑参与者(系统或人):参与者表示处于系统边界之外、与待开发系统存在交互的系统或人。如果参与者表示人，那么将其画成小人图标。如果参与者表示系统，则将其画成方框。
❑用况:待开发系统的用况用椭圆表示。用况的名称显示在椭圆里面。
❑系统边界：系统边界将系统与其所处的环境(可视化地)分隔开来。系统边界用矩形表示。系统的用况画在边界以内。
❑参与者与用况之间的关系：参与者与用况之间的关系表示该参与者在执行该用况的过程中与系统存在交互。关系用实线表示。
❑用况之间的关系：
—-泛化关系：从用况A到用况B存在“泛化”关系表示用况B是用况A的一个泛化。特化用况A继承了泛化用况B所包含的交互步骤。
—-扩展关系：从用况A到用况B的“扩展”关系表示用况A(扩展用况)所包含的交互序列在所定义的扩展点上扩展了用况B(被扩展用况)所描述的交互顺序。
—-包含关系：从用况A到用况B的“包含”关系是指用况A包含了用况B中的交互序列。当两个或多个用况的交互序列中包含共同的部分时使用“包含”关系。其中共同的部分被提取到一个单独的用况中，被其他用况所包含。通常，包含用况中的交互顺序是不完整的，要基于被包含用况才能表达完整的含义。
图11-6用况图的重要建模元素
提示11-9:用况图的规模
创建用况图时要遵循的一条简单规则是它应该包含5～7个用况。如果用况图包含的用况过少，那么可能表示：要么是用况的抽象程度过高，要么系统边界划得过窄。如果系统需要明显多于5～7个的用况来描述，那么该系统可以划分成多个逻辑组件，然后再为每个组件创建用况图。然而，过多的用况也可能表明用况描述过于细致。要判断用况描述是否处于合适的细节程度上，应当应用11.4节中介绍的规则。
提示11-10:对场景和用况的描述
推荐将使用自然语言和基于模型这两种方式结合起来描述用况和场景：
❑使用用况模板来描述上下文信息，以及主场景与可替换场景、例外场景间的关系。
❑在用况模板中使用顺序图来描述用况中的交互顺序。如果由于所涉及的涉众使得顺序图不太适合，那么使用列表的方式描述交互序列
❑使用活动图对已得到充分理解的主场景、可替换场景以及例外场景之间的关系进行描述。
❑使用用况图来提供关于用况间关系以及参与者与用况间关系的概况。
11.8需求工程过程中不同场景类型的使用
| 不同场景类型和表达方式的适用性 | |||
| 场景类型/表达方式 | 适用于 …… | ||
| 需求工程过程 | 需求规格说明 | ||
| 内容 | 叙述性场景 | *** | 一 |
| 当前状态场景 | *** | * | |
| 期望状态场景 | *** | *** | |
| 正面场景 | *** | *** | |
| 负面场景 | *** | *** | |
| 不当使用场景 | *** | *** | |
| 描述性场景 | ** | *** | |
| 探索性场景 | *** | 一 | |
| 解释性场景 | *** | * | |
| 实例场景 | ** | * | |
| 类型化场景 | * | *** | |
| 混合场景 | *** | ** | |
| 系统内部场景 | * | ** | |
| 交互场景 | ** | *** | |
| 上下文场景 | *** | *** | |
| 主场景 | *** | *** | |
| 可替换场景 | ** | *** | |
| 例外场景 | ** | *** | |
| 用况 | *** | *** | |
| 表示格式 | 文本(结构化)场景 | *** | 一 |
| 基于模板的场景和用况 | ** | *** | |
| 顺序图 | ** | *** | |
| 活动图 | – | ** | |
| 用况图 | ** | ** | |
第12章 使用目标和场景的优势
12.1 目标导向的优势
12.1.1 对于文档化的帮助
需求工程中的文档化的目的是以一种合适的方式记录关于需求和上下文的知识。
目标可以用来检查所记录的需求或需求文档的完整性。假设目标是完整的，那么当该条件满足时可以认为需求也是完整的。
通过明确地考虑目标，可以识别出不相关的需求。不相关需求的一个标志就是该需求不和任何目标相关，也就是该需求对任何目标的满足都没有贡献。
目标可以用来组织需求文档的结构。需求文档的结构可以根据目标的分解结构来组织。
需求文档中的每个需求都是为了实现一个或者多个目标。
12.1.2 对于抽取的帮助
目标记录了涉众对于系统的意图。
使用目标来指导需求抽取，以一种清晰的对于目 标满足的关注来支持对于需求的系统化抽取。
目标导向支持对潜在的实现方案的识别。目标首先被分解为一系列可选的子目标。
每个子目标的相关的场景和面向方案的需求可以帮助涉众评估父目标的各种实现方式。
场景提供了对于目标满足的正面和负 面示例。
12.1.3 对于协商的帮助
涉众往往会从不同的视角来观察待开发系统。协商活动的目的是统一涉众们各自的视角，以得到一种更好的、完全统一的系统需求视角。
面向方案的需求中的冲突往往是由不同涉众对系统的不同意图而引起。目标可以(也应该)帮助澄清所发现的需求冲突是否由涉众的意图和目标的冲突所引起。
12.1.4 对于确认的帮助
需求确认的目的是在早期阶段就确保所开发的系统是正确的。是指所开发的系统满足所有相关涉众的愿望和期望，并符合所有约束。
可以基于所描述的系统目标进行系统确认。如果目标不能被相关需求的实现所满足，那么这些需求就可能是不完整的或者存在缺陷。
12.1.5 对于管理的帮助
目标有助于需求工程中的管理活动。目标特别有助于需求的优先级确定以及需求追踪关系的建立。
明确地考虑目标有助于对需求的分级。
明确地描述目标有助于以一种项目特定的方式建立需求追踪关系，以及支持对需求来源的追溯。
12.2 使用场景的优势
12.2.1 有助于文档化
场景可以用来帮助获取关于开发刻面的上下文信息。
场景也可以作为需求文档的组织结构使用。
场景通过实例的方式为面向方案的需求提供解释。
场景将需求置于通常的使用上下文之中。
12.2.2 有助于需求抽取
使用场景是辅助需求抽取的一种重要手段。场景有助于在需求抽取过程中抽取知识以及理解涉众的需要和意图。
场景为需求交流和沟通提供了一种直观的方法。
通过使用场景，未被充分理解的系统上下文方面可以很容易地进行解释和交流。
12.2.3 有助于协商
场景可以用来分析和解决需求冲突。
通过使用场景来说明冲突，这有助于冲突的识别、交流和解决。
在冲突分析中创建场景有利于检测引发冲突的真正原因。
可以使用场景以一种所有涉众都可以理解的方式来记录多个可替换的方案。因此，场景有助于共识的达成。
12.2.4 有助于确认
场景描述了预期的系统使用方式的实例。通过场景可以向涉众介绍复杂的需求，而涉众则可以以一种可理解的方式 进行需求确认。
以通过检查需求的实现是否能满足正面场景并且避免负面场景和不当使用场景来检测需求中不完整、不正确和不一致的地方。
场景还可以用于识别需求文档中的无关需求。
12.2.5 有助于管理
在需求管理活动中，场景可以辅助进行需求的优先级划分。
适合用来确定项目中所需要的可追踪性信息。
场景通过建立起面向方案的需求与目标之间的联系，来帮助管理面向方案的需求。
场景中包含的上下文信息有助于对变更请求进行评估。
12.3 将目标与场景相结合的好处
目标和场景之间的相互依赖关系
12.3.1 目标发起对场景的定义
场景描述了满足或者不能满足这个目标的典型交互序列。
如果目标模型中的目标进行了修改，那么在多数情况下也将导致对相关场景的修改。
12.3.2 目标对场景进行分类
场景描述了对某些目标的满足或不满足。因此，每个场景都可以与其(部分或者完全地) 满足的目标相关。
❑满足目标的场景：主场景和可替换场景。
❑不满足目标的场景：例外场景。
❑违反目标的系统使用场景：不当使用场景。
12.3.3场景描述对目标的满足情况
场景通过示范性的交互序列来阐述对目标的满足情况。例如：
❑满足目标的示例；
❑未能满足目标的示例；
❑恶意违反目标的示例，即对系统的不当使用。
12.3.4场景发起对目标的细化
使用场景阐述目标的满足情况往往会引起对目标的细化。包括如下几种情况:
❑目标分解，即识别出新的子目标；
❑识别出新的独立的目标；
❑修改或移除已有目标。
目标分解
当通过场景的方式来对目标进行具体化分析时，可能会识别出该目标的新子目标。为已有目标定义子目标的过程称为目标分解。
识别新的、独立的目标
场景描述目标的满足情况时，可能会识别出全新的目标，即独立的目标，而非与该场景相关的某个目标的子目标。
修改/移除目标
通过场景的方式对目标进行具体化还可能引发修改或移除与该场景相关的目标。目标与场景之间的这种交互对于目标模型的确认尤为重要。