用例标识：用例的编号。

　　用例名称：根据用例表达的功能而取的简短明了的名称。用例命名其实是有讲究的，即必须是一个动词短语或句子，而不是一个名词短语，通常建议为一个动宾短语（如：提取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款）。用例的命名表现了用例的特点，即它代表的是参与者的操作，是一个动作。尽量不要取 “××管理”或“维护××”，因为这个动作应当是一个非常明确的动作，而“××管理”代表的是插入、修改、删除等一系列动作，操作就变得不明确了。

　　应用范围：就是要设计的系统。

　　用例类型：“用户目标”还是“子功能”，即是用户需要操作的目标功能，还是从“用户目标”中提取出来的“子功能”。“用户目标”应当至少有一个参与者，来驱动它完成相关操作，而“子功能”通常没有，因为它往往是被系统所驱动。

　　用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）如何进行使用进行描述。同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。

　　参与者：列出与该用例相关的参与者，包括进行操作的人（角色）和相关的外部系统。

　　涉众利益：关注该用例的人对该用例的要求，它往往是非功能需求，或者是功能需求中的一些常常为我们所忽视的细节。如客户要求在填写一些表单的时候能够快速进行查找，而另一些系统管理员希望提高可维护性（虽然他们可能不是该用例的参与者）。编写涉众利益应当按照如下格式：使用数字编写序号，而每个涉众利益应当书写为“谁期望怎么样”。

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

　　事件流：是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。

　　基本流程：又称为“主流程”或“主成功场景”，它描述的是该用例以最正常的方式流转，并且最终获得成功的流程。基本流程在编写时，应当通过数字，对流程中的每一步进行编号。

　　扩展流程：又称为“替代流程”、“分支流程”或“交替场景”，它描述的是基本流程在流转过程中可能出现的所有分支。扩展流程在编写时，通常使用“数字+小写字母”对扩展流程进行编号。数字代表该扩展流程是在基本流程的哪一步发生分支的。如果是任意位置满足某条件就会发生分支，则使用“*”代替。小写字母代表该扩展流程是本用例中的第几个扩展流程。扩展流程编号的后面应当描述进入该扩展流程的条件。最后，和基本流程一样，通过数字编号，详细描述该扩展流程的整个流程。如果在扩展流程中还会出现分支，则如上递归地描述该扩展流程的扩展流程。

　　异常流程：故名思意，它是对该用例的所有基本流程和扩展流程可能出现的所有异常情况及其处理流程的描述。与扩展流程一样，异常流程首先通过“数字+小写字母”进行编号，描述出现异常的条件。如果是任意位置都可能满足异常条件，则使用“*”代替数字。随后，编写出处理该异常的整个流程。按照以上步骤，罗列出所有可能出现的异常情况。

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

　　非功能需求：我们可以把它们简称为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。

　　补充规格说明书：该用例对应的补充规格说明书。

　　除此之外，用例说明还可以包括其它内容。比如，该用例是用于查询数据或展现一个表格，则应当画出数据的格式或表格的样式，并详细标注数据间的运算关系；如果客户对该用例有其它硬件或技术要求，可增加“技术与数据变元”项。

　　在编写这部分说明的时候，还有一个非常关键的地方值得注意。当我们在编写事件流时，如果发现多个用例都出现相同或相似的流程，并且功能相对独立时，应当考虑将它提取出来单独形成一个用例。如果是这样，在原用例的这个地方只需说明在执行某个步骤时进入哪个用例就可以了，不用再描述这部分流程。如果原用例在基本流程中调用这个用例，则原用例包含这个用例；如果原用例在扩展流程中调用这个用例，则这个用例是对原用例的扩展。

　　另外，异常流程也是一个非常重要的内容。过去我们在分析阶段没有考虑异常处理的情况，以致在开发阶段不知道怎样处理才能让客户满意。但值得提醒的是，这里的异常是站在业务层面的异常，如：“用户不能提供单据号”，或“用户未领取通知单”。而那些技术层面的异常不应当出现在这里，如“数据库连接失败”等。