业务建模的范围

根据环境和需要的不同，业务建模工作的范围可以不同。下面列出六种这样的场景。

场景 #1 － 组织图

您可以为组织及其流程构建一个简图，以更好地了解对于正在构建的应用程序有哪些需求。 在这种情况下，业务建模是软件工程项目的一部分，主要在先启阶段执行。 这些类型的工作在开始时常常没有打算更改组织，只是进行绘图，但实际上，构建和部署新应用程序总是包括一定程度的业务改进。

场景 #2 － 领域建模

如果您构建应用程序的主要目的是管理和提供信息（例如订购管理系统或银行系统），则可以选择在业务级别构建该信息的模型，而无需考虑业务的工作流程。这称为领域建模。通常，领域建模是软件工程项目的一部分，在项目的先启阶段和精化阶段执行。

场景 #3 － 一项业务多个系统

如果您正在构建大系统或一系列应用程序，则可能有一项业务建模工作将要作为多个软件工程项目的输入。 业务模型帮助您查找功能需求，并且作为构建应用程序系列的体系结构的输入。 请参阅指南：从业务模型到系统。在这种情况下，业务建模工作常常被视为一个独立的项目。

场景 #4 － 一般业务模型

如果您正在构建将由多个组织使用的应用程序（例如，销售支持应用程序或记帐应用程序），在整个业务建模工作中，使这些组织都在开展业务时避免对于系统而言过于复杂的需求（业务改进）是很有用的。但是，如果无法使这些组织就这一点取得一致，则业务建模工作能帮助您了解和管理这些组织在对应用程序的使用方法上的差异，并且使您能更轻松地确定哪些应用程序功能应优先。

场景 #5 － 新业务

如果某个组织决定启动一全新的业务线（业务创建），并且将构建信息系统来支持该业务，则需要执行业务建模工作。在这种情况下，业务建模的目的不仅是找到系统需求，还要确定新业务线的可行性。 在这种情况下，业务建模工作常常被视为一个独立的项目。

场景 #6 － 修改

如果组织决定彻底改变开展业务的方法（业务重建），则业务建模本身常常是一个或多个项目。通常，业务重建分多个阶段进行：设想新业务、反向设计现有业务、正向设计新业务和构建新业务。