用例模板说明

参与者：用例图中该用例的参与者，通常是业务操作的触发者和施与对象（如外部系统）。

触发事件：谁干了什么，触发了这个用例。

前置条件：在触发该用例相关操作前必须达到的条件。

事件流：这是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。
1. 基本流程：另一个名称更能表达它的意义：最佳流程（The Best Flow）。它描述的是该用例以最佳的、最正常的方式流转，没有出现任何异常，并且最终成功完成操作的流程。基本流程在编写时，应当通过数字对流程中的每一步进行编号。
2. 扩展流程：或者叫“分支流程”，它描述的是基本流程在流转过程中可能出现的所有分支。扩展流程最大的特点就是，它应当是在基本流程的某一步骤发生的分支，因此它的编号规则是“基本流程号+序号”。基本流程号就是发生分支的那一个基本流程的编号。在同一个基本流程上发生多个分支时，它们的序号从1依次开始编号。
另一种情况是，某个扩展流程本身拥有多个步骤，这时应当在“基本流程号+自身序号”的基础上再添加序号，如“2.1.1”。
扩展流程在描述时，应当首先描述进入这个分支的条件，即“如果××则××”、“当××时××”。
3. 异常流程：就是发生异常情况时的处理流程。注意，用例说明是站在用例角度进行的说明，因此这里并不是我们通常一样的发生程序异常的处理流程，而是用户在处理业务操作时发生的异常情况，如：如果顾客不能提供身份证，则••••••

后置条件：又称为“成功保证”，就是执行基本流程获得成功以后所达到的状态（条件）。后置条件往往体现的是执行该用例的最终目的。如：完成用户档案的填写并提交。

非功能需求：简称为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。这一部分的需求分析相当重要而又最容易被忽略，后面我们再详细讨论。

假设与约束：就是隐藏于业务功能中的各项规则与条件，如各种逻辑条件、计算公式、环境限制等等。

优先级：没啥可说的，最关键的是怎么去评定。这里我卖一个官子，在需求评审阶段，我会给大家一个比较准确而又可操作的评定方法。