用例实现规约模板
用例规约+活动图例子
一、用例规约作业请根据中国工商银行网络银行的转账汇款的相关说明，试编写该用例的规格说明。
要求从中体会业务规则的作用和分析，并在自己的课题中分析充分详尽的业务规则。
注：新发布的用例一章的课件中，有个取款相关的用例规格说明，可参考。
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.收款人信息：当您向其他银行汇款时，系统无法判断收款人信息是否准确，仅对信息格式进行校验，请您务必准确填写收款人户名、卡（账）号、收款行等信息，若因上述信息填写错误导致汇款失败，手续费不退回。
汇款成功后收款人信息将自动添加至“我的收款人”，方便您再次汇款操作。
您还可直接输入收款人户名、手机号向其汇款，若其手机号已绑定银行账户（含他行），则将实时汇入绑定账户；若其手机号未绑定银行账户，则系统将向收款人发送短信，根据收款人短信回复卡/账号汇入资金。
网上书店——用例规约
如果管理员输入无效的用户名和（/或）密码，系统显示错误信息。管理员可以选择返回基流的起始点，重新输入正确的用户名和（/或）密码；或者取消登陆，用例结束
前置条件
无
后置条件
用例成功后，管理员登陆进入系统
扩展点
无
9．维护顾客信息
简要说明 本用例用于维护顾客信息。包括添加、修改和删除顾客信息
事件流
基本流
无。
2．个人信息管理
简要说明
本用例用于给顾客维护个人信息。包括修改本人的账号、密码和联系地址等信息。
事件流
基本流
当顾客查看并修改个人信息时，开始执行以下基本流：
（1）系统返回给当前顾客在系统数据库中目前存储的个人信息。
（2）顾客可以对本人信息的一项或几项进行修改。
（3）顾客向系统提交修改后的个人信息。
扩展点
无
进入图书信息修改界面，修改并保存图书信息
S-2：删除图书信息
管理员单击删除按钮，相应的图书被删除并更新数据库
S-3：添加图书信息
进入图书信息添加页面，添加并保存图书信息
特殊需求
无
前置条件
管理员登陆
后置条件
用例成功后，图书信息被添加、改变或删除
扩展点
无
11．订单管理
简要说明
本用例是管理员用来管理顾客订单信息之用。该用例接收从银联系统反馈来的关于某顾客的订单是否扣款成功的信息，然后把该信息以电子邮件的方式通知该客户。对于扣款成功的订单，通知物流系统给该订单的顾客配送所购书籍
备选流
顾客输入的新信息验证错误
如果系统检测到顾客输入的信息格式或内容有错（如输入新密码和确认输入新密码不一致等），会向顾客给予错误提示，并要求用户重新输入或取消修改的操作。
用例规约示例
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. 用户注册与登录- 用例名称：用户注册- 用例描述：用户需要提供个人信息进行注册，包括用户名、密码、手机号等，系统验证信息合法性后完成注册。
- 前置条件：用户打开点外卖系统，未登录状态。
- 后置条件：用户成功注册并登录系统，可进行下一步操作。
- 主要参与者：用户、系统。
- 触发事件：用户点击注册按钮。
- 用例步骤：1) 用户选择注册功能。
2) 用户填写个人信息并提交。
3) 系统验证信息合法性。
4) 系统生成唯一标识符并存储用户信息。
5) 系统自动登录用户。
2. 点餐与支付- 用例名称：用户点餐与支付- 用例描述：用户选择餐厅、浏览菜单、添加菜品到购物车，并进行支付操作。
- 前置条件：用户已注册并登录系统，进入特定餐厅界面。
- 后置条件：用户完成支付，生成订单，并进行配送。
- 主要参与者：用户、系统、餐厅。
- 触发事件：用户点击某个餐厅进入。
- 用例步骤：1) 用户选择特定餐厅。
2) 用户浏览菜单并添加菜品到购物车。
3) 用户选择支付方式并完成支付。
4) 系统生成订单，并通知餐厅。
5) 餐厅确认订单，并进行配送。
二、用例规约1. 用户注册规约- 前置条件：无。
- 后置条件：用户成功注册并登录系统。
- 基本流程：1) 用户打开点外卖系统，点击注册按钮。
2) 用户填写用户名、密码、手机号等个人信息并提交。
3) 系统验证信息合法性。
4) 如果验证通过，系统生成唯一标识符并存储用户信息，自动登录用户。
5) 如果验证失败，系统返回错误信息，用户重新填写信息。
- 异常流程：- 用户输入的用户名已被注册：系统返回错误信息，提示用户换一个用户名。
用例规约(实例)
课程注册系统用例规约版本<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.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
用例规约
网上书店系统用例规约姓名：廖杰学号：1208060324版本<1.0>订单管理管理员登录用户查看订单用例图删除书籍1．用户注册1.1简要说明本用例用于向顾客提供注册功能，每位顾客必须注册后才能够登录系统进行购物。
注册信息包括使用本系统的名称、账号、密码和电子邮件等。
注册完成后，系统保存这些信息到数据库，以方便管理员管理及联系用户。
1.2事件流1.2.1 基本流当用户进行注册时，开始执行以下基本流：（1）系统要求用户填写个人信息，包括使用本系统的账号、密码和电子邮件等。
（2）用户填写个人信息。
（3）系统验证用户信息。
1.2.2备选流1.2.2.1用户信息验证错误如果系统检测到用户输入的信息格式或内容有错，例如账号密码不匹配，会给以错误提示。
1.3前置条件用户必须首先访问网上购物的主页，然后点击注册。
1.4后置条件如果该用例成功，系统数据库中将增加一条该用户的信息，否则，系统维持现状。
1.5扩展点无。
2．个人信息管理2.1简要说明本用例用于给顾客维护个人信息。
包括修改本人的账号、密码和联系地址等信息。
2.2事件流2.2.1基本流当顾客查看并修改个人信息时，开始执行以下基本流：（1）系统返回给当前顾客在系统数据库中目前存储的个人信息。
（2）顾客可以对本人信息的一项或几项进行修改。
（3）顾客向系统提交修改后的个人信息。
2.2.2备选流2.2.2.1顾客输入的新信息验证错误如果系统检测到顾客输入的信息格式或内容有错（如输入新密码和确认输入新密码不一致等），会向顾客给予错误提示，并要求用户重新输入或取消修改的操作。
2.3前置条件顾客必须首先登录系统，然后才能进入本用例。
2.4后置条件如果本用例成功，顾客在系统数据库中的个人信息会被修改。
否则，系统维持原状。
2.5扩展点3．浏览图书信息3.1简要说明本用例用于维护3.2事件流3.2.1基本流当顾客进入网上书店系统之后，开始执行以下事件流：（1）在站内可以点击浏览本网上书店内的书籍。
用例规约表格模板(基于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.0> [注：以下提供的模板用于 Rational Unified Process。
其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。
][要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File>Properties，然后将Title、Subject 和 Company 等字段替换为此文档的相应信息。
关闭该对话框后，通过选择Edit>Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。
对于页眉和页脚，这一操作必须单独进行。
按 Alt-F9，将在显示字段名称和字段内容之间切换。
有关字段处理的详细信息，请参见 Word 帮助。
]修订历史记录目录1. 用例名称 41.1 简要说明 42. 事件流 42.1 基本流 42.2 备选流 42.2.1 <第一备选流> 42.2.2 <第二备选流> 43. 特殊需求 53.1 <第一特殊需求> 54. 前置条件 54.1 <前置条件一> 55. 后置条件 55.1 <后置条件一> 56. 扩展点 56.1 <扩展点名称> 5用例实现规约：<用例名称>[以下提供的模板用于用例规约，它包含以文本表示的用例特征。
该文档和需求管理工具（如Rational RequisitePro）一起使用，用于详细说明用例特征中的需求，并对这些需求进行标记] [用例图可在可视化建模工具（如 Rational Rose）中开发。
用例规约模板
用例模板
用例名称（用例名）
用例目标（用例在系统中的目标）
级别（概要任务/首要任务/子功能）
活动者（此用例的活动者）
状态（未定义路径/只定义了初始路径/路径定义完成）
前置条件（用例执行千系统应具有的状态）
后置条件（用例成功执行后系统应具有的状态）
主路径（用例主路径的名称）
可选路径（用例的可选路径）
例外路径（用例的例外路径）
举例：
用例名称修改密码
用例目标当用户修改自己的密码时用例开始。
它处理修改密码问题。
当用户结束修改市用例结束
级别子功能
活动者用户
状态只定义了初始路径
前置条件用户登录进入系统
后置条件用户的密码已得到修改
主路径用户修改密码，系统保存修改
可选路径用户修改密码，最后放弃对密码的修改
例外路径用户输入的原密码有误，或者两次输入的新密码不一致，系统显示错误信息。
用户可以选择返回主路径的起始点，重新输入正确的原
始密码以及两次一致的新密码；或者取消修改。
用例规约+活动图例子
⽤例规约+活动图例⼦⼀、⽤例规约作业请根据中国⼯商银⾏⽹络银⾏的转账汇款的相关说明，试编写该⽤例的规格说明。
要求从中体会业务规则的作⽤和分析，并在⾃⼰的课题中分析充分详尽的业务规则。
注：新发布的⽤例⼀章的课件中，有个取款相关的⽤例规格说明，可参考。
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表中的采购信息时，为了将此类信息以简捷的方式纳入系统管理范围，需要将采购信息直接导入系统。
用例规约例子
用例规约例子
以下是 6 条用例规约例子：
1. 咱就说，你去超市买东西，这不就是一个很常见的用例规约嘛！你知道自己要买啥，什么品牌、多少数量，这不就跟软件里的各种条件、步骤一样一样的嘛？比如说，你决定要买巧克力，然后选了某个牌子，接着看价格和重量，哎呀，这就跟程序里的各种设定和判断太像啦！
2. 你想想看，你每天早上起床后要做的一系列事情，也是个用例规约呀！刷牙、洗脸、换衣服，每一步都有先后顺序和特定的操作呢！就像软件运行时，一个步骤紧接着一个步骤，可不能乱了呀！比如你总不能先换衣服再刷牙吧，这多别扭呀！
3. 嘿，你知道煮饺子也是个好例子呢！先准备水，水开了下饺子，然后等饺子煮熟，捞出来，每一步都不能马虎呀！这在软件里不就相当于一个个明确的流程和规定嘛，水就像是输入，饺子煮熟就是输出，这过程多清晰啊！难道不是吗？
4. 你和朋友约着出去玩，这整个过程也是个用例规约呀！先商量去哪里，再确定时间，然后怎么碰面，一点都不能乱来呢！这不就跟程序里的流程规划一样嘛，一环扣一环的。
你再想想，如果商量不好，那可就玩不成啦，就像程序出错就运行不下去一样呀！真的好形象呀！
5. 哎呀，就连你写作业都是个典型的例子呀！先拿出本子和笔，再看题目，思考怎么做，然后开始写，最后检查。
这和软件中的用例规约简直如出一辙嘛！你可别小瞧这写作业的过程呢，像不像程序在一步步执行任务？
6. 你看那些运动员比赛，也是有他们的用例规约呀！比如跑步比赛，先站在起跑线，听口令，起跑，冲刺，每一步都很关键呀！这多像软件运行时的各种规定呀，每一个动作都得精确无误呀！不然怎么能赢得比赛呢，你说对吧？
我的观点结论就是：生活中到处都是用例规约的例子呀，真的太有意思啦！。
业务用例规约示例
a.申请户名应无历史欠费记录
这一栏中可以用过程步骤的编号来引用相关的业务规则。若该规则仅作用于本用例，可以加上面例子直接书写。若该规则作用于多个业务用例，建议编写专门的业务规则文档,为每个业务规则编号。在这里引用编号即可。如
Rule001
涉及的业务实体(中英文对照)
Be_XXX(申请单)
5.勘察员现场勘察,填写现场勘察工作单,给出是否符合用电条件结论.符合条件执行6,不符合条件执行异常过程5.1.1
6.审批过程为并行过程,同时执行分支过程6.1.1和6.2.1.两个分支过程均需执行完毕并有审批结果.若两个分支过程审批都同意,执行7,若一方或两方都不同意.执行7,若一方或两方都不同意,执行异常过程6.3.1
2.成功建立收费帐户和结算帐户
3.成功建立抄表台帐
4.成功建立监察档案Fra bibliotek5.成功建立计量档案
主过程描述
1.用电用户到营业大厅填写用电申请表,提交营业柜台
2.营业员初步核实申请信息,查询该用户是否有欠费记录,符合条件则启动用例
3.营业员录入申请信息,产生用电申请单
4.业务班长审查申请单,产生现场勘察工作单,分配勘察员执行任务
Be_XXX(现场勘察单)
Be_XXX(业务收费清单)
Be_XXX(电表安装工作单)
Be_XXX(用户档案)
Be_XXX(收费帐号)
Be_XXX(抄表台帐)
Be_XXX(监察档案)
Be_XXX(计量档案)
这一栏中可以列出与该业务用例相关的业务实体。一般情况下，业务实体要在晚一些的过程中才能产生。这里为了示意特别列出。在正常建模过程中，这一栏的内容要等建立了业务对象模型以后才能确定。
业务用例规约示例
用例规约——精选推荐
学籍管理系统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结账
用例描述：
用例名称：
用例规约
用例名称suc_第二次面试用例描述用人部门主管和人力资源部主管对面试通过的人进行第二次面试，确定最终录用人选执行者用人部门主管、人力资源部主管、总经理、人力资源部员工、应聘者前置条件 1.各执行者具备相应的职责和权限2.未有不可抗拒力（如自然灾害）等影响。
3.公司正常运营4.公司相关制度完善5.各个执行者无特殊变故后置条件无正常流1. 人力资源部员工根据第一次面试结果、经历评估结果、智力测验结果筛选出符合要求的应聘者2. 人力资源部员工将筛选出的结果整合出第二次面试的应聘人员名单，更新《新员工招聘面试评定表》,提交人力资源部主管审核3.人力资源部主管审核通过人员名单及《新员工招聘面试评定表》4. 人力资源部员工制定第二次面试方案，提交人力资源部主管审核5.人力资源部主管审核通过第二次面试方案6.人力资源部员工根据审核通过的第二次面试方案，准备第二次面试所需材料和场地7. 人力资源部员工根据审核通过的名单，通知第二次面试人员面试时间地址8.人力资源部主管和用人部门主管根据更新后的《新员工招聘面试评定表》对面试人员进行综合评定8.1对于初试及简历的疑点提问8.2对于面试者的性格特征的提问8.3对于面试者的学习能力的测试与提问8.4专业测试9.人力资源部主管和用人部门主管根据评定结果填写《新员工招聘面试评定表》10.总经理对关键岗位人员面试10.1进行情景模拟考核10.2应急能力测试10.3工作经验测试10.4专业能力测试11.总经理根据评定结果填写《新员工招聘面试评定表》12.人力资源部员工根据面试结果更新《新员工招聘面试评定表》，提交人力资源部主管和用人部门主管审核13.人力资源部主管和用人部门主管审核通过最终的《新员工招聘面试评定表》14.人力资源部员工和录用候选人进行录用意向洽谈14.1薪资福利洽谈14.2合同期限洽谈15.人力资源部员工根据录用意向洽谈确定拟录取名单16.人力资源部根据录取人员的岗位性质填写《员工工资定级表》17.总经理审批《员工工资定级表》替代流及异常处理业务规则 1.所有用例的执行者需具有相应的权限2.提交的《新员工招聘面试评定表》和《员工工资定级表》除特殊要求外，其他内容必须填写3.《新员工招聘面试评定表》和《员工工资定级表》实体对应的信息条目必须遵守其逻辑规则涉及实体《新员工招聘面试评定表》：应聘职位、薪资要求、可到岗时间、应聘者姓名、籍贯、联系方式、招聘渠道、个人修养、求职意愿、综合素质、性格特征、专业知识和技能、其他优势或不足、英语能力、综合评估意见《员工工资定级表》：入职时间、部门、岗位、职位、学历、内部职别、原薪级、原月薪、调整时间、现薪级、现月薪、执行时间、部门意见、人力资源部意见、总经理意见。
用例规约模板
用例规约模板
用例名称
项目唯一标识符
UC-IMSS-004
任务书章节
简要描述
用例目标简述：谁（主执行者）让系统干什么，系统让其他系统（辅助执行者）干什么，最后，系统输出了什么
参与者
主执行者：检测员
辅助执行者：XX信号IO、AD芯片、参数422芯片、XXX
涉众利益
涉众
利益
//该用例的上下游存在的涉众
从该用例获取的利益
前置条件
该用例开始前，系统需要满足的约束。
主流程
步骤
描述
//代表用例核心价值的路径
/、按照交互四部曲书写；
/、使用主动语句理清责任；
/、主语只能是主执行者或系统； /、使用核心域词语；
/、不要涉及交互设计的细节； /、不要写系统不能负责的事情
1
2
3
5
6
7
扩展流程
//对应流程中某个步骤中，系统要处理的意外和分支。
子流程
//对应主流程中多次重复的一组步骤集合。
后置条件
该用例结束后，系统需要满足的约束。
规则与约束
业务规则、数据约束、非功能需求/质量属性（可用性、可靠性、性能等）、设计约束
1、。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
<公司名称>
<项目名称>
Use-Case-用例实现规约：<用例名称>
版本 <1.0> [注：以下提供的模板用于 Rational Unified Process。
其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。
]
[要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File>Properties，然后将Title、Subject 和 Company 等字段替换为此文档的相应信息。
关闭该对话框后，通过选择
Edit>Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。
对于页眉和页脚，这一操作必须单独进行。
按 Alt-F9，将在显示字段名称和字段内容之间切换。
有关字段处理的详细信息，请参见 Word 帮助。
]
修订历史记录
目录
1. 简介 4
1.1 目的 4
1.2 范围 4
1.3 定义、首字母缩写词和缩略语 4
1.4 参考资料 4
1.5 概述 4
2. 事件流–设计 4
3. 派生需求 4
Use-Case-用例实现规约：<用例名称>
1.简介
[用例实现规约的简介应提供整个文档的概述。
它应包括此用例实现规约的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。
]
1.1目的
[阐明此用例实现规约的目的。
]
1.2范围
[简要说明此用例实现规约的范围：它的相关用例模型，以及受到此文档影响的任何其他事物。
]
1.3定义、首字母缩写词和缩略语
[本小节应提供正确理解此用例实现规约所需的全部术语的定义、首字母缩写词和缩略语。
这些信息可以通过引用项目词汇表来提供。
]
1.4参考资料
[本小节应完整列出此用例实现规约中其他部分所引用的任何文档。
每个文档应标有标题、报告号（如果适用）、日期和出版单位。
列出可从中获取这些参考资料的来源。
这些信息可以通过引用附录或其他文档来提供。
]
1.5概述
[本小节应说明此用例实现规约中其他部分所包含的内容，并解释文档的组织方式。
]
2.事件流–设计
[按照协作对象用文字说明该用例的实现方式。
其主要目的是概述与用例有关的图，并解释这些图之间的关系。
]
3.派生需求
[用文字说明在设计模型中没有考虑但在实施过程中却需要注意的所有用例实现需求，例如非功能性需求。
]。