在软件需求分析的课上，老师常常和我们讲软件需求分析要像讲故事一样，让技术人员在看到文档的时候能有代入感，这样就能更清晰的了解到用户的行为动机和业务需求。在软件需求里讲故事，其实就是用户场景分析。最近的阅读中涉及到了很多关于这个方面的知识，所以今天我想以用例场景和步骤表达一些我的感想。
为了把系统描述的更加具体，我们编写了很多用例，这节用例组成了一个集合，形成一个用例集。实际上，用例集就是一个可以不断展开的故事。因为每一个用例都描述了主执行人为了实现业务目标与系统发生交互的情节，而这些情节里有构成主成功场景的主要情节，也有因故而导致目标没有实现的失败情节。同时每个场景里还有发生这个情节的触发条件。
我们先来讨论一下主成功场景的描述。一个系统在运行过程中满足了很多人的利益，所以就会有各种各样的用例和场景，但是我们先来采用一条经典的，简单的情节线作为主线，在这条主要的情节线中，主执行人完成了任务目标，同时其他项目相关人员的利益也得到满足，这就是主成功场景。而其他的用例和场景都将成为主成功场景的补充说明。在编写用例的时候一般会采用这样的结构来进行场景描述：场景执行的条件，完成的目标，执行的步骤集，结束的条件以及作为场景片段的可能的发生的扩展集。事实上不管是不是主成功场景，场景描述都应该采取这样的描述结构。在这个描述结构中执行步骤集是主体部分。执行步骤的描述要注意使用简单的语法，明确的表达出谁是执行者，谁是被传递的东西。另外就是要注意从俯视的角度站在一个高度上来描述场景，就是通常所说的上帝视角。我们在上一次的阅读笔记里谈到用例层次的升降，应用在这个地方就是要使每个步骤完成的目标大小尽量合理一些。比如如果把用户点一下TAB键都要作为一个目标的话就会让文档变得很长，使得用例条例不清晰。在表达每一个步骤的时候还要注意显示执行者的意图，而不是动作，这样也能够简化步骤说明使得用例的条理结构变得很清晰。在描述一个事物的时候，可能会面对一个事物中包含的不同部分，可以把每个部分都作为单独的步骤，也可以采用不同的方式将其中的若干部分进行合并。最后还可以可选择的提及到一些时间限制，以此来保证步骤的有序进行。
我们知道一个系统必然不可能使所有场景都成功发生，所以一定要在扩展场景描述里对这些情况进行补充说明。主要要说明都会出现哪些失败场景，具体的解决方案是什么等等。要在描述过程中明确扩展场景的扩展基础，发生条件，集中讨论所有的失败和可选择的过程。
编写场景能够让我们更明确的了解到用户的行为动机，同时也能够对我们的系统设计进行一个检验，保证我们的系统能够满足用户所有的工作场景，满足所有项目项目相关人员的利益。