1.完整正式用例格式
<名字：应该是一个动词短语来表示目标>
使用的环境：<目标较长的描述，如果需要，还包括触发条件>
范围：<设计范围，设计时将系统作为黑盒考虑>
层次：<概要，用户目标，子功能三者之一>
主执行者：<角色描述或者角色名称>
项目相关人员利益：<用例中项目相关人员和关键利益列表>
前置条件：<期望周围环境达到的状态>
最小保证：<所有退出操作之前，如何保证项目相关人员的利益>
成功保证：<目标完成时的环境状态>
触发事件：<什么启动了用例，可能时时间事件>
主成功场景：<步骤编号#><动作描述：从事件触发到目标达到清除的步骤>
扩展：<每次写一个扩展，每一个都指向主场景中的特定步骤>
<被改变步骤><条件>：<动作或子用例>
<被改变步骤><条件>：<动作或子用例>
技术和变化列表：<这里写出场景中因技术或数据变化可能的分支>
<步骤或者变化编号#><变化列表>
<步骤或者变化编号#><变化列表>
相关信息：<项目所需要的所有附加信息>
2.非正式用例格式
用例25 实际登陆
主执行者：用户
范围：应用程序
层次：子功能
<一系列过程描述>，在登陆前，系统要求输入。。。。
3.单列表格式
| 用例 | ||
| 使用语境 | ||
| 范围 | ||
| 层次 | ||
| 主执行者 | ||
| 项目相关人员和利益 | 项目相关人员 | 利益 |
| 前置条件 | ||
| 最小保证 | ||
| 成功保证 | ||
| 触发事件 | ||
| 描述 | 步骤 | 活动 |
| 扩展 | 步骤 | 分支活动 |
| 技术和数据变化 |
4.双列表格式
左：执行者动作 右：系统动作| 用户 | 系统 |
| 输入订单号码 | 检测订单号码和当月中奖号码是否一致 登记... 发送邮件... 指导... |
| 退出系统 |
5.RUP格式
与完整正式模板类似，扩展又叫可选流程
1.用例名称
1.1 简要描述
1.2 执行者
1.3 触发事件
2.事件流程
2.1 基本流程
2.2可选流程
2.2.1 条件1
...文本...
2.2.2 条件2
...文本...
3.特殊需求
3.1 平台
...文本...
3.2 ...
4.前置条件
...文本...
5 后置条件
...文本...
6.Occam格式
Occam语言，可以构造形式化的模型。
7.图形化的方式
图形化的方式存在可用性方面的问题：
1.最终用户和执行者可能不熟悉这些符号，也不会有耐心学习这些符号。
2.图形不能完全表达所需意思。
高层用例图其实提供了一个语境图，用例图的价值除此之外就没有什么了。
标签：...,执行者,用例,格式,文本,前置条件,模板 From： https://www.cnblogs.com/mach-arch/p/16921588.html