9.2.2 基于场景进行业务需求建模
需求工程方法论提出了基于业务场景的需求建模过程，总体遵循“正向可推导，反向可追溯”的原则，从需求阶段即采取有效的措施尽量将工作进行量化，从标准、阶段、方法等多个角度对需求过程进行建模，并通过一系列的方法和措施为软件工程后续阶段的量化和关联打下基础，从而实现软件开发全过程的有据可依，有法（原则、任务）可依。其总体过程大致如下：
1.需求准备
根据项目之前的可行性分析报告、技术协议、调研记录（包括会议、访谈等）分析总结汇总形成具体可量化的业务目标，一般使用表格展示最终结果。
同时，根据项目利益相关方列表、单位组织结构、岗位职责和各种调研记录，将统计所有相关涉众信息，并使用UML用例图表现涉众间的依赖和继承关系，最后使用列表罗列每个涉众对当前业务系统的期望，并根据对实际项目的影响程度和重要程度对涉众的每个期望赋予优先级，作为后续设计和开发任务分派的基本依据。
2.业务建模
根据已经量化的业务目标，针对每个业务目标分别结合与此相关的涉众进一步划分出来的业务角色建立业务边界。即，为每个业务目标划分业务边界，对此业务有主观发起愿望的角色赋予业务主角，被动参与此业务目标的人员被称为业务工人。
针对每个业务边界，继续量化为使用UML的业务用例图建模，如实反映现实业务问题，形成反映具体某个业务场景的业务用例视图，作为业务场景的静态展示视图。
针对业务用例视图中的每个业务用例，使用UML活动图（泳道图）继续细化和分解，结合业务主角和业务工人，将业务用例需要表达的业务执行过程动态展示出来，形成业务情景视图。另外，针对每个活动图无法表达的前置/后置条件（来自于业务用例），涉及的业务实体等使用业务用例规约表，显式表达出来。
同时，针对所有业务用例形成反映实际业务流程的业务场景视图（活动图），业务场景视图中的活动全部由业务用例汇总形成。通过两者的结合检测业务场景是否满足业务需求，检测业务用例是否有超出范围或遗漏的情形出现。
针对业务实际中存在的单据、报表等信息，进行初步拆分和统计，形成业务实体，方便后续节点的演进和使用。(https://www.daowen.com)
3.系统建模
针对业务情景视图中的活动，遵循在计算机系统中执行的活动，通过直接关联、拆分、演绎等多种手段映射为系统用例。系统用例发起人员即为系统的用户。多个系统用例结合业务场景形成计算机中执行的系统用例场景视图。
针对每个系统用例向下分解形成反映具体计算机执行过程的系统情景视图（活动图）。
针对每个系统情景视图，通过原型界面工具，绘制反映计算机动态执行系统情景的原型页面，结合概念实体，原型界面主要为客户展示界面布局和核心业务字段信息。若干个原型界面通过前台界面内部的Form表单元素、界面按钮、数据列表等，后台的业务Business处理逻辑方法以及最终关联处理的实体Entity，形成结构化的表格表达形式，将系统原型界面执行过程形式化、规范化，方便后续设计的开展。
系统用例按照业务用例视图范围向上汇总即形成反映计算机系统执行业务过程的系统模块视图。
概要视图是一种虚拟视图。由原型界面中的各个系统情景中的前台页面元素、业务处理逻辑和关联实体经过自动统计形成的，主要用于汇总和去重，以及为设计和开发做好前期准备。
用户视图也是一种虚拟视图。由系统用例场景视图转换角度后形成，用户视图主要通过最终用户的角度，检测当前角色用户在系统中功能是否缺失、是否多余等，用以再次确定业务需求的采集是否真实有效地反映用户期望。
总体流程可参考图9-19建模过程方法所示。
图9-19 建模过程方法
