不为有趣之事,何遣有涯之生
不失其所者久,死而不亡者寿

产品之路系列(6) 详细需求分析之系统分解

6 详细需求分析之系统分解

业务子系统划分

待开发的系统有时候相当复杂,涉及不同业务。为了控制分析的复杂度,我们通常需要先将其分解成更小的部分。在需求分析阶段,最好的方式是按照业务来进行划分。

下面是子系统划分的任务指引图:


整个过程可以理解为:划分、标识、呈现三个过程

划分要点

划分业务子系统不是目的,而是一种手段,一种控制复杂度的手段。所以如果业务系统很简单,就用不着划分。

如果处理的是遗留系统的二次开发,需要分析出是不是要增加新的子系统,原来的系统哪些要修改;只有复杂的新系统,需要我们去进行子系统划分的工作。

对于复杂系统,我们通常采用业务职能与产品服务双维度进行分解。

  • 按业务职能分解:适合内部使用的系统,最典型就是产、销、供、管四个部分。划分之前我们先画出组织架构图,然后根据组织、部门之间的相近度,划分出业务子系统即可

    例如某健康体检中心平台,划分出了客服服务管理系统(销)、物资管理系统(供)、体检业务系统(产)、财务系统(管)四个业务域

  • 按产品服务分解:适合外部服务和个别内部系统。划分前,我们先梳理出业务结构树,然后以不同产品服务作为划分标准,有些内部管理系统也适用

    外部服务的如招商银行,根据客户视角的产品服务角度,分出了:一卡通、信用卡、超级网银、财务管理、金融助手等子系统
    内部服务中,某些审批项目由于不同部门扮演的职能角色不同,按照业务维度很难合并,就可以采用按照产品服务维度分为:资金类审批、物资类审批等

  • 双维度划分:特别服务的系统,需要我们进行双维度的划分,先按照某维度做一级划分,再用另一个维度做二级划分

    例如对于一个大型综合性意愿管理系统来说,可以先按产品服务维度划分为:门诊、住院、体检等系统,然后按照业务职能维度对每个系统进行二级划分

  • 按关键特性划分:这种划分比较偏技术性,一般系统偏计算机域主题时,比较适用

    例如:安防系统、楼宇自动化控制系统等

标识接口

正所谓哪里有分解哪里就有接口,系统的关系通过接口来连接。标识接口主要通过思考一下几个问题:

  • 本子系统要其他子系统提供什么服务?
  • 本子系统能够为其他子系统提供什么服务?
  • 这些服务由谁负责提供?谁会使用它?
  • 这些接口哪些是现有的?哪些要修改?哪些要开发?

呈现划分

呈现方式可以通过文字列表的方式,如果比较复杂,最好使用图形来表示

  • 强调纵向分解:层次图
  • 强调横向功能与调用关系:构件图、功能关系图
  • 强调横向数据交换与共享关系:数据流图

根据实际系统复杂度与侧重点,选择其中一种或多种图来表示

输出物

业务子系统划分描述模板

业务接口分析

标识出各个业务子系统之间的服务关系后,就需要针对这些服务关系做逐一的分析,服务关系在软件系统中以业务接口方式来体现。

下面是业务接口分析任务指引:

接口分析要点

注意业务接口与系统接口的区别,一个业务接口可以由多个系统接口组成/实现;业务接口明确是why和what,不涉及how

明确接口的用途和业务价值,可以从三个维度去考度:

  • 1 放在哪个子系统最合适?推荐采用知行合一的方式,由知道接口信息的系统来实现
  • 2 哪些子系统会使用,用来实现什么价值;可以帮助开发人员有效理解,同时也利于测试
  • 3 使用的频率大概是什么样的,可以是精确的值,也可以是一个范围,它可能会影响开发的架构设计

明确完以上信息,接下来便是细化接口的交互过程,可以通过时序图+数据字典的方式来进行描述
最后确定接口设计约束,可能是来自业务,也可能是来自一些外部环境、政治法规、公司政策等。

输出物

未经允许不得转载:菡萏如佳人 » 产品之路系列(6)

欢迎加入极客江湖

进入江湖关于作者