用例规约模板
用例规约+活动图例子
一、用例规约作业请根据中国工商银行网络银行的转账汇款的相关说明，试编写该用例的规格说明。
要求从中体会业务规则的作用和分析，并在自己的课题中分析充分详尽的业务规则。
注：新发布的用例一章的课件中，有个取款相关的用例规格说明，可参考。
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.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
用例规约表格模板(基于RUP)
班级：测绘工程学号：1201721193 姓名：杨宇功能需求：1.该系统必须允许注册用户（包括客户和商家）审查他们过去三年的用户历史订单记录或销售记录2.该系统允许用户通过关键字搜索店铺或菜品3.该系统必须允许用户通过销量、评分、距离等条件进行店铺优先级排序4.该系统必须允许登录客户在店铺未打烊且送餐距离合理的情况下下单5.该系统必须允许登录客户给下过的订单评价6.该系统必须允许登录客户下单时使用多种付款平台7.该系统必须保留客户订单记录3年8.该系统必须允许客户和商家两种角色登录该系统9.该系统必须允许商家接单10. 该系统必须允许商家处理订单非功能需求：1. 该系统应满足在ios及android系统运行2. 该系统在10:00-12:30以及5:30-7:00时间段内支800万用户并发使用，其他时间支持200万用户并发使用3. 该系统可以检测用户点评内容是否，若内容违规则可以进行删除。
4. 系统安全：用户在身份认证、授权控制、私密性等方面的要求。
5. 系统易用：系统操作界面美观、简便，通俗，便于操作。
6. 系统可维护：系统在出现故障时可以及时维修，使其数据恢复。
客户用例图：商家用例图系统管理员用例图（1）用例图（1）用例规约：用例编号UC-1 用例名称登录用例描述用户登录该系统主参与者用户前置条件无后置条件登录到系统级别基本事件流程：1.系统提示用户输入用户名和密码2.用户输入用户名和密码3.系统验证用户名和密码，若正确，则登入到系统中。
如果用户输入无效的的用户名和密码，系统显示错误信息，并返回重新提示用户输入用户名和密码或者取消登录候选事件流程：1.点击注册按钮，注册一个新账号特殊需求无扩展点无备注无（2）用例图（2）用例规约：用例编号UC-2 用例名称提交订单用例描述客户提交订单主参与者客户前置条件用户已经成功登入该系统后置条件无级别基本事件流程：1.成功登录系统2.通过查找将需要的菜品添加到购物车3.点击提交订单按钮候选事件流程：1.退出该系统特殊需求无扩展点无备注无（3）用例图2）用例规约：用例编号UC-3 用例名称接收订单用例描述商家接单主参与者商家前置条件商家成功登入商家版系统后置条件无级别基本事件流程：1.成功登录系统2.进入订单处理模块3.点击接单按钮候选事件流程：1.退出该系统特殊需求无扩展点无备注无（4）用例图4）用例规约：用例编号UC-4 用例名称增加菜品用例描述商家通过该系统增加店铺的菜品（包括菜品的名称数量上传图片等）主参与者商家前置条件商家成功登录商家版系统后置条件无级别基本事件流程：1.成功登录商家版系统2.进入管理模块3.点击菜品进入菜品管理模块4.添加菜品名称、相关促销信息以及上传菜品图片5.点击保存按钮候选事件流程：1.返回到主界面2.退出系统特殊需求无扩展点无备注无（5）用例图5）用例规约：用例编号UC-5 用例名称增加活动模块用例描述系统管理员根据需要增加美团外卖活动模块如“今日特价2折”模块主参与者系统管理员前置条件管理员成功登录该系统后置条件完成模块管理级别基本事件流程：1.管理员成功登录系统2.进入活动管理模块3.点击增加活动按钮4.输入相关活动信息（包括活动规则）5.确认、提交候选事件流程：1.退出该系统特殊需求无扩展点无备注无用户下单付款数据流图。
用例规约模板
用例模板
用例名称（用例名）
用例目标（用例在系统中的目标）
级别（概要任务/首要任务/子功能）
活动者（此用例的活动者）
状态（未定义路径/只定义了初始路径/路径定义完成）
前置条件（用例执行千系统应具有的状态）
后置条件（用例成功执行后系统应具有的状态）
主路径（用例主路径的名称）
可选路径（用例的可选路径）
例外路径（用例的例外路径）
举例：
用例名称修改密码
用例目标当用户修改自己的密码时用例开始。
它处理修改密码问题。
当用户结束修改市用例结束
级别子功能
活动者用户
状态只定义了初始路径
前置条件用户登录进入系统
后置条件用户的密码已得到修改
主路径用户修改密码，系统保存修改
可选路径用户修改密码，最后放弃对密码的修改
例外路径用户输入的原密码有误，或者两次输入的新密码不一致，系统显示错误信息。
用户可以选择返回主路径的起始点，重新输入正确的原
始密码以及两次一致的新密码；或者取消修改。
用例规约+活动图例子
⽤例规约+活动图例⼦⼀、⽤例规约作业请根据中国⼯商银⾏⽹络银⾏的转账汇款的相关说明，试编写该⽤例的规格说明。
要求从中体会业务规则的作⽤和分析，并在⾃⼰的课题中分析充分详尽的业务规则。
注：新发布的⽤例⼀章的课件中，有个取款相关的⽤例规格说明，可参考。
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.收款⼈信息：当您向其他银⾏汇款时，系统⽆法判断收款⼈信息是否准确，仅对信息格式进⾏校验，请您务必准确填写收款⼈户名、卡（账）号、收款⾏等信息，若因上述信息填写错误导致汇款失败，⼿续费不退回。
汇款成功后收款⼈信息将⾃动添加⾄“我的收款⼈”，⽅便您再次汇款操作。
您还可直接输⼊收款⼈户名、⼿机号向其汇款，若其⼿机号已绑定银⾏账户（含他⾏），则将实时汇⼊绑定账户；若其⼿机号未绑定银⾏账户，则系统将向收款⼈发送短信，根据收款⼈短信回复卡/账号汇⼊资⾦。
uml用例规约
用户登录用例图用例规约：用例名称：登录用例ID：IBM_ESHOP_002.1 角色：普通用户用例说明：用例主要功能是实现登录,起始于普通用户的登录前置条件：启动程序，进入登录界面基本事件流：参与者动作系统响应 1. 用户输入基本信息（登录名和密码），点击确定按钮2.系统查找数据库，看该用户是否在数据库中。
若存在则进入主页面,若不存在，则进入2.1.1;若未输入，则进入2.2.2其它事件流：无异常事件流：参与者动作系统响应2.1.1未输入用2.2.1用户名不2.1.2未输入2.2.2密码不正确2.1.1 提示用户名或密码不能为空2.2.2提示用户名或密码不正确。
后置条件：登录成功添加联系人用例图用例规约：用例名称：添加联系人用例ID：IBM_ESHOP_002.2 角色：普通用户用例说明：该用例主要功能是添加联系人,用例起始于普通用户点击“添加”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.进入主界面，用户点击“添加”按3.用户添加联系人的相关信息，点击“确定”按钮2.系统响应点击事件，进入添加界面4.判断用户的输入是否合法，若合法，则返回主界面，若不合法：若输入信息为空，则其它事件流：无异常事件流：参与者动作系统响应4.1.1.1若未添加姓名4.1.2.1.1若未添加Emai4.2.1.1 若Email格式不正确4.2.2.1 若输入固定电话格式不4.2.3.1若输入手机格式不正确4.1.1.2 系统提示“必须输入姓名”4.1.2.2系统提示“必填”4.2.1.2 系统显示“邮件格式不正确”4.2.2.2 系统提示“8位电话号码”4.2.3.2 系统提示“只能输入数字”后置条件：添加联系人成功，返回主界面修改联系人用例图用例规约：3.用户对联系人姓名、性别、出生日期、Email、职务、固定电话、手机、住址、备注信息进行修改，点击“确定”按钮5．系统对用户的输入进行判断，若合法，则弹出对话框，提示“修改联系人成功”其它事件流：无异常事件流：5.1姓名未输入，系统给出提示对话框“必须输入姓5.2 Email未输入，系统给出提示对话框“必填”后置条件：修改信息成功，返回主界面删除联系人用例图用例规约：查找联系人用例图用例规约：用例名称：查找联系人用例ID：IBM_ESHOP_002.4 角色：普通用户用例说明：该用例主要功能是从列表中查看联系人信息,用例起始用户点击“查找”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户点击“查找”3．用户可以根据选择分组名称，填写邮箱、职位、姓名、手机。
软件工程-用例规约【范本模板】
1、登陆系统
系统中的所有参与者均可以使用本用例登陆系统，要求输入合法的用户名和密码。
登录系统用例规约
查询菜品信息的参与者是数据管理人员、顾客，用于查看酒店所有菜品的详细信息.
查询菜品用例规约
修改菜品信息的参与者是数据管理人员，用于修改酒店所有菜品的详细信息.
修改菜品用例规约
修改菜品信息的参与者是数据管理人员，用于增加酒店菜品的详细信息。
增加菜品用例规约
删除菜品信息的参与者是数据管理人员，用于删除酒店菜品的详细信息。
删除菜品用例规约
查询员工信息的参与者是数据管理人员，用于查看酒店所有员工的详细信息。
查询员工用例规约
修改员工信息的参与者是数据管理人员，用于修改酒店所有员工的详细信息。
修改员工用例规约
增加员工信息的参与者是数据管理人员，用于增加酒店所有员工的详细信息。
增加员工用例规约
删除员工信息的参与者是数据管理人员，用于删除酒店员工的详细信息。
删除员工用例规约
10、查询vip客户信息
查询vip客户信息的参与者是数据管理人员，用于查看酒店所有vip客户的详细信息。
查询vip客户信息用例规约
修改vip客户信息的参与者是数据管理人员，用于修改酒店所有vip客户的详细信息。
修改vip客户信息用例规约
增加vip客户信息的参与者是数据管理人员，用于增加酒店vip客户。
修改vip客户信息用例规约
删除vip客户信息的参与者是数据管理人员，用于删除酒店vip客户的详细信息。
删除vip客户信息用例规约。
用例规约——精选推荐
1.注册功能用例的用例实现一、简要说明游客可注册为网上订餐系统的用户。
注册时只要填写登录用户名、密码、联系电子信箱、联系电话以及安全问题和答案六项信息即可。
注册后，用户可以继续填写个人详细信息及收获人信息，同时可以修改密码、查询及维护订单。
二、事件流基本流：1. 游客选择注册。
2. 系统返回一个注册页面。
3. 游客根据提示输入相应的注册信息。
4. 系统验证游客输入成功。
5. 游客提交注册信息。
6. 系统提示注册成功并返回首页。
（默认已登录）备选流：1. 游客输入信息和系统验证不一致（如字段长度超过系统设置等），系统给出相应的提示信息并返回注册页面。
2. 游客输入用户名是已注册用户名，系统给出提示并返回注册页面。
3. 系统异常，无法注册，并给出相应的信息（如网站维护等）。
三、前置条件游客申请注册。
四、后置条件游客注册成功成为会员五、扩展点无。
2.登录\注销用例的用例实现一、简要说明用户：已经注册成功的用户可以通过登录页面登录进入该网站。
登录之后可以实现订餐系统的设定功能。
管理员：管理员必须通过后台进行登录，登陆以后，可以在前台或者后台之间切换，更方便地对系统进行管理及维护。
不提供管理员注册功能，管理员只能在数据库中添加，以保证系统的安全性。
登录后，可在前台或者后台选择注销，以便安全退出系统。
二、事件流基本流：1. 该会员选择登录。
2. 系统返回一个登录页面。
3. 会员输入用户名、密码和验证码并提交。
4. 系统进行系统验证，验证成功，记录该用户为登录用户并返回主页面。
（表明该会员已登录。
）5. 会员选择“注销”。
6. 系统提示用户成功注销并返回网站首页。
7．管理员修改管理员个人资料和账号信息。
备选流：1．用户忘记密码，选择“找回密码”功能，进入找回密码用例。
2. 系统验证用户登录信息有错，提示用户重新登录。
3. 系统处理异常，系统给出相应的提示信息.。
4．管理员只能在后台运行。
三、特殊要求无。
四、前置条件该会员必须是本网站已注册的成员。
用例分析之用例规约样例
2.当系统确认操作者具备导入权限时,进入采购信息导入界面。操作者选择将要导入的Excel文件（用本地浏览等方式），点击<确定>。如果要导入的采购信息在系统中已经存在（可以根据采购姓名和出生日期判断），那么系统提示：“该采购信息已经存在！”点击<确认>返回导入页面——单个导入的情况（或者，在系统提示并得到<确认>后，跳过此采购信息继续导入其余信息——多个导入的情况）。
3.导入完成后，系统提示：“采购信息导入成功！”
4.采购信息导入完毕后，系统自动调用用例3.1,记录采购信息导入现场记录，以便用例3.2使用。
5.当导入的采购属于业主时,通常会连带导入相应的物业信息。(其实这个步骤不必要，物业信息可以单独导入，并且在业主信息中设置有对应物业信息的检索)。
用例可选事件流
异常情况处理等非正常工作流程。
用例交系统存储,且得到确认无误后退出用例。
用例非功能性需求:
1.要求导入的Excel表的格式有固定的规范。
2.以各个分公司为单位的创建人所创建的采购信息只有该分公司的所属工作人员才有权利使用。哦年
3.关于供方信息和求方信息的分类，在采购信息属性中已经设置，所以在导入的时候不必特意分类。
修改历史
修改日期：8月3日
顺序图：PC3:UCk:SEQ1:批量导入采购信息正常流程顺序图
边界类原型：
类图：
用例主要参与者:
以各个分公司为单位的采购信息创建人,该创建人巳由分公司经理分配给创建采购信息的权限。
用例触发事件:
当某个分公司接收到填写于Excel表中的采购信息时，为了将此类信息以简捷的方式纳入系统管理范围，需要将采购信息直接导入系统。
[模版]用例规约
![[模版]用例规约](https://img.taocdn.com/s3/m/ea0b178171fe910ef12df862.png)
修订历史记录目录修订历史记录 (1)用例规约： <用例名称> (2)1. 用例名称 (2)1.1. 简要说明 (2)2. 事件流 (2)2.1. 基本流 (2)2.2. 备选流 (2)2.2.1. <第一备选流> (3)2.2.2. <第二备选流> (3)3. 特殊需求 (3)3.1. <第一特殊需求> (3)4. 前置条件 (3)4.1. <前置条件一> (3)5. 后置条件 (3)5.1. <后置条件一> (4)6. 扩展点 (4)6.1. <扩展点名称> (4)用例规约： <用例名称>1.用例名称[以下提供的模板用于用例规约，它包含以文本表示的用例特征。
此文档可以和需求管理工具（如Rational RequisitePro）结合使用，用来指定和标记用例特征中的需求。
[用例图可以借助可视化建模工具（如 Rational Rose）来开发。
用例报告（带有所有特征）可以用 Rational SoDA 来生成。
有关详细信息，请参见 Rational Unified Process 中的工具向导。
]1.1.简要说明[说明中应简要表述用例的作用和目的。
一个段落即足以作此说明。
]2.事件流2.1.基本流[当主角有所行动时，此用例随即开始。
总是由主角来带动用例。
用例应说明主角的行为及系统的响应。
应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
如果进行了信息交换，则需指出来回传递的具体信息。
例如，只表述主角输入了客户信息就不够明确。
最好明确地说主角输入了客户姓名和地址。
通常可以利用词汇表让用例的复杂性保持在可控范围内-您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。
简单的备选流可以在用例文本中提供。
如果只需几句话就可说明存在备选流时将发生的事件，则可以直接在事件流一节中说明。
用例规约例子
用例规约例子
以下是 6 条用例规约例子：
1. 咱就说，你去超市买东西，这不就是一个很常见的用例规约嘛！你知道自己要买啥，什么品牌、多少数量，这不就跟软件里的各种条件、步骤一样一样的嘛？比如说，你决定要买巧克力，然后选了某个牌子，接着看价格和重量，哎呀，这就跟程序里的各种设定和判断太像啦！
2. 你想想看，你每天早上起床后要做的一系列事情，也是个用例规约呀！刷牙、洗脸、换衣服，每一步都有先后顺序和特定的操作呢！就像软件运行时，一个步骤紧接着一个步骤，可不能乱了呀！比如你总不能先换衣服再刷牙吧，这多别扭呀！
3. 嘿，你知道煮饺子也是个好例子呢！先准备水，水开了下饺子，然后等饺子煮熟，捞出来，每一步都不能马虎呀！这在软件里不就相当于一个个明确的流程和规定嘛，水就像是输入，饺子煮熟就是输出，这过程多清晰啊！难道不是吗？
4. 你和朋友约着出去玩，这整个过程也是个用例规约呀！先商量去哪里，再确定时间，然后怎么碰面，一点都不能乱来呢！这不就跟程序里的流程规划一样嘛，一环扣一环的。
你再想想，如果商量不好，那可就玩不成啦，就像程序出错就运行不下去一样呀！真的好形象呀！
5. 哎呀，就连你写作业都是个典型的例子呀！先拿出本子和笔，再看题目，思考怎么做，然后开始写，最后检查。
这和软件中的用例规约简直如出一辙嘛！你可别小瞧这写作业的过程呢，像不像程序在一步步执行任务？
6. 你看那些运动员比赛，也是有他们的用例规约呀！比如跑步比赛，先站在起跑线，听口令，起跑，冲刺，每一步都很关键呀！这多像软件运行时的各种规定呀，每一个动作都得精确无误呀！不然怎么能赢得比赛呢，你说对吧？
我的观点结论就是：生活中到处都是用例规约的例子呀，真的太有意思啦！。
用例图及用例规约
京胜校园软件综合实验室用例图用户登录用例图本图共有三个角色：operator、teacher、student，operator登录到管理员模块，teacher登录到指导教师模块，student登录到学生模块。
三大模块都可以实现退出功能。
学生模块用例图学生模块又分为四大模块：我的实训，我的课程，个人中心，资料中心（如图）。
我的实训我的实训又分为四个小模块：我的消息，通知公告，我的课表，我的实训（如图）。
1.我的消息学生可以查看收件箱和发件箱的信息，并且扩展发送消息、删除消息、回复消息三种功能。
2.通知公告3.我的课表4.我的实训。
我的课程我的课程里只有一个小的模块：我的课程（如图）。
1.我的课程在我的课程里可以查看我的课程，并且扩展功能：进入课程。
资料中心资料中心分为两个小模块：下载资料和链接资料1.下载资料学生选择某一文件，便能够查看要下载的资料，在此处可以下载。
2.链接资料个人信息分为两个小模块：我的资料和修改密码1.我的资料2.更改密码指导教师模块指导教师模块分为信息管理、资源管理、实训组织、课程组织、资料管理5个模块。
信息管理信息管理又分为实训计划和投稿信箱两个模块1.实训计划指导教师可以在此查看实训计划，并且实现查看统计（查看被通知者查看信息的情况）、添加通知、删除通知、修改通知、查询（通过标题查找）5大功能。
2.投稿信箱指导教师可以在此查看投稿信箱，并且实现查询（通过投稿标题查询）功能。
资源管理资源管理模块里包含一个小模块内容管理。
1.内容管理实训组织实训组织模块又分为我的课程、实训管理、成绩管理3个小模块。
1.我的课程指导教师可以查看自己的课程，并实现查询（时间段或全部）功能。
2.实训管理3.成绩管理指导教师可以在此处查看成绩，并能实现查询（学期、班级、课程）、编辑成绩2大功能，其中编辑成绩又可以实现查看成绩、删除成绩、添加成绩、导入成绩（、查询（成绩名称）5大功能课程组织课程组织模块包含一个小的模块：课程管理。
用例规约——精选推荐
学籍管理系统1.术语表2.系信息管理（系统管理员）2.1用例规约2.11 查询系信息2.12删除系信息用例规约：2.13 修改系信息用例规约：2.14录入系信息用例规约：图SSM-XXXM-1图SSM-XXXM-2图SSM-XXXM-3图SSM-XXXM-4 3.补充规约补充规约3.1简介3.1.1目的本文档的目的是定义学籍管理系统的需求。
本补充规约列出了不便于在用例模型的用例中获取的系统需求。
补充规约和用例模型一起记录对系统的一整套需求。
3.1.2范围本系统适用于学校的学籍信息管理，使得管理员和教师从繁重的管理工作中解脱出来，轻松管理学生的相关信息。
3.1.3参考资料适用的参考资料包括：1.补充规约说明（百度文库）2.UML说明与Rose建模3.2功能3.2.1系统错误记录所有的系统错误都应当记录下来。
系统的致命错误会导致系统的有序关闭。
系统错误消息应包括错误的文本说明、操作系统的错误代码（如果适用于该错误）、检测错误状态的模块、数据戳和时间戳。
所有的系统错误都应保存在错误日志数据库中。
3.2.2在线操作学生可以在线查询和修改个人信息，导师可以查询学生的信息，并对其信息进行提出建议或修改，管理员对系统进行维护及时发布信息。
3.3可用性3.3.1Windows 兼容性桌面用户界面应与Windows XP/7 兼容。
3.3.2易于使用的设计学籍管理系统用户界面的设计应当着眼于易于使用，使具有一定计算机知识的用户群体不需要经过更多的培训就能够使用该系统。
3.4可靠性本节列出了所有的可靠性需求。
3.4.1 <可行性>该系统必须提供一个Windows XP /7 的用户交互界面。
3.4.2 <平均故障间隔时间>MTBF（平均故障间隔时间）需求将在下次迭代中定义。
3.5性能3.5.1<性能需求一>该用户的数据库应能够支持3000 名用户对数据库的同一时刻的访问，并且该系统的服务器应能够支持1000名用户对其的同一时刻的访问。
模板-用例规约
密级：内部
缤纷视频网项目
用例规约
二零一三年七月
关于本文档
项目名称
×××项目
主 题
用例规约
说 明
该项目用于网上购物
适用对象
该项目适用于代替以往的购物方式，改为网上购买食品的用户。
修订历史
版本
章节
类型
日期
作者
说明
1.0
C
说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；
评审记录
角色
er点击‘确认’按钮，删除商品信息
4.系统删除选中的商品信息，并更新商品信息列表
其它事件流：
第3步，user选择“取消”，系统将取消删除操作，并返回商品列表页面
异常事件流：
第4步，系统删除商品信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示user删除失败
后置条件：
6．系统保存结账信息，并返回到商城主页面。
其它事件流：
第1步，user若没有登录系统，则提示用户先登录系统，同时若是用户没有注册账号，提示用户先注册账号
第2步．user选择‘修改’按钮，对已选购的商品信息进行修改
第2步．若用户是首次结账，需要填写送货地址，送货地址包括：姓名、本地/外地、通讯地址、邮政编码、电话号码。非首次结帐，显示上次购物时的送货地址，并默认为本次的送货地址。
其它事件流：
无
异常事件流：
第6步，系统保存商品数量时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示user更改商品数量失败
后置条件：
系统更新商品数量信息。
2.1.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<扩展点名称>
[扩展点在事件流中所处位置的定义。
]。