业务用例规约示例
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机从银行卡的磁条中读取帐户代码， 并检查它是否属于可以接收的银行卡。
- 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(计量档案)
这一栏中可以列出与该业务用例相关的业务实体。一般情况下，业务实体要在晚一些的过程中才能产生。这里为了示意特别列出。在正常建模过程中，这一栏的内容要等建立了业务对象模型以后才能确定。