下载文档原格式
一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如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.可⽀持性
设计约束
设计约束是在实现系统时必须要遵守的⼀些约束，包括界⾯样式、报表格式、平台、语⾔等。
<公司名称><项目名称>业务用例规约：<业务用例名称>版本<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. 扩展点。
