业务用例规约示例
OO系统分析员之路--用例分析系列(7)--用例规约的编写--业务规则和实体描述
一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。
这类规则笔者习惯于，并且也建议将它们写到用例的补充规约里面去，因为它们一般与具体的业务功能性要求没有直接关系。
有时候，这类规则也被写到软件架构文档中。
关于用例补充规约以后再讨论。
第二种是交互规则。
这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。
当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为VIP 定单进入特殊流程等。
这类规则一般要写到用例规约中。
交互规则实际上还有两个是比较特殊的，一个入口条件，也称为前置条件，即actor满足什么条件才能启动用例;另一个是出口条件，也称为后置条件，即用例结束后会产生哪些后果。
稍后参看示例。
第三种是内禀规则。
所谓内禀规则是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。
例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。
同时也包括大家所熟悉的数据效验规则，例如身份证号必须是15或18位，邮编必须是6位等等。
这类规则是业务实体的内在规则，因此应该写到领域模型文档中，稍后参看示例。
读者或许对把规则这么分类有不同的习惯和理解，可能会觉得麻烦。
但是笔者这么做有充分的理由。
首先，全局规则与具体用例无关，它实际是系统应该具备的特性，这些规则把它分出来目的就是为了让系统去负责这些特性的实现。
读者可以结合实际考虑一下，通常授权，事务，备份等特性都是由系统框架去实现的，具体的功能中并不去实现它们。
如果读者有过基于某个框架开发应用的经历的话一定会认同笔者的话。
其次，交互规则是在用例场景当中产生的，它们规定了满足什么条件后业务将如何反应。
通常，这部分规则是最复杂，也最不稳定，最容易变化的。
大家所说的需求经常变更相信绝大部分就来自于此。
用例规约+活动图例子
一、用例规约作业请根据中国工商银行网络银行的转账汇款的相关说明，试编写该用例的规格说明。
要求从中体会业务规则的作用和分析，并在自己的课题中分析充分详尽的业务规则。
注：新发布的用例一章的课件中，有个取款相关的用例规格说明，可参考。
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.收款人信息：当您向其他银行汇款时，系统无法判断收款人信息是否准确，仅对信息格式进行校验，请您务必准确填写收款人户名、卡（账）号、收款行等信息，若因上述信息填写错误导致汇款失败，手续费不退回。
汇款成功后收款人信息将自动添加至“我的收款人”，方便您再次汇款操作。
您还可直接输入收款人户名、手机号向其汇款，若其手机号已绑定银行账户（含他行），则将实时汇入绑定账户；若其手机号未绑定银行账户，则系统将向收款人发送短信，根据收款人短信回复卡/账号汇入资金。
用例规约模板
用例规约模板
用例名称
项目唯一标识符
UC-IMSS-004
任务书章节
简要描述
用例目标简述：谁（主执行者）让系统干什么，系统让其他系统（辅助执行者）干什么，最后，系统输出了什么
参与者
主执行者：检测员
辅助执行者：XX信号IO、AD芯片、参数422芯片、XXX
涉众利益
涉众
利益
//该用例的上下游存在的涉众
从该用例获取的利益
前置条件
该用例开始前，系统需要满足的约束。
主流程
步骤
描述
//代表用例核心价值的路径
/、按照交互四部曲书写；
/、使用主动语句理清责任；
/、主语只能是主执行者或系统； /、使用核心域词语；
/、不要涉及交互设计的细节； /、不要写系统不能负责的事情
1
2
3
5
6
7
扩展流程
//对应流程中某个步骤中，系统要处理的意外和分支。
子流程
//对应主流程中多次重复的一组步骤集合。
后置条件
该用例结束后，系统需要满足的约束。
规则与约束
业务规则、数据约束、非功能需求/质量属性（可用性、可靠性、性能等）、设计约束
1、。
用例规约怎么写？
⽤例规约怎么写？
UC001-发布公告
UC001（⽤例编号）-发布公告（⽤例名称）
⽤例描述
统标⼈员根据项⽬发⾏需求，发布债券发⾏公告
执⾏者
统标⼈员、交易员
前置条件
......
后置条件
......
基本路径
1.交易员输⼊债券项⽬信息，请求发布
2.系统校验项⽬信息充分
3.系统⽣成发布信息
...
扩展路径
1a.交易员输⼊债券项⽬信息，请求发布
2a.系统校验项⽬信息充分
补充约束
字段列表
1.债券基础信息=债券代码+债券简称+债券类型{国债|地⽅政府债|政策性⾦融债...}+票⾯利率+.....
业务规则
2.保留2位⼩数
质量需求
1.可⽤性
2.性能
3.可靠性
4.可⽀持性
设计约束
设计约束是在实现系统时必须要遵守的⼀些约束，包括界⾯样式、报表格式、平台、语⾔等。
第05讲用例规约
用例规约：记录时间(续)
前置条件： 后置条件：
用户必须已经登录到这个系统 系统将雇员的工时正确的记录到数 据库中
用例规约：记录时间(续)
正常事件流：
1.雇员查看当前时间之前输入的数据； 2.雇员从已有的支付号码中选择一个， 这些收费代码是按客户和项目组织 的； 3.雇员从当前的时间段选择一个日期； 4.雇员输入以正整数表示的工时； 5.系统在视图中显示这个数据，并在 以后的视图中看到这个数据。
3. 受益人及其利益：
3. 公司：需要精确地记录交易并满 足客户的利益。需要支付授权服 务记录可接受的支付。需要一些 容错功能。需要账目和存货清单 得到自动的快速更新
正式型（详细型）-处理销售3
3. 受益人及其利益：
5. 政府税务机构：需要从每一次销售 中收税。 6. 支付授权服务：需要用正确的格式 和协议传来的数字授权请求。需要 精确计算它们可支付给商店的款额
把它们看做是看门人， 它阻止参与者触发该用 例直到满足所有条件 说明在用例触发之前 什么必须为真
后置条件
后置条件约束用 例执行后系统的状 态
用例执行后什么 必须为真 对于有多个事件 流的用例，则应该 有多个后置条件
前置、后置条件注意
某些用例依赖于其他用例
一个用例在离开系统时，可能是另一个 用例的前置条件（例如：“登录”和“管理 系统”）
正式型（详细型）-扩展1
1. 在系统失败时，要恢复和校正账 目，确保所有的交易敏感状态以 及事件能够从场景的任何步骤中 恢复
1. 出纳员重启系统和登录，并请求恢 复先前的状态
正式型（详细型）-扩展2
2. 系统重建先前的状态
系统检测阻止恢复的异常状态 1. 系统给出纳员发出一个出错信号，记 录该错误并进入一个干净的状态 2. 出纳员开始一次新的销售
业务用例规约
<公司名称><项目名称>业务用例规约：<业务用例名称>版本<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 帮助。
][注：如果您没有使用 Requisite Pro，就应使用此文档模板来记录实际的业务用例，其中包括该业务用例的工作流程、特殊需求和性能目标。
此文件应链接到 Rose 模型中的相应业务用例。
如果您在使用 SoDA，则可以将此文档用作对业务用例报告的输入，该报告将把此文档的内容与Rose 中的用例图结合在一起。
]修订历史记录目录1. 简介 41.1 目的 41.2 范围 41.3 定义、首字母缩写词和缩略语 41.4 参考资料 41.5 概述 42. 业务用例名称 42.1 简要说明 43. 目标 44. 性能目标 44.1<性能目标的名称> 45. 工作流程 45.1 基本工作流程 45.1.1<工作流程步骤的名称> 45.2 备选工作流程 55.2.1<工作流程步骤的名称> 56. 类别 57. 风险 58. 可能性 59. 流程拥有者 510. 特殊需求 510.1<特殊需求的名称> 511. 扩展点 511.1<扩展点的名称> 5业务用例规约：<业务用例名称>简介[业务用例规约的简介应提供整个文档的概述。
用例规约范例
广州大学华软软件学院
华软管理系统
学籍管理子系统用例规约:学位资格查看
版本1.0
修订历史记录
目录
1.奖励查看4
1.1简要说明4
2.事件流4
2.1基本流4
2.2备选流4
3.特殊需求4
3.1界面信息显示需求4
4.前置条件4
5.后置条件4
6.扩展点4
用例规约:学位资格查看
1. 学位资格查看
1.1 简要说明
系统提供查看学位资格的功能；
角色：各系教务员
2. 事件流
2.1 基本流
1、用户选择“学位资格查看”功能启动该用例；
2、系统打开‘学位资格查看主界面’，该界面分为查询条件区和结果显示区；
3、用户在查询条件区输入学号、年级、专业、学位资格(有/无)、和认定时间，然后选择‘查询’；
4、系统刷新‘学位资格查看主界面’，在结果显示区显示符合查询条件的记录，显示年级、专业、
学号、姓名、学位资格、认定时间；
5、用户选择‘退出’，该用例结束。
2.2 备选流
3. 特殊需求
3.1 界面信息显示需求
4. 前置条件
1．系统中已已设置了学生信息；
2．系统中已设置了用户信息；
5. 后置条件
6. 扩展点。
用例规约示例
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机从银行卡的磁条中读取帐户代码， 并检查它是否属于可以接收的银行卡。
用例规约表
用例规约表是一个用来描述软件系统用例的表格，它包含了一系列关于用例的详细信息。下面是一个用例规约表的示例：
用例编号
用例名称
参与者
前提条件
正常流程异常流程后置件UC1用户登录
用户
用户已注册账户，且未登录
用户输入用户名和密码，系统验证通过后登录成功
用户输入的用户名或密码错误，系统提示错误信息，并返回登录页面
用户登录成功后，系统记录用户已登录状态
UC2
浏览商品列表
用户
用户已登录
用户进入商品列表页面，查看商品列表信息
无异常流程
无后置条件
UC3
购买商品
用户
用户已登录，且选择要购买的商品加入购物车
用户提交购买请求，系统处理购买请求并完成交易
无异常流程
购买成功后，系统更新购物车状态和库存状态
UC4
支付订单
用户
用户已登录，且订单已生成
用户选择支付方式并提交支付请求，系统处理支付请求并完成支付
无异常流程
支付成功后，系统更新订单状态和支付状态
在上述示例中，用例规约表包含以下列：
用例编号：用例的唯一标识符。
用例名称：用例的简短描述。
参与者：与该用例相关的参与者或角色。
前提条件：执行用例之前必须满足的条件。
正常流程：用例的详细执行步骤。
异常流程：可能的异常情况及处理步骤。
后置条件：用例执行完毕后的状态或结果。
业务用例规约示例
5.成功建立计量档案
主过程描述
1.用电用户到营业大厅填写用电申请表,提交营业柜台
2.营业员初步核实申请信息,查询该用户是否有欠费记录,符合条件则启动用例
3.营业员录入申请信息,产生用电申请单
4.业务班长审查申请单,产生现场勘察工作单,分配勘察员执行任务
5.勘察员现场勘察,填写现场勘察工作单,给出是否符合用电条件结论.符合条件执行6,不符合条件执行异常过程5.1.1
异常过程描述
5.1.1不符合条件，营业员归档申请记录，停止申请过程，用例结束
6.2.1配电和用电两方至少一方不同意，营业员归档申请记录，停止申请过程，用例结束
业务规则
a.申请户名应无历史欠费记录
这一栏中可以用过程步骤的编号来引用相关的业务规则。若该规则仅作用于本用例，可以加上面例子直接书写。若该规则作用于多个业务用例，建议编写专门的业务规则文档,为每个业务规则编号。在这里引用编号即可。如
如abizrule001涉及的业务实体中英文对照bexxx申请单bexxx现场勘察单bexxx业务收费清单bexxx电表安装工作单bexxx用户档案bexxx收费帐号bexxx抄表台帐bexxx监察档案bexxx计量档案这一栏中可以列出与该业务用例相关的业务实体
业务用例规约示例
用例名称
Bu_申请永久用电
Rule001
涉及的业务实体(中英文对照)
Be_XXX(申请单)
Be_XXX(现场勘察单)
Be_XXX(业务收费清单)
Be_XXX(电表安装工作单)
Be_XXX(用户档案)
Be_XXX(收费帐号)
Be_XXX(抄表台帐)
Be_XXX(监察档案)
Be_XXX(计量档案)
ATM用例图_用例规约_时序图[]
![ATM用例图_用例规约_时序图[]](https://img.taocdn.com/s3/m/e841b606e45c3b3567ec8b7f.png)
ATM用例图_用例规约_时序图[]————————————————————————————————作者：————————————————————————————————日期：ATM 系统用例图存款取款查询转账客户银行主机改密码用例包括：1） 存款：客户持银行卡（本行或其他行）从ATM 存放现金 2） 取款：客户持银行卡（本行或其他行）从ATM 提取现金3） 查询：客户持银行卡（本行或其他行）在ATM 上查询卡的帐户信息 4） 转账：客户持银行卡（本行）在ATM 上进行同行转账5） 改密码：客户持银行卡（本行或其他行）在ATM 修改卡的密码系统用例规约：ATM取款用例名称：ATM取款描述：客户持银行卡（本行或其他行）从ATM提取现金actors: 客户和银行主机前置条件：无基本流： 1.客户插入银行卡。
2.ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。
3.客户输入密码。
4.ATM验证帐号和密码。
5.ATM显示包括取款在内的服务功能，客户选择“取款”。
6.输入取款额：客户输入数量为50元的倍数的取款额。
7.ATM向银行主机通知卡号、密码、账号和取款额，获得含有最新余额的取款成功确认信息。
8.ATM打印并吐出凭条。
9.ATM清点并吐出现金，记录取款成功。
10.ATM询问客户是否继续服务。
11.客户选择否，ATM吐出银行卡，结束用例，否则回到步骤5。
[用例结束]备选流：3-7，10a. 客户取消服务：ATM记录服务取消，打印凭条，吐出凭条和银行卡，[用例失败] 3,6,11a. 客户未及时输入超过30秒：ATM吞卡，[用例失败]2a. 卡无效：ATM吞卡，[用例失败]2b. 读卡器或卡被损坏：ATM吞卡，[用例失败]4a. 密码错：4a1. 客户重新输入密码a.累计3次密码错误：ATM吞卡，[用例失败]4b. 无此帐号：ATM吞卡，[用例失败]5a. ATM无现金：ATM不显示“取款”功能，客户可选择其他服务，[用例失败] 6a. 取款额超过ATM现金余额：ATM要求客户重新输入取款额。
用例规约的例子
用例规约
用例名称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.《新员工招聘面试评定表》和《员工工资定级表》实体对应的信息条目必须遵守其逻辑规则涉及实体《新员工招聘面试评定表》：应聘职位、薪资要求、可到岗时间、应聘者姓名、籍贯、联系方式、招聘渠道、个人修养、求职意愿、综合素质、性格特征、专业知识和技能、其他优势或不足、英语能力、综合评估意见《员工工资定级表》：入职时间、部门、岗位、职位、学历、内部职别、原薪级、原月薪、调整时间、现薪级、现月薪、执行时间、部门意见、人力资源部意见、总经理意见。
软件工程-用例规约【范本模板】
1、登陆系统
系统中的所有参与者均可以使用本用例登陆系统，要求输入合法的用户名和密码。
登录系统用例规约
查询菜品信息的参与者是数据管理人员、顾客，用于查看酒店所有菜品的详细信息.
查询菜品用例规约
修改菜品信息的参与者是数据管理人员，用于修改酒店所有菜品的详细信息.
修改菜品用例规约
修改菜品信息的参与者是数据管理人员，用于增加酒店菜品的详细信息。
增加菜品用例规约
删除菜品信息的参与者是数据管理人员，用于删除酒店菜品的详细信息。
删除菜品用例规约
查询员工信息的参与者是数据管理人员，用于查看酒店所有员工的详细信息。
查询员工用例规约
修改员工信息的参与者是数据管理人员，用于修改酒店所有员工的详细信息。
修改员工用例规约
增加员工信息的参与者是数据管理人员，用于增加酒店所有员工的详细信息。
增加员工用例规约
删除员工信息的参与者是数据管理人员，用于删除酒店员工的详细信息。
删除员工用例规约
10、查询vip客户信息
查询vip客户信息的参与者是数据管理人员，用于查看酒店所有vip客户的详细信息。
查询vip客户信息用例规约
修改vip客户信息的参与者是数据管理人员，用于修改酒店所有vip客户的详细信息。
修改vip客户信息用例规约
增加vip客户信息的参与者是数据管理人员，用于增加酒店vip客户。
修改vip客户信息用例规约
删除vip客户信息的参与者是数据管理人员，用于删除酒店vip客户的详细信息。
删除vip客户信息用例规约。
用例分析之用例规约样例
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. 你看那些运动员比赛，也是有他们的用例规约呀！比如跑步比赛，先站在起跑线，听口令，起跑，冲刺，每一步都很关键呀！这多像软件运行时的各种规定呀，每一个动作都得精确无误呀！不然怎么能赢得比赛呢，你说对吧？
我的观点结论就是：生活中到处都是用例规约的例子呀，真的太有意思啦！。
用例规约模板
游泳馆管理系统用例规约：1.用例名称1.1简要说明指的是仓库保管员根据已经经过验收员验收合格的商品，进行商品正式入库的操作，入库之后将增加相应商品的库存数量。
2.事件流2.1基本流1.仓库保管岗登陆进入‘商品入库’页面。
2.系统根据系统当前时间生成开票日期和临时单据编号（单据编号＝临时标记＋系统日期＋2位顺序号。
例： ls2005101001）。
3.用户点击‘选择待入库单据’按钮。
4.系统弹出‘待入库单据选择’页面。
5.系统查询出已经经过验收员验收的单据信息，信息包括单据编号、业务员、进货单位、税号、地址、扣率等单据概要信息。
6.用户输入业务员、进货单位等查询条件。
7.系统查询出满足条件的采购开票单据列表。
8.用户选择需要进行入库操作的具体单据。
9.系统根据所选的单据的概要信息列出已验收合格的具体商品明细信息（商品条码、商品名、产地、生产厂家、单价和数量等）。
10.用户点击‘确认’按钮。
11.系统根据用户所选单据的信息填入入库单据的开票单据编号、业务员、进货单位、税号、地址、扣率等单据概要信息。
以及商品明细信息，商品条码、商品名称、规格、保质期、生产厂商、供应商、单价和数量等。
12.用户选择商品存放货位。
点击‘保存’按钮。
13.系统生成单据正式编号（单据编号＝单据类别＋年份＋6位顺序号。
例：rh2005000001）。
系统保存单据信息。
14.用户点击‘入库’按钮。
15.系统增加仓库库存记录(序列号、单据编号、商品编码、发生类别（0为入库类单据，1为出库类单据）、入库数量、发生日期、发生后数量)。
修改实时库存数为发生后数量。
2.2备选流2.2.1保管员对入库验收单据有异议时1.当基本流5发生后，保管员对已验收的单据有异议时，保管员选择需要入库的单据。
填写备注栏重新验收理由。
2.保管员点击‘保存’按钮保存意见信息，并通知验收员处理有异议商品。
3.特殊需求无4.前置条件采购验收通知单；5.后置条件生成入库单；6.扩展点无。
图书馆系统需求分析用例规约
图书管理用例规约目录1。
读者管理 (5)1.1 简要说明 (5)1.2 事件流 (6)1。
2.1 基本流 (6)1.2.2 备选流 (6)1.2。
2.1 新增 (6)1。
2.2.2 查询 (7)1.2.2。
3 修改 (7)1.2.2。
4 删除 (7)1。
2.2.5 禁用 (7)1.3 特殊需求 (7)1.4 前置条件 (7)1.5 后置条件 (7)1.6 扩展点 (7)2。
图书订购 (8)2。
1 填写请购单 (8)2.1.1 简要说明 (8)2.1。
2 事件流 (8)2.1.2.1 基本流 (8)2.1.2。
2 备选流 (8)2。
1.2.2.1 新增 (9)2。
1。
2.2.2 修改 (9)2.1。
2。
2。
3 删除 (9)2.1。
3 特殊需求 (9)2.1.4 前置条件 (9)2。
1。
5 后置条件 (9)2。
1。
6 扩展点 (9)2.2 审核请购单 (9)2。
2。
1 简要说明 (9)2.2。
2 事件流 (10)2.2。
2。
1 基本流 (10)2.2。
2。
2 备选流 (10)2。
2.2.2。
1 回退 (10)2.2。
2。
2.2 通过 (10)2.2.3 特殊需求 (10)2。
2.4 前置条件 (10)2。
2.5 后置条件 (11)2。
2。
6 扩展点 (11)2.3.1 简要说明 (11)2.3.2 事件流 (11)2。
3.2。
1 基本流 (11)2。
3.2。
2 备选流 (11)2。
3。
2。
2。
1 新增 (11)2.3。
2。
2.2 修改 (12)2.3.2。
2.3 删除 (12)2.3.2。
2。
4 注销 (12)2。
3。
3 特殊需求 (12)2.3.4 前置条件 (12)2.3.5 后置条件 (12)2.3.6 扩展点 (13)2。
4 分管领导审批 (13)2。
4.1 简要说明 (13)2.4.2 事件流 (13)2。
4.2.1 基本流 (13)2。
4.2。
2 备选流 (13)2。
4.2。
2.1 回退 (13)2。
用例规约——精选推荐
学籍管理系统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名用户对其的同一时刻的访问。
用例规约
网络营销系统----下订单
UC编号
SUC001
用例简述
客户查看商品信息后下订单
用例图
主流程
第一步：客服提供给客户商品的信息。
第二步：客户对于客服提供的商品信息，进行查看。
第三步：联系客服后，与客服进行交互。
第四步：客户对选定的商品，下订单。
第五步：客户确认收货并支付
替代流程
a) ”无法显示商品信息”系统出现客户查看的商品信息无法显示的信息，回到主要流程1，客服重新提供商品信息
替代流程
a) ”联系物流公司失败”系统出现客服联系物流公司失败的信息，回到主要流程2，客服重新联系物流公司
b）“确认支付失败”系统出现客服确认支付失败的信息，回到主要流程3，客户重新确认支付
例外用例
d) “订单无法显示”系统出现客服 Nhomakorabea管理的客户订单无法显示的信息，该系统用例失败
业务规范
1）订单在三个工作日之内处理完成
业务规范
1）每笔订单至少有一件商品
2）系统按照公司原有的编码方式形成订单号
非UML文档
订货单txt文件
其他
填了假数据的“订货单”纸本
用例名称
网络营销系统----订单管理
UC编号
SUC001
用例简述
客服对客户下的订单进行管理
用例图
主流程
第一步：客服对收到客户的订单进行管理
第二步：客服联系物流公司发货
第三步：客服确认支付
2）物流公司投递错误率须小于2%
2）系统按照公司原有的编码方式形成送货单号
非UML文档
无
其他
无
b）“查看的商品不存在”系统出现客户查看的商品不存在的信息，回到主要流程2，客户重新选择商品进行查看
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
6.审批过程为并行过程,同时执行分支过程6.1.1和6.2.1.两个分支过程均需执行完毕并有审批结果.若两个分支过程审批都同意,执行7,若一方或两方都不同意.执行7,若一方或两方都不同意,执行异常过程6.3.1
7.营业员通知用户到大厅交纳初装费用.业务收费员收取费用,产生业务费用已讫清单
8.施工班执行现场安装工作,并填写现场施工单
9.装表员根据现场安装结果,为用电用户配置计量表,现场安装,并填写安装记录刘和电表初始示数
10.营业员收集所有工作单据,建立用电客户档案、收费和结算帐户、抄表台帐、监察档案和计量档案。用例结束
业务规则
a.申请户名应无历史欠费记录
这一栏中可以用过程步骤的编号来引用相关的业务规则。若该规则仅作用于本用例，可以加上面例子直接书写。若该规则作用于多个业务用例，建议编写专门的业务规则文档,为每个业务规则编号。在这里引用编号即可。如
Rule001
涉及的业务实体(中英文对照)
Be_XXX(申请单)
分支过程描述
6.1.1业务班长根据现场勘察结果，审批是否同意用电申请。结果返回6
6.2.1配电专员根据现场勘察结果，审批是否同意用电申请。结果返回6
异常过程描述
5.1.1不符合条件，营业员归档申请记录，停止申请过程，用例结束
6.2.1配电和用电两方至少一方不同意，营业员归档申请记录，停止申请过程，用例结束
2.成功建立收费帐户和结算帐户
3.成功建立抄表台帐
4.成功建立监察档案
5.成功建立计量档案
主过程描述
1.用电用户到营业大厅填写用电申请表,提交营业柜台
2.营业员初步核实申请信息,查询该用户是否有欠费记录,符合条件则启动用例
3.营业员录入申请信息,产生用电申请单
4.业务班长审查申请单,产生现场勘察工作单,分配勘察 Nhomakorabea执行任务
业务用例规约示例
用例名称
Bu_申请永久用电
用例描述
低压或高压用电用户向供电企业申请用电.供电企业审查申请资料,进行现场勘察,符合用电条件者进行现场安装,并送电,完成永久用电申请过程
执行者
业务员(代理用户客户操作)
前置条件
1.申请用户资料齐全
2.申请用户之前没有欠费记录
后置条件
1.成功建立用电客户档案
Be_XXX(现场勘察单)
Be_XXX(业务收费清单)
Be_XXX(电表安装工作单)
Be_XXX(用户档案)
Be_XXX(收费帐号)
Be_XXX(抄表台帐)
Be_XXX(监察档案)
Be_XXX(计量档案)
这一栏中可以列出与该业务用例相关的业务实体。一般情况下，业务实体要在晚一些的过程中才能产生。这里为了示意特别列出。在正常建模过程中，这一栏的内容要等建立了业务对象模型以后才能确定。