3.7 使用场景技术的需求获取
在开发人员与用户的交流中，场景作为工具可发挥较大作用。开发人员在与用户进行有关软件需求的谈话和交流中，谈论具体事例的情况较多，用户也经常结合专业知识讲述他们的具体工作和工作流程。因此，场景很自然地作为交流的工具使用，每个场景可以对应系统的一个潜在的需求。
3.7.1 场景的定义及构成
所谓场景是指用户与软件系统为实现某个目标而进行交互活动过程的描述。
场景可视为是对使用系统经历的解释。软件开发人员可利用场景来模拟用户与软件系统为完成某个功能而进行的交互活动过程，通过分析来获取其中有用的需求信息。对于较为复杂的软件系统，通常需要许多场景。
场景的构成可以有不同的形式，应由如下几个方面的内容构成：
执行者（用户）
进入场景前系统状态的描述
执行者的目的
动作和事件系列（包括正常或非正常事件流）
上述４个方面的内容既可以以简洁的方式填写也可部分省略不写。
通常，场景应具有下述特征：
场景代表某些用户可见的功能，可用于描述一个具体的系统功能；
场景总是被参与者启动，并向参与者提供可识别的信息；
场景必须是完整的。
图3-2表示了一个用自然语言描述的某人切断ＰＣ电源的场景。在这个场景中，用户顺序地描述了如何退出Wｉｎｄｏｗｓ ９８，并切断ＰＣ电源的一系列交互活动。
王某是使用装有Windows 98系统的ＰＣ用户，已有一年的经验。他几乎每天使用ＰＣ向朋友发电子邮件，今天在发送了４封电子邮件后想切断ＰＣ电源。
王某首先按下屏幕中的“开始”按钮，在显示出来的菜单中选择“关闭计算机”选项。在屏幕中央出现了与关闭计算机相关的对话框，询问用户是否真正关闭计算机。王某确认并按下了“关闭计算机”的按钮。计算机在使屏幕变黑后，自动切断ＰＣ电源。
图3-2表示的场景可使用前述的描述形式具体表示如下：
执行者（用户）：王某
进入场景前系统状态的描述：使用ＰＣ的经验是1年，几乎每天使用。另外，今日发送电子邮件的工作已结束。
执行者的目的：退出Windows 98，并切断ＰＣ电源。
动作和事件系列：图32中的第2段文字,从按下“开始”按钮到切断ＰＣ电源的事件完成为止。
3.7.2 场景的表示
除了可用自然语言表示场景外，也可使用图形、动漫画等其他表示形式。场景也可与快速原型方法结合使用。此外，也可利用一些已有的半形式化的图形表示方法和技术(如流程图、状态图、时序图)以及形式化的方法和技术(如CCS、CSP、Z语言等)来表示场景。场景的一些典型表示形式如表32所示。
场景的使用者可以根据具体情况有选择地使用上述表示形式，也可组合使用几种表示形式。对于某些水平较高的专业技术人员，可以使用更加适合的特殊人工语言来描述场景。但是，在需求信息的获取中，由于用户的参与相当重要，使用非形式化的表示形式是合适的，形式化的表示形式对于用户来说难以理解。
3.7.3 场景的种类
场景描述了执行者的目标，但该目标能否实现决定了场景可大致分为正常场景和失败场景两类。场景的分类将有助于对场景的分析。对于正常的场景，主要注重于目标的实现过程以及效率如何。对于失败的场景，注重于分析失败的理由。如果找到了执行者不能达到目标的理由，将成为改进软件系统的参考因素。
更进一步，根据场景描述的内容可分为正向场景和逆向场景（AntiScenario）。前者描述所希望实现的目标、与目标相关的执行者和事件等，后者描述用户所不希望的需求，描述的功能将不能写入需求规格说明中。逆向场景作为描述的工具对于收集需求信息的初期是有效的，经过事先的分析将有利于防止混入一些无用的需求信息。
场景之间亦可以建立关系以及精化处理。例如，当向一个场景中添加一些动作构成了另一个场景时，这两个场景之间的关系就是扩展关系，后者继承前者的一些行为。当一个场景使用另一个场景时，这两个场景之间就构成了使用关系。一般说来，如果在若干个场景中有相同的动作，则可以把这些相同的动作提取出来单独构成一个场景。大部分场景将在项目的需求获取阶段产生，并且随着需求分析工作的深入还会发现更多的场景。这些新发现的场景都应及时补充进已有的场景集合中。
3.7.4 使用用例的需求获取
实际上，关于场景的定义有许多，例如，Bermer和Johnson定义的场景［15］，以及Kotonya和Sommerville［16］定义的场景。本节将主要介绍由Jacobson［17］定义的与场景相关的用例（usercase）这一需求获取技术。用例与前述的场景并不是同一概念。用例通常用于描述可发生的所有事件序列，而场景则是描述其中的一部分。因此，用例也可以说是场景的集合，一个场景是用例的实例。
Jacobson提出的用例用于描述软件系统与一个外部“执行者（actor）”的交互顺序，它体现了执行者完成一项任务的过程。执行者可为一个人或一个应用软件系统，也可以是硬件或是某些与软件系统交互以实现某些目标的外部实体。在利用用例建立系统模型时，软件系统被视为一个黑盒子，并可使用自然语言顺序地描述软件系统与外部执行者的相互作用。下面，我们以自动取款机（ATM）为例来说明。
例ＡＴＭ的用例模型和取现金的用例如图３３和图３４所示［18］。图３３表示与ＡＴＭ相关的用例模型。图３４用结构化自然语言的形式描述ＡＴＭ正常工作的用例。
实际上，用例的定义也有不同的表示形式［19，20］。例如，为便于描述和提高重用性，可利用如下所示的结构化形式：
执行者：用例的主导者。
目的：用例的目的。
前提条件：启动用例的条件。
结束条件：用例结束时应满足的条件。
基本序列：描述在满足前提条件下启动用例后，按时间顺序正常发生的执行者与软件系统的相互作用。
异常序列：按时间顺序描述在正常序列的相互作用中发生异常情况时，软件系统与执行者的相互作用。
备注：应向设计者转达除功能需求以外的非功能需求、设计约束条件和限制，以及有待解决的事项等。
３.７.５ 场景技术的特点
场景技术不仅把软件系统的需求信息文本化，而且有助于在实现软件系统前明确用户与软件系统的相互作用。此外，场景技术还具有如下特点：
可以把当前系统存在的问题作为实例记录下来。
可以成为项目相关人员间的共同语言。
由于场景描述了软件系统的操作，比较具体，易理解性较好。
通过场景使得提出和获得需求的双方之间能建立起相应的理解。
另一方面，在使用场景技术时，也要注意如下问题：
场景的数量，即一个软件项目应该写多少个场景没有限制标准，主要视项目的规模和复杂性而定。但如果场景数量过大，易加大分析和理解的难度。
场景的冗余问题。应尽量避免场景描述的内容发生重叠，可根据实际情况合并和去掉一些内容重叠的场景。
应防止场景描述内容的冗长。