业务子系统划分

因为很多系统会涉及多个问题域，所以如果直接对整个系统进行功能需求、数据需求和非功能需求主线的梳理，就会很困难。

应该先从业务角度，把系统涉及的问题域分解成不同的业务子系统，以便逐一分析。简单来说，这个任务就是从黑盒子视角回答一个问题：系统涉及哪些子问题，它们之间有什么关系。

当产品经理站在客户维、业务维的角度，看到的东西将会和技术为、实现为完全不同。而使用技术维、实现维的划分，用户很难参与，也就无法保证需求的完整思考。

所以，理解为什么要根据业务划分子系统，是做好这个任务的关键。如果系统设计的业务简单、用户群单一，就没有必要划分，也可以跳过这个任务。

首先需要划分子系统。划分子系统不是最终目的，而是一种控制复杂度的手段。如果系统设计的业务简单、用户群单一，就没有必要划分。

对于需要划分的系统，需要采用合适的策略。对于比较复杂的新开发系统，最主要的策略包括按业务职能划分、按产品/服务分解、高维度划分、按关键特性分解。

一般来说，对于支撑管理业务的系统，最典型的业务子系统划分策略就是按部门职能进行划分。部门职能最典型的就是产销供管四部分。所以在划分之前，可以先画出跟系统有关的组织架构图，然后根据组织部门之间的相似度划分出各个业务子系统。

在开发外部服务系统的时候，可以先梳理出业务结构树，然后以不同的产品和服务作为划分线索。当然，在某些内部管理系统里，也可能采用这种角度来划分。

对于一些更复杂的系统，有可能采用职能和产品/服务双维度进行划分。先用其中一个维度进行一级划分，然后再用另外一个维度进行二级划分。

如果待开发的系统偏向计算机域主题，就需要从系统对用户的价值角度识别关键特性，然后逐一进行后续的需求分析。

对于基于遗留系统开发的系统而言，不太建议全面转向按业务角度划分。更适合的方法是分析需要新增哪些子系统、影响哪些原有子系统，以及哪些原有子系统需要修改。

下一步是标识接口、确定关系，也就是整理出两两业务子系统之间的业务关系或服务关系。典型的思考要点有如下几个：

产品经理需要选择一种合适的方法来呈现这种划分。当然，也可以直接用文字列出划分结果。

只用文字描述会存在一些缺陷：一方面，它显得不够直观；另一方面，不能直接、有效地体现业务子系统之间的业务关系或服务关系。这个时候就可以借助一些模型图表来呈现划分结果。

最常用的模型图表有这么几种：

层次图：如果各个业务子系统之间的关系比较简单，产品经理只想强调纵向分解，那么建议使用这种最简单的层次图。
构建图：如果各个业务子系统之间存在横向行为或服务调用关系需要呈现出来，那么最合适的模型就是 UML 中定义的构建图。虽然构建图标准中定义了各种模型元素，但通常需要用到的元素只有业务子系统、业务子系统间的服务关系、服务使用方和服务提供方。
数据流图：如果各个业务子系统之间的业务关系和服务关系主要表现为数据共享、数据交换，那么推荐使用 IDEF 中定义的数据流图来描述。

最终的业务子系统描述文档，第一部分是图表部分，选择合适的模型呈现业务子系统。第二部分是对模型中业务子系统服务接口的简要说明。

业务子系统说明由以下三个部分组成：

服务接口说明由以下四个部分组成：