几个网上找的需求用例的模版

这个是我在参考别人的基础上,自己加工了一下,形成了简繁两套模板, 已经在三个项目中使用.

繁:  这个比较详细,几乎包含了一个用例的方方面面, 可用于描述比较复杂的功能需求.

用例名称	发送短信
用例编号
用例作用域	短信发送和接收
用例版本	1.0
优先级	5
主要参与者	普通管理人员
涉众	涉众名称	兴趣
	短信接收人	准确及时的收到短信
	短信网关	准确及时地将短信发送到用户手中
前置条件	已登录到短信平台
触发条件	管理人员想通过本平台发送短信时
主事件流	1.     用户选择发送短信功能 2.     系统显示短信编辑页面。 3.     用户输入编辑短信信息 4.     用户选择发送范围。 5.     系统所有部门，用户组，用户供用户选择 6.     用户选择发送目标群体，并确定。 7.     用户点击发送，发送短信. 8.     系统将短信记录保存到短信网关发送表。
分支流
后置条件	短信成功被发送到短信网关
业务规则
特殊需求	选取发送群体，应做到灵活选择。

简约型:  主要用一段文字描述用例的主要功能,  有点敏捷的味道, 根XP的 user story card类似.

用例名称	删除联系人
用例编号
用例版本	1.0
用例作用域	个人通讯录管理
优先级	4
主要参与者	所有用户
描述	用户可以对不再联系的联系人予以删除。用户转到个人通讯录管理页面，用户有两种方式可以删除联系人信息，直接在列表中浏览，然后删除指定的条目，也可以执行联系人查询功能，进行批量删除。
特殊需求	应该有方便的批量删除功能

 

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

用例编号	UC-3
用例名称	积分累积
创建者	****	最后更新
创建时间	二〇〇四年十月二十五日	最后更新时间	十月二十五日
执行者	操作员或终端
说明	执行者收集消费客户的消费信息，并将这些信息发送至处理系统，根据消费客户消费对应的积分回报在其积分卡片帐上累加本次消费获赠的积分，处理系统返回终端本次消费获赠的积分。 本用例的积分累积先决条件是现金消费
先决条件	终端、操作员已经签到。网络通讯正常。
请求结果	返回本次消费获赠的积分，并显示在相应终端设备显示屏上，并有打印选择，如果客户需要打印则把相关信息打印给客户。
优先级	高
使用频率	高
普通过程	3.0 积分累积
	执行者行为	系统响应
	1）  收集现金消费信息及积分卡帐户信息，并将这些信息发送至处理系统（累积不需要输入密码）
		2）验证输入的数据是否合法（UC-A0）
		3）数据库操作，如积分卡片帐无此商户信息，建立本商户积分卡片帐（UC-A7），在本积分卡客户的积分卡片帐上累积此次消费获赠的积分
	4）接收返回，显示本次获赠的积分和累积积分，按消费者要求打印积分信息
可选过程	UC-A7 建立卡片帐
	执行者行为	系统响应
		1）无此积分卡客户信息
		2）在系统后台插入积分卡客户基本信息
		3）完成
例外因素	1.无此积分卡客户信息
	执行者行为	系统响应
		1）返回无此积分卡客户信息；
	2）接收返回，提示持卡用户无积分帐户，并提示重新输入积分卡客户信息；
	3）重新输入客户id，或者退出；
		4）转普通过程至结束；
包含用例	UC-A0  验证数据合法性
特定需求
假设
问题
注释

说明：  “优先级”指该本系统对本需求任务实现的重要程度。
             “使用频率”是指实际用户环境中，本任务执行的频率。预先估计的使用频度为并行使用和性能需求提供了一个早期指示
             “普通过程”也叫主过程、基本过程。。在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。当这种对话结束时，执行者也达到了预期的目的。
              “可选过程”，可选过程代表了任务的细节或用于完成任务的途径的变化部分。普通过程可以在一些决策点上分解成可选过程。然后再重新汇成一个普通过程。
               “包含过程”，许多使用实例可能共享一些公共函数。为了避免重复，你可以定义一个独立的使用实例，这一实例包含这个公共函数，并指定其它使用实例必须包括这个公共使用实例。
                “例外因素”引起任务不能顺序完成的情况称为例外（ e x c e p t i o n），在某些时候它可以视为可选过程。在定义使用实例时，描述例外路径是很重要的，因为它们描述了在特定条件下用户对系统如何工作的看法。“请求一种化学 制品”使用实例中的一个例外是不存在业务上可用的化学制品。如果你没有将例外记录在文档上，那么开发者可能在设计和构造阶段忽视这些可能性。此时，当系统 遇到一个例外条件时，就会发生系统崩溃。