看完后我觉得对于做产品的人也是如此，我们可以通过穷举法来发现或想象和制作很多的用户使用场景。但能这样的场景不一定是真切和正式的，但对于指导我们的产品策划设计工作还是有不少的益处的。

原文的内容如下：

2.1.1 创建非正式场景指南

尽管我们称这部分软件开发过程是非正式的，但仍然有一些指南可用于建立这些非正式场景，以获得最大效益。这些指南如下：

1)一个软件系统应该是由一些较小的非正式场景构成，而不是一个大的非正式场景。

2)一个非正式场景应关注系统的一个相关方面。例如，用户登录系统、服务器处理用户提交的时间卡、一次用户查询、用户领取工资等。

3)每个非正式场景应该尽可能详细地指出具体值。学生们不应该写”用户通过鼠标点击，消除了相应格子内的小球”，而应该说”王卉观察己方对应的蓝色 小球，找到两个相邻小球，在其中一个小球的位置点击鼠标，消去小球，又在剩余时间片内，消去了暂不构成威胁的三个小球，其中由于点击位置失误，消去了一个 对手方的红色小球”。后一种说法包含了管理用户在一个时间片内消去小球操作的潜在复杂性，而前一种说法则没有。

4)在非正式场景中，应该描述系统将要处理的几类用户错误，但不应该试图穷举覆盖所有可能的错误。

5)在表示每个非正式场景中，实现细节应该省略。例如，每个非正式场景都不应该提到链表或其他数据结构。

6)每个场景都应该描述场景初始化前的系统状态。例如，用户点击鼠标非正式场景应描述用户点击前游戏面板的状态。

7)每个场景应在指明下一个场景时才结束。

创建非正式场景的常见问题是太抽象而不够具体。用抽象术语刻画系统使用的问题在于抽象描述不如详细讨论情形所体现的系统复杂性来得明显。创建非正式场景的目的是帮助开发人员获得对待开发项目的深入理解。

要点2-1   创建非正式场景

（1）非正式场景要短；

（2）非正式场景应指明一个活动；

（3）非正式场景应指出具体值；

（4）非正式场景可以指明几类用户错误；

（5）应忽略实现细节；

（6）应该描述初始化之前的系统状态；

（7）应指出下一个场景。

2.1.2 非正式场景示例：用户一个时间片内的鼠标点击

当前系统状态

系统状态由每个玩家在游戏面板上不同颜色小球的分布构成。游戏中有两个玩家，王卉和王艳，每人分配一种小球颜色，王卉对应蓝色，王艳对应红色，游戏 面板格子中存在5个不相邻的蓝色小球和5个不相邻的红色小球。游戏开始时根据难度设置，随机生成3个蓝色小球和3个红色小球。其中一个蓝色小球恰好与原有 蓝色小球相邻。

非正式场景

接下来王卉和王艳开始寻找己方的相邻小球，王卉找到一对相邻蓝色小球，通过鼠标点击消除其中一个，又在剩余时间内消除了两个蓝色小球。然后，由于点 击失误，消除了一个红色小球。同时，王艳没有找到相邻的红色小球，就随意消除了两个未相邻的红色小球。这时时间片结束，系统判断双方均无剩余相邻小球，该 轮次结束。

下一场景

下一场景是系统新生成两种颜色的小球各3个，双方进入下一时间片的比赛。

进一步分析班组项目的游戏，考虑许多不同的非正式场景。在你的项目开发小组成员中分解这些场景。你们每个人应利用前面小节所讲的原则进行非正式场景描述。这项任务对于小组中每个人快速进入项目开发是很有用的，这项任务应尽早开展。