用例规约模板
用例规约+活动图例子
一、用例规约作业请根据中国工商银行网络银行的转账汇款的相关说明，试编写该用例的规格说明。
要求从中体会业务规则的作用和分析，并在自己的课题中分析充分详尽的业务规则。
注：新发布的用例一章的课件中，有个取款相关的用例规格说明，可参考。
1.安全提示：为了您的资金安全，请勿轻信陌生人通过网络聊天群、直播、电话、短信等方式进行的诱导性“投资理财”、代办大额信用卡或高额贷款、网购客服或快递进行退货等非正规渠道要求进行转账汇款，谨防被骗。
短信通知手续费将根据我行政策进行减免，请以实际扣款情况为准。
2.汇款类型：根据人民银行关于防范电信诈骗有关要求，我行为您提供“实时汇款、普通汇款、次日汇款”三种汇款方式选择。
对于“普通汇款”和“次日汇款”，您可在限定时间内通过手机银行或网银“转账汇款-查询汇款明细”进行撤销。
3.到账时间：行内汇款一般实时到账，7*24小时受理。
自2019年11月29日起100万元（含）以内跨行汇款，我行将优先通过网银互联系统汇出至收款行，一般实时到账，7*24小时受理。
100万元以上跨行大额汇款，工作日交易时间（前一日20:30-当日17:15）一般实时到达收款行；工作日（周一至周四）非交易时间（17:15-20:30）提交，系统预约至当日20:30后汇出；非工作日，系统将做预约处理，待下一工作日交易时间（一般为节假日最后一天20:30后）汇出。
准确时间以人民银行系统为准。
4.收款人信息：当您向其他银行汇款时，系统无法判断收款人信息是否准确，仅对信息格式进行校验，请您务必准确填写收款人户名、卡（账）号、收款行等信息，若因上述信息填写错误导致汇款失败，手续费不退回。
汇款成功后收款人信息将自动添加至“我的收款人”，方便您再次汇款操作。
您还可直接输入收款人户名、手机号向其汇款，若其手机号已绑定银行账户（含他行），则将实时汇入绑定账户；若其手机号未绑定银行账户，则系统将向收款人发送短信，根据收款人短信回复卡/账号汇入资金。
用例规约说明书_模版
A1.其他事件流A1
在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告
异常流程描述
[在达到执行者目标时，产生了违背执行者目标的流程处理。]
例如：UC001_网站公告发布
用例描述
[说明中应简要表达用例的作用和目的（即满足相关涉众的利益），一个段落即足以作此说明]
执行者（参与者）
[用例的触发者、操作人、系统或时间。]
前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。]
后置条件
[用例的后置条件是用例执行完毕系统可能处于的一组状态。]
3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告
4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改
5．用例终止
备选流程描述
[描述用例执行过程中只在特定条件下才出现的流程]
No.1<备选流的触发条件>
<第一备选流>
[较复杂的备选流应单独说明。]
1.1.2<备选支流>
[如果能使表达更明确，备选流又可再分为多个支流。]
特殊要求
[描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。]
主要流程描述
[描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应执行者提出的服务请求。]
例如：
1．负责人鼠标点击“修改公告”按钮
2．系统出现一个文本框，显示着原来的公告内容
其他事件流a1在按提交按钮之前负责人随时可以按返回按钮文本框的任何修改内容都丌会影响网站首页的公告异常流程描述在达到执行者目标时产生了违背执行者目标的流程处理
网上书店——用例规约
如果管理员输入无效的用户名和（/或）密码，系统显示错误信息。管理员可以选择返回基流的起始点，重新输入正确的用户名和（/或）密码；或者取消登陆，用例结束
前置条件
无
后置条件
用例成功后，管理员登陆进入系统
扩展点
无
9．维护顾客信息
简要说明 本用例用于维护顾客信息。包括添加、修改和删除顾客信息
事件流
基本流
无。
2．个人信息管理
简要说明
本用例用于给顾客维护个人信息。包括修改本人的账号、密码和联系地址等信息。
事件流
基本流
当顾客查看并修改个人信息时，开始执行以下基本流：
（1）系统返回给当前顾客在系统数据库中目前存储的个人信息。
（2）顾客可以对本人信息的一项或几项进行修改。
（3）顾客向系统提交修改后的个人信息。
扩展点
无
进入图书信息修改界面，修改并保存图书信息
S-2：删除图书信息
管理员单击删除按钮，相应的图书被删除并更新数据库
S-3：添加图书信息
进入图书信息添加页面，添加并保存图书信息
特殊需求
无
前置条件
管理员登陆
后置条件
用例成功后，图书信息被添加、改变或删除
扩展点
无
11．订单管理
简要说明
本用例是管理员用来管理顾客订单信息之用。该用例接收从银联系统反馈来的关于某顾客的订单是否扣款成功的信息，然后把该信息以电子邮件的方式通知该客户。对于扣款成功的订单，通知物流系统给该订单的顾客配送所购书籍
备选流
顾客输入的新信息验证错误
如果系统检测到顾客输入的信息格式或内容有错（如输入新密码和确认输入新密码不一致等），会向顾客给予错误提示，并要求用户重新输入或取消修改的操作。
网上书店——用例规约
②根据订单号获取该订单顾客的个人信息，主要是获取该顾客的电子邮件地址。
③向顾客发送电子邮件
备选流
发送电子邮件失败
如果发送电子邮件失败，则系统会向管理员发送错误信息。
特殊需求
无
前置条件
管理员必须首先登录到该系统中
后置条件
如果该用例成功，会生成通知顾客订单是否成功扣款的电子邮件，并把扣款成功的订单信息转发给物流系统。否则，则保持原状
扩展点
3．浏览图书信息
简要说明
本用例用于维护
事件流
基本流
当顾客进入网上书店系统之后，开始执行以下事件流：
（1）在站内可以点击浏览本网上书店内的书籍。
（2）可以根据不同的类别选择自己喜欢的书籍类型。
（3）可进一步查看自己所选书籍的详细信息。
备选流
用户信息验证错误
特殊需求
无
前置条件
顾客必须首先登录系统，然后才能进入本用例。
当管理员要求查看顾客信息时，开始执行以下基本流：
（1）系统列出所有符合该管理员要求的订单信息
（2）管理员提出所要执行的操作
如果有新订单提交，则执行S-1分支，向顾客信息里边添加新顾客信息。
如果已发货，则执行S-2分支，则向顾客信息里边删除相对应的顾客信息。
如果有顾客发出的修改信息的请求，则执行S-3分支，则向顾客信息里边对应记录进行修改。
事件流
用例规约描述样板
用例规约描述编号：Zpark-ESM-UC版本 1.0变更记录填表说明本文档的目的是依据《需求规格说明书》和系统原型，建立用例模型，并对用例模型进行具体描述。
用例规约描述是面向对象分析和设计的重要步骤。
用例规约描述需要进行评审。
1引言文档（《用例规约描述文档》）是描述项目小组对项目进行需求分析得到的关于用户和系统之间交互作用的文本性描述文档。
1.1目的用例是关于用户和系统之间相互作用的文本性描述，从外部角度描述系统的行为，表达系统应该做什么。
本文档通过用例规约描述，来进一步说明该系统需求，是下一阶段系统设计的基础，也是测试用例的重要依据。
1.2定义1.3概述ESM用来对企业员工薪酬进行管理，主要功能包括薪酬结构定义、组织结构定义、薪酬数据填写、薪酬审批、薪酬统计报表。
ESM包括四种角色（Actor）：1.普通用户（User）普通用户指的是ESM系统中不具有管理、审批职能的用户，仅能够查看本人薪酬相关信息。
其对应的操作如图1所示。
图12．薪酬管理专员（SM）薪酬管理专员负责定义企业薪酬结构，并负责员工薪酬的审批。
其操作如图2所示。
图23．经理（Manager）经理指企业各级部门的负责人。
最基层的经理负责填写本部门员工的本月薪酬数据，包括基本工资、扣款、奖金或补贴。
上级经理负责审批。
其操作如图3所示。
图34．超级用户（SuperUser）超级用户负责创建企业组织结构，导入员工信息，系统用户管理。
其操作如图4所示。
图42用例描述2.1组织结构管理模块2.1.1建立新岗位用例规约：图ESM-ZZJG-1 岗位信息查询页面图ESM-ZZJG-2 岗位信息页面图ESM-ZZJG-32.1.2删除岗位用例规约：图ESM-ZZJG-42.1.3查询岗位用例规约：2.1.4更新岗位用例规约：图ESM-ZZJG-52.1.5添加岗位上下级关系用例规约：图ESM-ZZJG-6图ESM-ZZJG-72.1.6删除岗位上下级关系用例规约：ESM-ZZJG-8ESM-ZZJG-92.1.7查询岗位上下级关系用例规约：ESM-ZZJG-10ESM-ZZJG-112.2员工信息管理模块。
用例规约(小组)
1．用例UC1:挂号2．主要参与者:挂号负责人3．受益人及其利益:1)挂号负责人:正确输入病人信息、选择科类信息、选择医生信息。
2)病人:可以快速的拿到挂号凭证单4．前置条件:挂号负责人正确登陆系统5．后置条件:登记病人信息，选择科类，选择医生，确认信息，打印挂号凭证。
6．主要成功场景:1)挂号负责人成功登陆系统2)病人到挂号处挂号3)挂号负责人输入病人信息4)挂号负责人成功选择科类和医生5)打印机打印出挂号单6)病人成功取得挂号凭证单住院管理用例前置条件：开始这个用例前，系统已正常启动，并工作者顺利进入系统。
参与者：病人，财务工作人员，病房工作人员。
主事件流如下：①如果病人提出入院登记申请执行子事件a②如果病人提出住院预缴执行子事件b③如果病人提出出院结算执行子事件c④如果病人提出药品查询执行子事件d子事件a：①病人接到住院通知；②病人提供相关身份证明和病历；③由病人提供的信息工作人员登记住院患者的基本信息；④向病人开出住院单。
子事件b：①病人提供住院单；②工作人员核实单据；③单据核实后向病人开出住院缴费单据；④病人预缴住院费用；⑤工作人员收取，向系统提交修改信息。
子事件c：①医生开出出院证明；②病人提供出院证明和相关资料；③向病人开出出院结算单据；④病人全额缴纳住院费用。
子事件d：①查询病人入院详细信息；②查询病人住院预缴信息；③查询病人出院结算信息。
后置条件：如果用例成功结束，推出用例.药房管理用例：病人通过药房付费取药，接触只有一个用例；药库是对药房里药品的供给补充，由医院工作人员负责管理，医院工作人员可同时接触药房管理、药库管理2个用例。
仓库管理系统用例①如果管理员登录执行事件a②如果管理员需要药品入库执行事件b③如果管理员需要药品出库执行事件c④如果管理员需要填写药品汇总表执行事件d事件a登陆用例：完成仓库采购员登陆功能。
事件b1.按照入库单仓库管理员进行药品管理2.仓库管理员对入库的药品进行核对事件c:1.管理员根据领料单核对信息.2.按照领料单发放药物事件d:1.查看药品是否充足2.如果供不应求，则填写采购单。
用例规约示例
7）授权-ATM机 通过将卡ID、PIN、金额以及帐户信息作 为一笔交易发送给银行系统来启动验证过程。对于此事件 流，银行系统处于联机状态，而且对授权请求给予答复， 批准完成提款过程，并且据此更新帐户余额。
如果PIN输入有误，ATM将显示适当的消息；如果还 存在输入机会，则此事件流在步骤3 -输入PIN处重新加入 基本流。
如果最后一次尝试输入的PIN码仍然错误，则该卡将被
ATM机保留，同时ATM返回到准备就绪状态，本用例终止。
备选流5 -帐户不存在
在基本流步骤4中-验证帐户和PIN，如果银行系统返回 的代码表明找不到该帐户或禁止从该帐户中提款，则ATM显示适当的消息并且在步骤9-返回银行卡处重新加入基本 流。
8）出钞-ATM机清点并向客户提供现金。
9）返回银行卡-ATM机将客户的银行卡返还。
10）收据-ATM机打印收据并提供给客户。ATM机 还相应地 更新内部记录。
［用例结束］
备选流1 -银行卡无效
在基本流步骤2中-验证银行卡，如果卡是无效的，则卡被 退回，同时会通知相关消息。
备选流2 -
ATM内没
有现金
系统用例规约：
用例名称：
ATM取款
描述：
客户持银行卡（本行或其他行）从ATM提取现金
actors:
客户和银行主机
前置条件：Байду номын сангаас
ATM处于准备就绪状态。
后置条件：
用例结束时ATM又回到准备就绪状态。
基本流：
1）准备提款-客户将银行卡插入ATM机的读卡机。
2）验证银行卡-ATM机从银行卡的磁条中读取帐户代码， 并检查它是否属于可以接收的银行卡。
用例规约(实例)
课程注册系统用例规约版本<1.0>查看成绩报告卡用例1.简要说明本用例允许学生查看他（她）刚结束学期的成绩报告卡。
本用例的Actor 是学生。
2.事件流当学生从主表格中选择“查看成绩报告卡”活动时，用例开始。
1.基本流—查看成绩报告卡1.系统检索出学生上个学期所修完的每门课程的成绩信息。
2.系统准备、排版并显示成绩信息。
3.当学生完成查看成绩信息后，选择“关闭”。
2.备选流1.没有可以查看的成绩信息如果在基本流中，系统不能找到这个学生上个学期的任何成绩信息，将会显示一个消息。
学生确认这条消息后，用例终止。
3.特殊需求没有和本用例有关的特殊需求。
4.前置条件1. 登录在本用例开始之前，学生要登录到系统。
5.后置条件没有和本用例有关的后置条件。
6.扩展点没有和本用例有关的扩展点。
课程注册用例1. 简要说明此用例允许学生登记当前学期的课程。
如果在学期开始的选/退课期间情况发生一些变化，那么学生也可以修改或删除自己所选的课程。
课程目录系统提供一个本学期所有课程的列表。
本用例主要的主角是学生。
课程目录系统是用例中包含的一个主角。
2. 事件流当学生从主窗体中选择“维护课程表”活动时，此用例就开始使用了。
1. 基本流—创建课程表1.学生选择“创建课程表”。
2.系统会显示一张空白课程表。
3.系统从课程目录系统中检索可选课程的列表。
4.学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。
在完成选择后，学生选择“提交”。
5.在此步骤中为每一门所选课程执行“添加课程”子流程。
6.系统保存该课程表。
2. 备选流1. 修改课程表1.学生选择“修改课程表”。
2.系统检索并显示学生现在的课程表（例如，本学期的课程表）。
3.系统从课程目录系统中检索本学期所有可选课程的列表。
系统向学生显示该列表。
4.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例规约：<用例名称>
[以下提供的模板用于用例规约，它包含以文本表示的用例特征。
该文档和需求管理工具（如
Rational RequisitePro）一起使用，用于详细说明用例特征中的需求，并对这些需求进行标记] [用例图可在可视化建模工具（如 Rational Rose）中开发。
用例报告（具有所有特征）可用
Rational SoDA 生成。
有关详细信息，请参见 Rational Unified Process 中的工具向导。
] 1.用例名称
1.1简要说明
[此说明应该简要介绍该用例的作用和目的。
一个段落即足以作此说明。
]
2.事件流
2.1基本流
[当主角有所行动时，此用例随即开始。
总是由主角来带动用例。
用例应说明主角的行为及系统的响应。
应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
如果进行了信息交换，则需指出来回传递的具体信息。
例如，只表述主角输入了客户信息就不够明确。
最好明确地说主角输入了客户姓名和地址。
通常可以利用词汇表让用例的复杂性保持在可控范围内−您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。
简单的备选流可以在用例文本中提供。
如果只需几句话就可说明存在备选流时将发生的事件，则可以直接在事件流一节中说明。
如果备选流较为复杂，则需要用另外一节来单独说明。
例如，备选流小节解释如何说明较复杂的备选流。
虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。
只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。
如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。
根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。
请切记，您的目的是要阐明问题，而不是混淆问题。
]
2.2备选流
2.2.1<第一备选流>
[较复杂的备选流应单独说明，这已在事件流一节的基本流小节中提及。
将备选流小节当作备选行为− 在许多情况下，由于主事件流中发生异常事件，这时每个备选流都可代表备选行为。
这些备选流的长度可以是说明与备选行为相关的事件所需的长度。
当备选流结束时，除非另外说明，主事件流的事件将重新开始。
]
2.2.1.1<备选分支流>
[如果能使表达更明确，备选流又可再分为多个支流。
]
2.2.2<第二备选流>
[在一个用例中很可能会有多个备选流。
为了使表达更清晰，应将各个备选流分开说明。
使用备
选流可以提高用例的可读性，并防止将用例分解为过多的层次。
应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。
]
3.特殊需求
[特殊需求通常是非功能性需求，它为一个用例所专有，但无法在用例的事件流文本中较容易或较自然地进行说明。
特殊需求的示例包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求）。
此外，其他需求，如操作系统及环境、兼容性需求和设计约束，也应在此节中记录。
]
3.1<第一特殊需求>
4.前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。
]
4.1<前置条件一>
5.后置条件
[用例的后置条件是用例一执行完毕系统可能处于的一组状态。
]
5.1<后置条件一>
6.扩展点
[此用例的扩展点。
]
6.1<扩展点名称>
[扩展点在事件流中所处位置的定义。
]。