业务建模与需求管理：连接商业战略与软件需求

# 业务建模与需求管理：连接商业战略与软件需求 ## 1. 业务建模的目的与工作流 业务建模工作产品，无论是新创建的还是复用现有的，都将业务战略与软件需求工程联系起来。业务建模学科有以下几个目的： - 理解目标组织中的问题并确定潜在的改进领域。 - 确保客户和最终用户对目标组织有共同的理解。 - 推导支持目标组织的系统需求。 - 理解系统部署所在组织的结构和动态。 业务建模工作流如图所示： ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px A([早期初始阶段]):::startend --> B(评估业务状态):::process B --> C(仅进行领域建模):::process B --> D(业务建模):::process D --> E(描述当前业务):::process D --> F(定义业务):::process D --> G(探索流程自动化):::process D --> H(开发领域模型):::process ``` 在这个工作流中，有多种路径可供选择，决策取决于业务建模工作的目的以及软件开发生命周期的阶段。需要注意的是，活动的顺序并不意味着一个活动完全完成后才能进行下一个活动。实际上，每个活动在项目生命周期中都会多次执行，每次重复时，相关的工作产品都会基于更多的知识进行进一步细化。 ## 2. 关键业务建模活动 ### 2.1 评估业务状态 在早期迭代（很可能是第一次迭代）中，需要评估组织的状态并确定需要改进的领域。此阶段的目标是限制业务建模的工作量。描述完当前状态后，在业务愿景中定义目标状态，以确保明确理解和定义要解决的问题或要利用的机会。评估业务状态包括评估目标组织、设定和调整目标、识别和记录业务目标以及分析业务架构。此活动产生的关键工作产品是目标组织评估。 ### 2.2 描述当前业务 如果在评估业务状态活动中确定不需要对业务流程进行重大更改，并且目的是开发一个软件系统来帮助自动化现有业务流程，那么只需对这些流程和软件需求进行建模。通常，首先定义或细化组织结构，然后定义业务目标、业务参与者和业务用例，并将它们追溯到所支持的业务目标。根据业务建模目标，可以对业务用例进行优先级排序，并为优先级最高的业务用例生成业务用例实现。 ### 2.3 定义业务 此活动定义未来的业务，包括识别业务流程并细化业务流程定义。如果采用用例实现方法，则通过用例实现来设计业务流程实现；否则，定义业务操作。最后，细化角色和职责。定义业务活动的工作流如下： ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px A(识别业务流程):::process --> B(细化业务流程定义):::process B --> C(设计业务流程实现):::process B --> D(探索流程自动化):::process C --> E(细化角色和职责):::process D --> E ``` ### 2.4 探索流程自动化 该活动探索所考虑的业务流程的自动化机会，详细说明要获取、开发或部署的软件系统如何融入组织，并生成一个业务模型以推导软件需求。自动化的范围可以从支持改进业务用例的交付时间，到重组或排序业务流程的活动，再到监控、控制和改进工作方式。通过探索流程自动化机会获得的经验，团队可能能够调整目标和期望，使其更加实际。 ### 2.5 开发领域模型 如果在评估业务状态活动中确定不需要全面的业务模型，只需要一个领域模型，则可以执行开发领域模型活动。在 RUP 中，领域模型被视为业务分析模型的一个子集，仅围绕该模型的业务实体。此活动识别对业务领域重要的所有产品和可交付成果，详细说明业务实体，并提供对业务运营和环境中概念的共同理解。 ## 3. 业务建模的工作产品 业务建模学科产生了以下关键工作产品： |工作产品|描述| | ---- | ---- | |业务分析模型|包含业务事件、业务用例实现、业务人员、业务实体、业务系统和业务规则等工作产品，用于与利益相关者沟通对当前组织的影响，并帮助系统分析师识别需求。| |业务架构文档|将业务架构呈