一个完整的业务模型包括业务用例场景、业务用例规约、业务用例实现场景、业务用例视图、业务用例实现视图、业务对象模型、业务规则。其中业务用例场景、业务用例规约、业务用例实现场景是重点。
业务用例场景（图像）
业务用例场景用于描述该业务用例在实际业务中是如何做的。在描述业务用例场景时，不能带有“设计”思想在里面，或者“抽象”、“优化”业务过程，它必须和客户认可的实际业务执行一致。一个业务目标，可能对应有多个业务用例场景。例如，交手机费，通过支付宝充值和通过充值卡充值，虽然最终实现的目标一致，但是是两个业务用例场景。
绘制业务用例场景可以用活动图、顺序图、状态图等工具。不同的工具有其使用场景，为了描述清楚业务，可使用多种图，多角度进行分析。
- 如果事情围绕某个东西展开，可以考虑用状态机图；否则使用活动图或顺序图。
- 如果没有复杂的特殊流程，可考虑顺序图；顺序图表达的内容是业务主角或业务工人之间传递的是什么。
- 如果有复杂的流程，可考虑活动图。活动图表达的内容是业务主角或业务工人做什么。
- 如果流程过多，为了避免活动图过于庞大复杂，可考虑只画核心的、重要的分支，细微的、不太重要的分支通过注解来说明。
活动图示例：
状态图示例：
顺序图示例：
业务用例规约（文字）
文字是图形的有力补充，图形虽然很直观、形象，但是一些细节性的内容还是需要用文字来说明。
业务用例规约示例：
业务用例实现场景（？）
业务用例场景：用于说明业务是怎样执行的。
业务用例实现场景；用于说明如何通过人机交互来完成业务。
业务规则
很多产品经理，在产品策划中不太重视业务规则，大致有两种后果：1.开发人员在开发过程中，不与产品经理商量，自己随意定规则（脱离产品经理的本意）；2.开发人员将问题抛回给产品经理，产品经理需要重新整理业务规则，开发工作继续（出来混还是要还的）。所以，业务规则对于一个系统的重要性不亚于业务需求本身。
业务规则大致可以分为三类：
全局规则
是指那些对系统大部分业务起也是作用的规则；全局规则是跨用例的；例如：用户在系统中的所有操作都需要被记录下来；用户需要有权限才能进行操作等。
要注意区分全局规则和非功能性需求。非功能性需求一般都是系统目标，即系统要做什么，而且会有指标来衡量，例如会话峰值并发数。而全局规则是用来限制功能性需求的，例如会话数量达到一定阈值时暂停新会话建立。
全局规则，通常写在用例的补充规约中。交互规则
产生于用例场景中，在活动转移、状态变迁、对象交互时必然会有一些限制条件，这些限制条件叫做交互规则。例如提交订单时要检查数据合法性等。
交互规则通常写在业务用例规约中（见用例规约一章）。内在规则
内在规则是指那些业务对象本身具有的，并不因为外部交互而变化。例如，用户编号：编号唯一、销户后再次申请编号不重复利用。
内在规则通常被写到业务对象描述文档中。
内在规则案例：
| 属性名称 | 类型 | 精度 | 说明(属性的业务含义以及业务规则) |
|---|---|---|---|
| 用户编号 | 字符 | 12 | 供电局编号（3位）+申请用电年份（4位）+流水号（5位）规则：用电编号唯一，销户后再次申请编号不重复利用 |
| 联系方式 | 字符 | 11 | 手机号或座机号 |
业务对象模型
业务对象模型是在领域建模的过程中建立的。
见下一章：领域模型
