2.3.2 分析系统内流程
针对每一个系统用例，分析其工作流程，明确相关规则。方法与“分析业务流程”相似，可参见“分析业务流程”，只是两者的对象不同，一个是目标客户组织，一个是待开发系统。
比如上述例子中，将“排队系统”分为“排队机”和“呼叫控制端”两个子系统，同样可以通过2.3.1节中所示的方法，得到“排队机”和“呼叫控制端”的功能需求。
2.3.3 分析业务规则
与业务相关的操作规范、管理章程、规章制度、行业标准等，都可以称为业务规则（Business Rules ，简称BR）。业务规则可以从宏观层面上理解可以包括业务的流程、业务条线包括的业务流程等，微观理解可以理解为具体数据项的加工逻辑，例如A指标是有B指标+C指标运算得出的。在这里，我们更多的采用的是业务规则的微观理解：具体数据项的加工逻辑（如利率的计算公式）、某些特殊的强制性要求（如“查询结果的输出，人名排列顺序缺省的按照姓氏英文字母排列顺序；部门排列顺序缺省的按照公司通讯录所标注的顺序。”）、关键的系统状态转换。系统的状态转换通常使用状态图表示，如下图所示的某流程的审批状态转换：
状态转换图示意
2.3.4 定义业务对象
“定义业务对象”活动的本质是通过分析业务对象将系统的黑盒打开得到其内部结构，也就是子系统或者模块、类、组件。可以说，此活动是软件设计的基础。
将重要业务概念转换为业务对象，并为业务对象建立类以及对象之间的静态结构关系，反映系统的结构约束，作为对用例进行验证的基础。通常可使用类图、E-R图表示业务对象之间的静态结构关系，也被称为业务领域模型。对每一个业务对象包含的具体属性应予以相应的表述和定义。业务对象的提取，通常来自于业务流程、系统流程中，各个活动所涉及到的信息要素，比如：活动“填写账户信息”，则“账户信息”即是一个潜在的业务对象。这些业务对象最终大部分将会直接转换为软件程序中重要的类定义或数据结构。而在《需求规格说明书》中，则需要详细的定义业务对象的每一个属性。
如：上述银行存款的例子，柜面系统涉及的业务实体：存款单、储蓄账户、客户信息（仅作示意）：
E-R图示意
2.3.5 分析操作与方法
在分析系统流程和定义了业务对象后，基于用例场景和业务对象，使用顺序图分析业务对象的操作和方法。这些操作和方法对应于软件设计中类、模块里的方法或函数，或者代表着子系统的功能需求。前面2.1节中提到“分析操作与方法”的活动本质上也应用于从业务需求得到系统需求的过程。
仍旧以银行存款为例，在将“银行”内部打开得到其内部结构（排队系统、柜面系统、柜员），通过顺序图（见图12）分析，我们可以得到“排队系统”和“柜面系统”的功能需求（设计中称为操作与方法）。如果使用特定的UML工具，通过绘制每一个用例的顺序图，可以自然的汇总出内部子系统、对象或模块的功能需求，如图13所示即为绘制图12后工具自然汇总生成的类图。
顺序图示意
顺序图汇总后的类图（显示了类的功能）
作者：fasiondog 来源：http://fasiondog.cn/archives/1400.html