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