《有效需求分析》一书聚焦于组织应用类软件系统的需求分析环节，介绍了18个按需求组合的关键任务，针对每个任务的一步步指导，以及每个任务输出的“软件需求规格书”片段模板。
待开发的系统有时相当复杂，涉及多种不同的业务，为了控制分析的复杂度，我们通常需要先将其分解成更小的部分。可以根据实现结构来划分，但在需求阶段更推荐根据业务来划分。
1、业务子系统划分
业务子系统划分包括以下三个步骤，
（1）划分业务子系统：根据系统特点，选择合适的划分策略进行分解。对于系统业务简单、用户群单一的系统，没必要划分。对于基于遗留系统开发的系统而言，更合适分析有哪些新增、修改、影响的子系统。对于相对复杂的新开发系统而言，最常用的策略包括，
· 按业务职能分解：一般而言，对于这种支撑、管理业务的系统而言，最典型的业务子系统划分策略就是按“部门职能”进行划分的。而部门职能最典型的就是产、销、供、管四个部分。在划分之前，可以先画出与系统有关的组织架构图，然后根据组织、部门之间的相近度，划分出各个业务子系统即可。
· 按产品／服务分解：通常在开发“外部服务系统”时，我们可以先梳理出“业务结构树”，然后以不同的产品／服务作为划分线索。当然，在某些“内部管理系统”中，也可能采用这种角度来划分。
· 职能／服务双维度划分：对于一些更复杂的系统，有可能需要采用“职能”和“产品／服务”双维度进行划分，先用其中一个维度做一级划分，然后再用另一个维度做二级划分。
· 按关键特性分解：如果待开发的系统是偏向“计算机域”的主题时，那么就需要换一种策略进行分解，如安防系统等，从系统对用户的价值角度识别关键特性，然后逐一再做后续的需求分析。
（2）标识接口、确定关系：正所谓“哪里有分解，哪里就有接口”，在分解完成后，整理出两两业务子系统之间的“业务关系”、“服务关系”，明确各子系统之间的服务接口。
（3）呈现业务子系统划分：根据实际情况选择合适的图表来呈现划分的结果，以便读者建立清晰、直观的理解。常用的模型、图表主要包括层次图、构件图和数据流图三种。
只有一级分解的情况，建议直接用列表呈现，通常只在有两级、多级分解时才会使用层次图。如果各个业务子系统之间存在横向行为、服务、调用关系需要呈现出来，最合适的模型就是构件图。
业务子系统描述及说明模板，
划分业务子系统不是目的，而是一种手段，一种控制复杂度的手段。
2、业务接口分析
标识出各个业务子系统之间的服务关系之后，就需要针对这些服务关系（即业务接口）做逐一分析。分三个步骤，
1、明确接口的用途与业务价值，也就是Why的问题。在这一步中，最重要的是厘清以下三个问题。
哪个子系统实现该接口是适合的？采用“知行合一”原则来判断，即由“知”道接口所需信息的子系统来实现接口（即“行”）。
哪些子系统会用到，用来实现什么价值？即达成的业务目的是什么。这样能帮助开发人员更有效的理解，同时也利于测试。
使用频率大概是什么样的？最好给出典型的频率值，可以是精确的值，也可以是一个范围，并且最好是有一些相关的场景信息。
2、细化接口的交互过程，在细化过程中，会使用到两种工具：一是时序图，呈现出接口的交互过程；二是数据词典，细化地定义出每次交互过程中数据包的构成情况。
3、确定接口设计约束，看客户技术管理部门是否有要求使用特定的数据、通信协议，或者遗留系统带来的限制；其次对数据传输、数据查询、加解密方面的性能要求进行一些分析；还应该考虑系统的部署环境（如服务器、网络）、使用者特点（频率、操作环境）等方面是否会带来一些设计约束。
业务接口分析模板，
业务接口是指不同业务子系统之间的服务关系，因此只要系统中存在多个业务子系统（也包括修改、影响的子系统）就需要执行该任务。
网友评论