第10章 功能的概要设计
功能的概要设计，是功能设计三步骤的第一步，它是对功能层的整体规划和设计。功能的概要设计是依据业务架构，对需求工程中收集到的功能需求一览进行确定、分类、规划等的工作，最终将功能需求一览转换为业务功能一览，它是后续各个设计阶段的判断设计内容、工作量等的依据。
10.1 基本概念
10.1.1 定义与作用
1．定义
功能的概要设计，是对需求工程收集到的功能需求一览进行进一步的梳理，确定真实的功能，并对“业务功能”进行分类（活动、字典、看板和表单），最终形成业务功能一览，它奠定了后续功能设计与开发的基础。“功能”与“业务功能”已经多次出现了，那什么是功能和业务功能呢？
（1）功能：完成同一目标的操作方法、数据结构、管理规则形成的模块就是功能。
（2）业务功能：完成某个具体的业务目标的功能就是业务功能，如合同签订、计划编制。
2．作用
从软件工程上功能的全过程看，这是对需求工程收集到的需求按照功能设计标准进行的第一次设计，也是从需求工程进入到设计工程的转换点，它的作用是将需求阶段的成果用设计的标准进行梳理、分类、规划、汇总，为后面的详细设计奠定基础。功能的概要设计是粗线条的，重点是将尚未完全确定的“功能需求”确定为正式的“业务功能”。
（1）需求分析：对需求资料进行分析，确定了必须提供的功能需求一览／需求4件套。
（2）概要设计：对功能需求进行规划、分类等，最终确定系统要实现的业务功能一览。
（3）详细设计：对已确定功能进行定义，给出满足业务处理的业务原型（业务4件套）。
（4）应用设计：加入系统功能描述，给出满足客户体验的应用原型（组件4件套）。
10.1.2 内容与能力
1．作业内容
功能的概要设计的内容主要有两大类，其一是业务功能分类，将功能需求一览转换为业务功能一览；其二是对分完类的业务功能进行规划。
1）业务功能的分类
需要将收集到的功能需求进行分类，找出它们的共性、特点，这为后续建立通用的业务功能设计模型奠定了基础。
2）业务功能的规划
通过规划用的关联图，可以交互印证功能需求是否是必要的、有无重复的、有无可以合并的同类功能，最终确定功能需求一览中的哪些功能需求留下、哪些不要，留下的就成为正式的业务功能，注意这两者的区分。
（1）功能需求：是功能的“需求”，尚未最终确定这个“需求”是否是必须要实现的功能。
（2）业务功能：是已经确定为必须要实现的功能，且已分类（活动、字典、看板和表单）。
3）业务功能一览
最终，将完成了分类和规划的功能汇总成业务功能一览。
2．能力要求
功能的概要设计，需要根据需求分析的成果功能需求一览、架构的概要设计成果业务架构图等资料进行功能的规划，因此需要具备以下基本能力（不限于此）。
（1）充分地理解需求分析资料的能力。
（2）充分地理解业务架构资料的能力。
（3）充分理解、熟练地掌握功能规划的设计方法。
（4）掌握基本的数据分析和设计方法，包括基础数据、数据库的知识。
10.1.3 思路与理解
功能规划的重要目的之一就是要确定功能需求，利用业务架构虽然确定了一些功能需求，但是当系统的功能数量非常多且逻辑关系很复杂的时候，由于很多的功能并不在业务流程上，它们之间可能只有简单数据的交互关系并没有业务逻辑关系，所以仅用业务架构图无法确定这类功能之间的关系，因此也就难以判断这部分功能需求的真伪。此时就需要利用功能关联图从数据关系判断功能需求，用“数据关系”可以判断出如下信息。
● 在已知的功能需求一览中是否存在重复的功能需求。
● 通过功能关联图，可以判断出还缺少哪些功能需求（如维护基础数据的字典功能）。
● 确定功能间的数据关系，可以防止需求变更时出现数据的缺失现象等。
仅具有数据关系的功能数量会远大于具有业务逻辑关系的功能数量，前者之间可能没有严谨的业务逻辑关系，而仅有简单的数据之间的引用或是参照关系。功能关联图给业务设计师提供了另外一个可以整体观察、理解功能需求之间关系的视图。有了业务架构图、功能间的数据关系视图，基本上就可以确定功能需求一览中的全部功能需求是否要转换为业务功能，以及增加、补全在需求分析中缺少的功能。
10.2 业务功能1——分类
10.2.1 业务功能的分类
在需求分析阶段，按照业务领域进行了分类，所谓的分类就是将具有共性的功能归集到一起，这个共性就是“业务领域”，这个分类可以让业务设计师了解到：收集到的功能需求覆盖了哪些业务领域、每个领域中包含哪些功能需求，通常来说，业务越复杂、涉及的业务范围越广，则构成的业务领域数量也就越多。
在设计阶段，就需要从设计的视角研究这些功能并再次抽取它们的共性，那么在设计阶段这些功能的共性是什么呢？这个共性就是对数据的“处理分工”不同，也就是说可以将全部的业务功能按照它们在处理数据时的分工进行分类。既然是按照数据处理的分工来区别功能，那么在说明功能的分类前，首先要说明数据的分类方法。下面就按照：数据用途分类→功能分类→功能间的异同的顺序进行说明。
1．数据用途分类
在构建管理信息系统时，可以按数据的用途划分为三个区，即数据的生成区、数据的加工区和数据的应用区。
1）数据生成区与过程数据、基础数据
数据生成区，顾名思义，就是将原始数据输入到系统中的区域，在这个区域产生的数据根据其用途可以分为两类，一类是“过程数据”，另一类为“基础数据”。
（1）过程数据。
在企业的生产活动过程中第一次产生的、没有经过任何加工的数据就称为过程数据。“过程”指的是业务生产的过程。软件的设计工作大部分都集中在这个区，例如，架构设计、功能设计、数据设计、管控设计等，通常所说的“业务数据”的绝大部分都属于此类数据，例如，销售数据、生产数据、财务数据、物流数据、人资数据等。
注：过程数据与历史数据的差异
过程数据是数据分类的一种，而历史数据是个时间概念，与正在处理的数据相比，已经处理完成的数据就属于历史数据了（不论它是过程数据还是基础数据）。
（2）基础数据。
企业中需要规范化并作为企业标准的数据，称为企业的基础数据，例如，客户资料、材料编号、产品价格、组织结构、员工履历等。基础数据是由相关部门按照企业规则预先编制好的。基础数据约束了过程数据的输入范围、标准，以及为过程数据提供了属性定义。编制基础数据，是客户方面推进信息化建设必须做的重要工作，基础数据也是未来构建系统主数据的核心内容。
注：基础数据与过程数据的转换
在用系统界面进行过程数据的输入时，如果基础数据作为界面上某个字段的选择对象，那么这个基础数据一旦被输入后，就成为过程数据的一部分了。
2）数据加工区与加工数据
对收集到的过程数据，按照不同目的加工（抽取、转换、清洗……），是对过程数据进行加工的区域，这个区域主要由技术工程师进行整体的分析、设计和开发，由业务设计师提供辅助的工作（数据表关系、计算公式、业务逻辑等内容）。经过加工完成的数据称为“加工数据”，它们被按照用户的关心维度、分析报表的种类预先分类存储。
3）数据应用区
利用加工数据，可以方便用户利用单据、报表以及各类静态、动态的方式进行查询、展示、分析。例如常见的加工数据有：销售分析、产值分析、成本分析、绩效分析、财务月报表等。
4）过程数据与基础数据的差异
（1）过程数据：
数据中包含大量的原始凭证类数据，如收据、发票、合同、支付、验收等，显然这样的数据一旦输入并确定后是绝对不允许进行维护的（不能更改数据，更改此类数据可能触犯公司规则甚至是国家法律）。
（2）基础数据：
它是企业的标准，作为基础数据它是需要与时俱进的，需要不断地进行维护以保持数据符合要求，如市场价格、新材料规格、企业知识库等。当然已经转换为过程数据的基础数据也是不能变更的，因为此时它已经属于过程数据了。
5）过程数据与加工数据的差异
（1）过程数据：
收集的是生产过程中第一次输入的数据，同时也是利用收集数据的过程对业务进行“过程管理”的载体，所有需要进行事前、事中管理的对象，都要在数据收集的过程中加载相应的管理规则。
（2）加工数据：
是对过程数据进行了加工处理后得到的数据，并按照应用的目的进行了归集，对加工数据的利用是BI（商务智能）的基础，它的重点是通过已有的数据，分析已发生的问题，发掘未来的价值。
2．业务功能的分类
有了三种数据的用途分类后，按照对不同数据处理的分工可以将业务功能划分为4大种类，即：活动功能、字典功能、看板功能和表单功能。
1）活动功能（以下简称活动）
活动，是指专门利用“窗体”形式来记录、展示在生产过程中产生过程数据的功能，之所以将这类功能称为“活动”，就是因为它们是企业中实际操作工作在系统中的映射（除去字典类工作），同时企业的管理规则也是主要加载在活动功能上的，活动是4类功能中数量最多、使用最广的一种。所有业务流程上的节点必须是活动，因为只有活动才能驱动流程的运转。活动对应的是数据分类中的“过程数据”，所有过程数据都是通过活动功能输入的。
2）字典功能（以下简称字典）
字典，是专门利用“窗体”的形式来维护需要标准化的企业基础数据。作为对基础数据进行维护的功能，它包含对数据的记录、展示、更新、发布的功能，由于字典是用来规范企业标准的工具，因此字典只能由特定的管理人员使用。字典对应的是数据分类中的“基础数据”，在活动功能中所有属于基础数据的字段原则上都是通过字典功能输入和维护的，字典功能是通过从功能规划找出来的重要对象之一。
3）看板功能（以下简称看板）
看板，是专门利用“窗体”的形式来展示经过加工处理后的数据的，它是用来“看数据”的，它不能进行“数据输入”，它可以利用窗体所具有的各种灵活多变的查询和展示形式（图形曲线、数据穿透等）。看板通常用门户、监控台、仪表盘、导航等形式来展示信息。看板可以用来展示上述三类数据。
4）表单功能（以下简称表单）
表单，是专门采用“打印”的形式来展示数据的，适用于各类需要打印、盖章，并以纸质的形式保存的场景。其中，“表”指的是各类统计和分析的“报表”；“单”指的是各类凭证形式的单据，这二类形式的区别如下。
（1）报表：产值分析、成本分析、绩效分析、财务报表等数据。
（2）单据：发票、收据、领料单、合同书、各类财务凭证等数据。表单可以用来显示上述三个类型的数据。
3．业务功能之间的关系
1）业务功能分类与数据分类的关系
数据用途分类与业务功能分类的关系从数据分区图和数据分类的关系可以看出业务功能的设计顺序，记录类功能（活动、字典）一定要先做，特别是活动，因为它不但关系到业务处理方式，而且决定了管理的方式；展示类业务功能（看板、报表）可以放在后面，因为只要有了满足管理规则的数据，如何查看和展示都可以做到，不足的数据也可以随时增加。
2）各业务功能的重点
4类业务功能各有自己的重点，内容展示了它们在未来完成的系统中具有的功能.
3）架构规划的关注顺序
有了业务功能分类的概念之后，业务设计师在进行需求获取、需求分析，以及架构设计时就知道了对功能关注的顺序，由于活动、字典等是产生数据的功能，在架构、规划时重点要先关注这些功能，活动是构成业务架构的要素，需要重点关注并先行确定，否则架构图设计时就没有节点了；同时活动和字典要先规划，因为它们产生的过程数据和基础数据是进行数据规划的依据。与这两个功能相比，看板功能和表单功能就可以稍微滞后，因为这两者不直接产生过程数据和基础数据，它们以“看数据”为主，它们需要的只是对过程数据和基础数据的加工而成的加工数据，而且看板功能和表单功能会随着客户对信息系统的理解加深，会产生新的需求变化，所以放到后面再设计反而会稳妥一些。
4．功能分类对规划设计的作用
功能的分类可以对规划设计起着一种检验的作用，可以从以下两个方面考虑。
1）系统的划分
在一个独立、完整的系统规划中，应该考虑包括4种功能，分别完成对系统包含业务的输入（活动），建立基础数据（字典），监控业务处理过程（看板）以及分析处理结果（表单）。这是从业务应用视角进行的规划，可以保证在实操时不出现遗漏。
2）开发阶段的划分
当开发的内容比较多时，常常会采用分期开发的方法，此时在划分每一期的功能时也要注意功能类型的平衡，每一期开发功能的数量不论多少，都必须要保证完成的功能可以支持某类业务的处理，避免某一期都开发活动，某一期都在开发看板这样的做法，这种做法会导致每一期完成的功能都不能独立地进行业务处理。从这些对比可以看出来，按照业务功能分类进行设计，不但不会影响业务领域分类的内容，而且还会加深对功能需求的理解，并为功能规划结果增加了一个检验的手段。
10.2.2 业务功能的分类视图
有了对业务功能的分类定义后，下面就业务功能的分类方法进行说明，分类的方法可以有两种：利用业务领域分类表，利用功能需求一览。
1．业务功能的分类视图
1）业务领域分类表利用业务领域分类表，按照不同的业务功能分类用不同的颜色标示
2）功能需求一览
利用已有的功能需求一览在表的右侧增加“业务功能分类”栏，在栏中分别标示出业务功能的分类名称，形成“功能需求一览”，从功能需求一览的表格中可以看出，业务领域分类表容易从整体上观察功能的发布情况；功能需求一览容易进行精准的分类，以及确定功能的准确数量。
2．业务功能分类的作用
对业务功能进行分类对理解设计方法有很大的帮助。
（1）建模方法：分类给出了不同类型的设计规律，大幅度地减少了模型的数量。
（2）确定工作量：由于4种功能的特点不同，可以定性、定量地确定开发工作量、时间。
（3）设计顺序：对业务架构、基础数据有影响的内容可以先设计，其他可以放到后面，例如，活动、字典必须要先设计，看板和表单可以滞后（不影响业务架构和规划）。
（4）设计能力匹配：由于4类功能的难易度不同，分配设计资源时有依据，例如，字典／基础数据部分比较难，可以让能力较强的设计师承担，等等。
以上对业务数据（3种）和业务功能（4种）进行的分类，可以体系化、工程化地认识设计对象的用途、形态、技术、标准等，读者可以认识到，这些分类并不影响数据和功能原有的属性、特点，它们只是一种理解对象的手法，每一次的归集与提炼都是对研究对象的认知的一种提升。当然，随着新需求不断出现和技术的进步，上述的划分也会发生变化，或者根据实际情况，灵活地使用上述功能也是完全可以的。另外，数据分类不只这三类。
10.3 业务功能2——规划
有了功能和数据的分类定义后，就可以进入到概要设计的核心工作：规划。规划是将需求分析的成果确定下来的重要步骤，概要设计的最重要成果之一就是将需求分析成果——功能需求一览转换为业务功能一览。
10.3.1 功能关联图
1．功能规划的概念
将功能需求一览中的功能需求确定为正式的业务功能的过程，从原始的①研究对象出发，分别获得了需求分析的成果②功能需求一览、架构概要设计的成果③业务架构图，但是，由于不能将②与③完全整合在一起，同时也由于很多的业务功能并不在业务架构图上，所以不能确定功能需求一览中的哪些需求是独立的，哪些是不需要的，哪些是重复的，哪些可以复用，哪些可以共用等，这样也就难以确定最终的业务功能一览。因此，需要从另外一个视角来研究所有功能之间的关系，即使功能之间可能没有业务逻辑关系，只要存在简单的数据引用／参照关系，就可以确定全部功能之间的关系，这种表达方式就是“功能关联图”。为了理解功能关联图的作用，下面先来看一下业务架构图与功能关联图的区别。
业务架构图：要素之间的关系是以业务逻辑为导向的（同时也有数据关系），在架构图中如果要素之间没有业务逻辑关系，仅仅是有数据的引用关系是不能形成架构关系的。
功能关联图：要素之间的关系是以数据引用／参照为导向的，只要有引用／参照关系就可以关联，不论要素之间是否存在着业务逻辑关系。
功能关联图提供了另外一个不同于业务架构的方法将全部有数据关系的业务功能关联在一起，这个关联图可以帮助业务设计师理解完成的功能、功能之间的关系，避免功能的重复，为功能的共用、复用打下了基础。功能关联图可以有不同粒度的表达，首先用大粒度的要素来表达系统之间的关联，然后用中粒度的模块，最后用小粒度的业务功能，逐次细化，最终清晰地表达出各种粒度功能之间的关系。
经过功能关联图的检验，确定了每一个业务功能的唯一性、有效性，就完成了从功能需求一览向业务功能一览转换的准备工作。
2．规划的范围与对象
1）规划范围
范围的确定依据是规划的目的，规划并不要求一定在同一张图上把全部的业务功能表达出来，而是根据规划的目的将相关的功能纳入进来，通常是以某个业务领域为范围或是以某条业务流程／数据线等为主线，将相关的功能关联起来。
2）选择对象
范围确定之后，下一步就是确定这个范围内的功能。一般来说，规划的对象以输入类功能为主，包括活动、字典，其他如看板和表单的作用是对（加工后）加工数据的展示、查询，基本上相互之间没有关系，可以不在关联图中出现。规划，是从一个更大的范围，概要、粗略地理解各个功能模块之间的关系，这个规划有意识地忽略细节，观察整体功能之间的相互作用。
10.3.2 功能关联图的设计
功能关联图有多种表示形式，但规划的原则是：从上到下、从粗到细、从区到线、从线到点，关联的方式有：功能区关联、功能线关联、功能点关联等。
1．功能的区关联
功能区块规划主要是采用“区块”的方式，对功能进行粗粒度的划分，观察不同功能区域之间的叠合关系。用“区块”做规划时，用方框画出不同的区块，每个区块具有不同的功能，但要注意，此时区块的功能粒度根据规划的范围不同而不同，一个区块代表的功能粒度可以大到是一个系统，也可以小到仅仅是一个业务功能。
业务功能被放置到按照业务领域划分的区域内，但是业务功能之间彼此有着业务逻辑上和数据上的关联，因此，可以将有关系的业务功能用虚线框关联起来，从而方便从一个大的视野来观察功能的分布和关联关系，同时还可以用功能的组合来构建灵活的系统，这个方法在产品规划时非常有效。
2．功能的线关联
当功能之间的关系更加复杂，功能的个体之间还存在着关联时就很难用简单的方框进行关联了，此时可以采用线关联的方法进行逐一的关联
3．功能的点关联
在某个业务功能上，标注出使用的字典名称，这样就可以知道每一类基础数据第一次在哪个功能点上被使用，避免基础数据在同一个系统中被输入两次（原则上，基础数据只能被输入一次，下游的活动只能引用第一次输入的基础数据）。
4．不同业务流程间的关联
在进行某个业务处理时，常常会发现这个处理需要由若干的不在同一条业务流程上的功能协同完成，此时为了避免混乱或是功能重复，可以将相关的业务流程排列在一起（此时不必用标准的流程图表达，而只是将流程上的活动标示出来就可以），然后按照要处理的目标将相关的功能关联起来。
10.3.3 架构与规划的区别
通过前面的说明已经知道了业务架构和功能规划的作用和区别，为了加深理解，再将这两种不同目的的图形进行一下对比。
1．架构与架构图
架构，是将要素（功能）按照标准的架构模型用业务逻辑进行关联的设计，架构的行为就是对业务进行优化的行为。架构设计的成果是架构图，架构图是逻辑图。不同架构图之间有逻辑关系，例如，分解图是框架图中某个业务领域的展开。每个图形中的要素之间都必须有明确的业务逻辑关系，架构图形的描绘必须正确，严格地表达出要素之间的顺序、位置、包含关系，同时，要素之间不但有业务逻辑关系，同时也有数据关系。业务架构图是客户业务的视角，它是客户业务过程在系统中的映射。
2．规划与关联图
规划，是将要素（功能）按照数据关系关联起来的设计。与架构的体系化作业相比较，规划更多是围绕着某个课题进行的，例如，业务财务一体化的功能规划等。功能关联图的表达可以比较自由，例如，区块可以重叠表达，因为重叠是表达功能复用关系的一个重要方法，它不重视要素之间的主次。功能关联图的重点是指出要素之间的数据关系（如果用业务架构图作为背景辅助效果最好，没有也可以），只要表达出要素之间的数据关系就可以。功能关联图各自是独立的，不同的图之间没有必然的关系。功能关联图是系统设计的视角，它解决的是功能的布局、复用、共用等。功能的规划，对于设计通用产品特别是具有模块组合功能的产品尤为重要。因为相对于设计“一次性的项目”，通用产品更加注重功能的复用、共用，以及应变性能，所以经过功能规划后的产品具有更高的灵活性，而没有经过功能规划的产品，遇到需求变化时可能就难以应对。从功能关联图表达的内容来看，业务架构图是不能替代功能关联图的作用的。
10.4 业务功能3——汇总
10.4.1 业务功能的最终确定
功能的概要设计最后一项就是整理业务架构、功能的分类、规划的成果，通过业务架构和功能规划，汇总出业务功能一览，获得了如下的成果。
1．业务架构
通过参考业务架构、业务设计的内容，对业务功能的确定还有如下的影响（不限于此）。
（1）在架构过程中，通过业务优化，可以补全很多原始业务构成中的缺失点。这里的业务优化指的是站在用户的视角，通过业务合理性、业务逻辑的通顺来加减业务的内容。
（2）设计特定的业务处理方式时，如成本精细管理，为了构建“精细管理”的体系，又会增加很多在需求调研时没有的功能。
2．功能规划
功能规划是从数据关系视角进行的功能梳理，这个梳理工作同样也会带来功能数量的调整。
（1）通过分类、规划，确定了业务功能是否可以共用、是否有重复等。
（2）大量增加字典类的功能（因在需求调研、分析时字典功能与基础数据还不是重点）。
（3）根据业务处理的内容，确定需要输出的表单等。总的来说，经过了架构和规划之后，功能的数量都会有一定程度的增加。有了上述的成果，就可以将功能需求一览中的“功能需求（按照业务领域分类）”确定为“业务功能（按照业务功能分类）”，并整理完成业务功能一览。
10.4.2 业务功能一览
在功能需求一览上增加内容，形成了业务功能一览
业务功能一览给出了业务功能的内容、分类及数量，这个表不但用来指导详细设计，而且还是重要的软件开发项目管理的依据，根据需要还可以在表中增加诸如设计难度、优先级、需要的资源、设计时间等内容。到此，就完成了对功能的概要设计。
小结
功能的概要设计，通过对来自于需求分析的功能需求一览进行分类、规划等一系列的处理，最终将信息系统必须要实现的业务功能名称全部确定下来，并形成了业务功能一览。在架构的概要设计中，利用业务逻辑对功能进行了梳理和确定，在功能的概要设计中又利用了功能的数据关联对业务功能进行了不同视角的梳理和确定，通过这两个视角（业务逻辑与数据关联），业务设计师基本上就对未来信息系统中的业务功能有了全面的理解和掌握。
（1）功能分类：大幅度地减少了功能的类型，使得设计的复用提升，例如，归集到“活动”类型的功能都具有相同的特点，这就为统一功能设计的标准、规范打下了基础。
（2）功能规划：功能规划过程中可以发现哪些功能被重复地利用，功能规划不但是对功能需求的确定，也是为后续实现功能的复用设计奠定了基础。
对功能层面的规划设计是与架构层面的规划设计不一样的。
（1）架构层面：由于架构受到业务逻辑的影响，而业务逻辑反映的是企业的业务事理，只要企业的业务处理方式发生变化，那么业务架构就一定会发生变化，业务架构发生变化是不可避免的，因为只有如此，企业才能适应外部变化，不断前进。
（2）功能层面：通过功能的规划设计，增强功能之间可以支持灵活应变、复用的能力，尽量减少功能层的变化，也就是说，功能层的变化是有的，但是设计得当会减少由于需求变化带来的影响。
功能规划，是软件功能复用的开始
功能的概要设计，帮助设计师聚焦于功能，从多个视角研究需要做的功能，寻找它们之间的特点、共性、个性的存在，例如，在多处被用到→有共用的可能性，在不同的系统中被用到→有复用的可能性等。解决上述这些问题，利用功能一览很难完成，因为从功能一览上不能直接看出功能之间的关联关系（包括数据关系），利用功能关联图就可以在不受业务逻辑的约束下对系统中的全部功能进行整体规划，俯视功能的全貌，进行任意的组合和协同。业务架构图，给了设计师一个从“业务逻辑”视角看功能关系的方法；功能视图，给了设计师一个从“数据引用／参照”视角看功能关系的方法。从这两个视角观察就可以全面地掌握功能之间的关系。