第13章 功能的详细设计
功能的详细设计，是功能设计三步骤的第二步，它是对功能的业务细节设计。功能的详细设计是参照需求工程中的功能需求规格书，并根据功能的概要设计成果——业务功能一览，对每一个已确定的业务功能进行细节的推敲和设计，给出该业务功能的具体原型界面、控件定义、规则说明，以及逻辑图形的表达。
13.1 基本概念
13.1.1 定义与作用
1．定义
功能的详细设计，是将完成某个业务处理所需要的原型界面、数据结构、控件定义、操作方法以及相关规则整合在一起的设计过程。
功能的详细设计，是对需求分析阶段成果——功能需求规格书（简称：需求4件套）进行的业务优化和细节设计，最终结果是形成——业务功能规格书（简称：业务4件套）。在系统中流动的所有业务数据的来源，都是在本章中编制业务功能规格书的“控件定义”时产生的，本章的内容也是整个系统设计中的重点，同时也是整个设计工程中工作量最大，与客户交互、确认最为频繁的地方。
2．作用
从对功能的设计过程看，这是对功能进行的第二次设计，也就是从业务视角的功能设计。本设计是以功能的概要设计成果——业务功能一览中所确定的业务功能为依据，参考需求阶段的功能需求规格书（需求4件套），逐一地对每个业务功能进行的业务优化、业务处理的细节设计，最终为每个业务功能编制出业务功能规格书（业务4件套）。经过了对功能设计后，功能在业务层面的细节就全部确定了。
功能的详细设计确定了功能的业务内容，在后续的设计开发中，原则上就不可以再更改业务的内容了，如果需要更改则必须要获得业务设计师的同意。
13.1.2 内容与能力
1．作业内容
功能的详细设计作业内容主要有三个部分：设计准备、规格说明和功能汇总。
对信息系统中“功能”的设计需要分为两个步骤，即：功能的业务设计和功能的应用设计。
1）设计准备
（1）实体概念：功能的设计是以实体为单位进行的，所以首先要进行对实体的定义和说明。
（2）标准模板：介绍记录用的标准功能规格说明模板，包括格式、内容、用途。
2）规格说明按照业务功能的分类（活动、字典、看板和表单），对每个功能进行详细的设计解说。
3）功能汇总将功能的详细设计结果进行汇总，形成两个重要的设计文档。
（1）业务功能一览：这个表替代了功能需求一览，给出了信息系统最终要实现的业务功能总数量。
（2）业务功能规格书：这个规格书替代了需求功能规格书（需求4件套），给出了每个业务功能的具体设计、开发的内容，是后续设计和开发的重要依据。
2．能力要求
相对于架构与规划设计的工作重点在对整体的设计而言，功能的详细设计是对业务功能的细节进行推敲和设计，重点在完成每个业务功能点的设计，参考能力如下（不限于此）。
（1）可以看懂业务架构图，掌握功能之间的逻辑关系。
（2）可以看懂需求分析资料，特别是功能需求规格书，它是详细设计的基础参考资料。
（3）熟练掌握功能的详细设计方法。
（4）具有一定的数据逻辑、数据库的知识。
（5）具有一定的原型界面设计知识。
13.1.3 思路与理解
对信息系统中“功能”的设计需要分为两个步骤，即：功能的业务设计和功能的应用设计。
（1）功能的业务设计：第一步设计的重点是从“业务”视角对“功能”进行设计，根据需求调研分析得到的资料，梳理清楚在“人-人”环境下用户的作业内容和作业方式，然后再利用信息化手法对原有的作业内容进行优化、完善，最终给出在未来的“人-机-人”环境下必须要完成的“业务作业”内容以及符合信息化处理方式的字段布局（此时不考虑完整界面的实现方法）。
（2）功能的应用设计：第二步设计的重点是从“应用”视角对“功能”进行设计，也就是将业务设计的功能内容转换成为用系统的构件进行表达，并给出在“人-机-人”环境下的业务处理方式，此时重点考虑的是在系统中如何处理业务，界面的构成和实现方法等，即应用的方法。
功能的详细设计内容就是对功能进行“业务”视角的设计，因为用户对系统的认知主要来自于界面，而界面设计的核心是业务内容，因此，功能界面上内容设计的优劣就直接体现了业务设计师对用户工作的理解，业务设计师要把这个界面当作与用户进行对话的“窗口”来进行设计，设计时要不断地问自己各个维度的问题。
1．站在用户①的视角
● 用户要在功能2上完成什么业务内容？
● 这个用户要对他的领导②提供什么信息？
● 本功能2与上游功能1、下游功能3之间的数据关系？
● 用户①与上游用户③和下游用户④之间的制约关系？
2．站在领导②的视角
● 功能2完成到什么标准才能够保证业务达成预定的目标？
● 对用户①的处理需要什么管理规则来做保证措施？
以上就是从“业务”的视角提出的设计内容，此时考虑的重点就是如何做好业务。当然，到了应用设计阶段，还可以再增加系统层面的内容，例如，将功能2与企业知识库相连接，提供与功能2相关的专业知识支持和检查等。
13.2 数据表与数据
已经清楚了功能需求与业务功能的关系以及它们是如何判断和转换的，在进入到具体的功能详细设计之前，还需要搞清楚几个基本的概念，包括：实体与数据表的关系，判断数据是否需要的方法以及相应的规则。
13.2.1 数据表
从需求调研开始就接触到了“实体”和“界面”的概念，在需求调研中讲到：一个实体指的是从用户那里收集到的一张表单，这张表单可以是一张发票、一份合同书、一张销售分析图表、一组数据的集合体或是一份需要上传的资料，调研时要寻找实体的形式和字段以作为后续功能设计的参考。
这里出现了实体、界面与数据表三个概念。实体的概念是系统外部的，界面和数据表的概念是系统内部的。
（1）实体：是企业实际使用的资料，可以是报表、单据，也可以是图形、影像资料。
（2）界面：是原型的主要部分，是数据表的载体，包括布局、字段等。
（3）数据表：是实体在界面上的映射，格式不同，数据的结构就不同，不同格式的数据需要采用不同结构的数据表。可以看出，作为系统外部的实体，“采购合同”是一张完整的“纸”，但是作系统内部的功能它是由“一个界面框、两个数据表”三个部分构成的。进入了功能的设计阶段后，由于实体形式就被业务原型所替代，实体上的数据与格式就被数据表所替代，所以功能设计完成后对业务设计师来说就不需要实体的概念了。
13.2.2 数据
1．数据的甄别
在前面已经判断了功能需求是否需要，需要的就转成了业务功能，这是完成了对“功能”粒度的判断。下面为了保证收集到的数据质量，还要对已经成为业务功能中的内容进行“数据”粒度的判断，这些数据在使用信息系统后是否还需要输入、输入后要遵守什么规则等，判断这些内容需要制定相应的标准，针对业务功能中的每一个数据都要进行甄别。
判断的步骤和标准如下。
①首先判断原有实体中的数据是否要放到未来的信息系统中，有些数据只是在“人-人”环境下的业务处理才需要，在“人-机-人”环境下就不需要了（去掉）。
②通过了①判断的数据在输入时是否可以为空，如果是关键数据（包括：计算、判断、引用等目的不可缺少数据），则不能为空（增加数据库不为空的检查）。
③通过了②判断的数据是否需要管理规则的管控（≠为空规则），如果需要，则在控件定义中加入管理规则。
④最后，为通过的数据增加保证其不出错的属性信息，包括：记录时间、部门、记录人等。以上是对已经确定为业务功能的实体数据进行的判断。
2．数据的质量
判断了数据是否需要后，还要对数据的质量提出要求，也就是要保证输入的数据是可用的，确保数据的可用性至少需要有以下三个方面的检查：完整性、及时性、正确性。表示数据质量的这三性需要融入到下面功能的详细设计中，通过定义和加入管理规则来保证。
1）完整性
数据的完整性，是信息系统数据的最低要求，也是最为容易实现的要求。判断完整性可以从使用的视角来推演，例如，监督生产过程的看板、最终分析结果的表单等，检查所需的数据是否可以完整地达到要求，没有遗漏、缺项。不完整的数据不能作为客户判断的依据。
2）及时性
数据的及时性，是信息系统保持数据“鲜度”的主要指标，通常及时性是与企业各个月度、季度或是年底的统计、申报等内容的时间相关的，例如，每个月的财务三表（经营盈亏），出勤统计表（工资计算）等。及时性可以利用时间限制（参考应用设计-时限）、管控等手段来保证数据在期限内完成数据的输入、维护和其他处理工作。如果不能及时统计到有时限要求的数据，形成的资料就失去了价值。
3）正确性
数据的正确性，是在数据输入的过程中，利用管控模型将输入数据、业务标准、管理规则整合在一起，通过模型的监控来确保输入的数据是正确的。例如，生产各类系统中发生的各类凭证数据，直接传递给财务系统使用，这是必须100%保证不出错误的。正确性是数据三性中最难做到的，要想做到正确性，系统必须是有管控手段的“管控类系统”，而不能是可以自由输入的“填报类系统”。数据的正确是关键，否则不正确的数据无论多么完整、多么及时都是无用的。
13.3 模板（业务功能规格书）
前面为进入功能的详细设计做好了铺垫工作（实体、数据表、数据），下面就进入到功能的详细设计环节。记录功能详细设计的资料称为业务功能规格书，由于该资料采用了4个模板作为记录载体，所以又简称为“业务4件套”（对比需求分析的记录称之为“需求4件套”）。业务功能4个分类（活动、字典、看板、表单）的描述方法都采用相同的模板。
13.3.1 模板的构成
1．设计思路
业务设计师是客户与技术设计师之间的桥梁，功能的详细设计资料业务功能规格书是仅次于业务架构图的主要业务设计成果，这个设计成果需要三方的确认。为了方便客户对功能设计资料的确认，业务设计师是用“业务设计用语”编制的业务功能规格书，“业务设计用语”可以做到不用特别的培训，客户就可以理解功能界面、控件定义等的设计含义（否则客户无法对设计结果进行确认和签字）。功能的详细设计是从业务视角对功能的最后设计，这个设计完成后原则上业务内容就确定了。如同需求分析阶段的需求功能规格书（需求4件套）一样，功能的详细设计也采用了4个不同的视角对功能进行描述，也称之为“业务4件套”。这个4件套包括：业务原型、控件定义、规则说明以及逻辑图形。不同之处在于将“需求原型”转换成为“业务原型”。
模板1——业务原型：给出界面业务内容的布局、字段的位置。
模板2——控件定义：用表格方式记录所有字段的名称、字段内容、相关规则等。
模板3——规则说明：用文章体的方式对各类复杂规则进行详细的说明。
模板4——逻辑图形：用图形方式表达了用文字难以说明的复杂逻辑关系。
2．记录方式
采用了这4种形式对一个功能进行描述，可以完整地、全方位地且唯一地表达这个功能的内容，这种方式非常适合于多人协作、传递、继承设计成果，可以有效地避免表达歧义，完全符合软件设计工程化的理念和方法，同时也为软件自动化辅助设计奠定了基础，4个模板具有以下特点。
1）结构化、标准化、易于记录
（1）不论什么业务功能，都采用这4个维度的描述，且每个模板要描述的内容、格式统一。
（2）记录的内容全是必读信息，为避免模糊、多义的描述，尽量不使用形容词、副词。
（3）在由多人接力进行需求、设计、开发的项目中，可以保证设计资料的可继承性。
2）有规律、格式化、易于沟通
（1）由于记录方式的规律性，经过简单的培训，所有相关人员都可以掌握或了解内容。
（2）由于格式化的记录方式，通过邮件、电话等方式进行讨论、修改非常方便。
3）可维护、可追溯、易于管理
（1）发生变更可以记录变更日、变更人、变更信息等。
（2）具有了前述优点，设计资料的文档管理就会比较容易。在功能设计中所采用的设计方法和记录方式，是符合面向对象的设计思想的，这为后续的应用设计、技术设计、开发实现以及验证测试等阶段的工作打下了基础，同时也为今后采用智能化的软件设计方法打下了基础。
13.3.2 模板1——业务原型
业务原型：是以实体为原型的依据，对业务处理用界面做的整体布局和字段控件（数据）布置。业务原型是业务设计阶段的原型表达方式。业务原型是业务设计阶段的原型表达方式。它是从需求原型到系统界面的中间过渡，这里只讨论实体中业务要素部分的设计，业务原型只需要将业务相关的内容说清楚，不涉及对系统的操作功能，如按钮、菜单等的描述，因此业务原型上不需要配置用于操作的按钮（如增加、删除、保存等），按钮的描述在应用设计中考虑。业务功能的原型在不同阶段有不同的名称与形式，在详细设计阶段完成的是“②业务原型”。之所以称为业务原型，就是因为这里只讨论“业务”方面的内容。
1．原型规划
业务功能规格书的第一个模板是业务原型。业务原型规划主要是在界面上对业务字段（数据）进行规划、布局，并在布局的范围内进行细节的设计，确定业务原型的具体工作环节有两个：数据格式的确定，字段的布置。
1）原型的数据格式
决定原型界面形式的重要依据之一就是数据结构，数据结构不同，容纳数据表的格式就不同，格式不同又会带来界面形式的变化。合同签订界面的主表区采用卡式、细表区采用列表式，合同签订的界面形式采用了“主细表”的形式（卡式+列表式）。
2）字段的布置原型的大局已定（格式），下面就是在界面上布置字段，从用户操作的视角出发，将功能所需要的字段按照业务处理的逻辑、规范、习惯等排布到最佳的位置。由于业务功能的设计不是最终的系统界面，所以此时的重点在于将业务字段全部布置出来，按照用户易于输入、观看的原则进行，在界面上划分几个区域，每个区域内安排一组内容相近的字段，保证使用者可以快速地读取信息。为了方便对界面上字段的描述和查询，通常将界面分成若干个区域，按照由上到下、从左到右的顺序布置区域的位置，并在界面中标出不同的区域名称。
（1）模板从上到下为：①工具栏→②主表区→③细表区。
（2）主表区的内部再进行划分，从左到右：位置1→位置5。
2．原型工具
因为业务原型中表达的是“业务要素”的布置，不是系统的界面设计，在这个阶段尚不要求与未来的系统界面高度相似，只要能够准确地表达出业务字段的布局就可以，因此绘制业务原型可以采用任何形式的绘图工具
（1）表格工具：表计算软件。
（2）专用工具：专业的原型设计软件。
选择什么绘图工具，与业务设计师掌握工具的熟练程度以及业务内容是否已经确定有关。如果业务设计师可以熟练地操作专业原型软件时，用什么方式都可以。如果业务设计师不熟悉专用工具或业务内容尚不确定时，设计内容还需要与相关人员进行反复地确认与修改，则此时采用表计算软件比较合适，所有的人都可以参与修改，工作效率较高。
3．界面形式的分类
1）界面形式界面表现形式有很多种，包括：卡式、列表式、主细表式、树表式。不同的数据结构需要采用不同的形式，采用哪种形式最佳由业务设计师参考业务内容，以及未来的应用方法（实际系统的界面）综合考虑决定。
2）界面形式的选择
收集到原始实体与业务原型的界面可以不是一一对应的关系，选取哪种形式合适取决于用户与业务设计师的沟通。
设计方式一：一个实体，一个界面，将主表和细表合为一体。
设计方式二：一个实体，两个界面，将主表与细表分开。
4．控件描述
在界面上需要绘制出控件，控件是构成界面的要素，类型有很多种，在业务设计阶段主要描述的有两个：字段控件、按钮控件，它们与业务设计的内容紧密相关
1）字段控件将每个单独的数据载体称为字段控件，字段控件由两个部分构成：标题栏和输入框。
（1）标题栏：表示该数据的名称，如合同金额、项目名称等，为了易于称呼和表达美观的原因，建议设计标题时采用较为简洁的称呼，标题字数控制在4～6个字左右最为好记。
（2）输入框：输入数据的部分，其形式有文本框、单选框等，输入的数据类型有数字、文字等。以下在描述时，将字段控件简称为字段。
2）按钮控件界面上用于操作的按钮称为按钮控件，常用的基础按钮控件（新增、修改、删除、查询、保存、提交等），但是有两种特殊情况需要在业务设计阶段就给出设计说明。
（1）特殊控件：例如，需要在界面上设置“上传资料”的功能时，由于它不是一个标配的基础功能，所以必须要在界面上配置“上传资料”按钮，同时给予该功能的设计说明。
（2）管理规则：例如需要在基础功能控件的“保存”按钮上链接“检查单价是否超标”的管理规则，“保存”按钮虽然是基础功能，但是链接在“保存”按钮上的管理规则却不是标配的，所以在业务设计时要画上“保存”按钮并对管理规则加以说明。
注：关于按钮控件
在此处只说明与业务处理相关的需求，例如：①要上传说明类型的资料及相关要求；②是否超标及超标的处理方法等。而不需要说明按钮控件的基本功能（如上传和保存的实现方法）。
13.3.3 模板2——控件定义
对界面上的所有字段进行说明和记录的是模板2——控件定义。下面从模板构成和控件定义的方法两个方面进行说明。
1．模板的构成
模板2是用来对业务原型上的控件进行定义、说明的，模板内的划分参考界面的排列顺序由上到下、从左到右。下面以“合同签订”原型为例，说明控件定义模板的构成。
2．控件定义说明（业务相关）
控件的类型有很多，这里选取一些有代表性的控件，特别是字段的类型，详细说明它们的描述和记录方法，这个方法仅供参考，重要的是一定要统一格式、标准，因为它们是软件设计中工作量最大，也是业务设计师与技术业务设计师／开发工程师之间讨论次数最多的资料。下面说明控件定义模板中主表区中不同类型字段的记录方法。
3．管控规则说明
在上述“控件定义（业务）”谈到的都是正确地输入和处理业务数据时的做法，但是如果发生了没有按照规则进行输入和处理时该如何应对呢？这就需要有管控规则了，因为一般对业务处理的管控都是通过字段控件和按钮控件来进行的，因此将管控规则连接在字段控件或是按钮控件上，当发生违规行为时就会激活管控规则，激活管控规则的条件写到各个控件的“定义与说明”栏中。管控规则通常分为两类：管理规则、系统规则。
13.3.4 模板3——规则说明
1．模板构成规则
模板的内容大体上可以分为三个部分，即整体概述、处理规则及其他说明。模板3的作用是提供一个可以用文章体的形式用大量的文字进行描述的场所，它可以描述用前面的业务原型、定义表格所不能说清楚的问题，主要的描述对象如下。
（1）整体概述：对功能进行整体目的、作用、功能等的说明。
（2）处理规则：说明的内容要同时涉及多个字段之间的复杂处理关系。
（3）其他说明：其他一些预想，或是需要大篇幅说明的问题。
2．规则描述
下面对规则的内容举例说明。
1）整体概述
（1）背景说明：说明该功能的目的、作用、与其他业务功能之间的关系等。
（2）新建规则：在记录一条新的数据时，该功能需要满足哪些初始条件，例如，引用的上游数据要满足什么条件、数据输入和处理时要遵守哪些管理规则等。
（3）完成规则：在准备提交前，该功能必须要满足什么检验条件，例如，业务标准、管理规则等（具体的检查实现方式在后面“功能的应用设计”中有详细的说明）。
2）处理规则
有些处理规则会同时涉及多个字段的内容，当描述的内容比较复杂时，这个处理说明放在哪个相关的字段内都不合适，此时就将这个处理规则的说明放到这里来。
13.3.5 模板4——逻辑图形
1．模板构成
逻辑图形可以表达前3个模板（用原型、文字）说不清楚的复杂问题，特别是对模板3规则说明的补充。如果功能的内容比较简单时，模板4是可以省略的。
2．描述内容
用什么样的逻辑图表达没有一定之规，主要是根据要说明的内容
（1）操作步骤图
操作步骤图当功能内部的业务处理复杂、业务处理的开始、结束都有很多的规则，且不但有内部的字段关联而且还有与外部的其他功能、数据来源有关系时，就可以采用类似的图形形式，表达原型中的操作过程，或是功能内、外部之间的关联关系。注：步骤与流程的区别步骤与流程不同，一个实体内部的操作过程称为步骤，它不是“业务流程”，所以它的定义、标准也不需要按照流程图的方式绘制。
（2）数据I/O图。
如果该功能内部的数据与外部数据源有比较复杂的关系，仅依靠控件定义中的“数据源”项的说明不够且不形象时，为了向后续的技术业务设计师或是编程工程师说明情况，可以采用“数据I/O图”来表示不同功能之间的数据关系。这个图形可以检验模板2控件定义内容是否正确，同时它也特别适用于对业务设计师进行数据方面的能力培养。
（3）数据关联图。
如果某个字段的处理是由多个内部字段或是内外部功能中的字段共同完成的，要想说明它们的背景、复杂的算式关系仅使用该功能内部的字段是不够的，因此可以采用“数据关联图”来表示
功能的详细设计，不但提供了数据，还提供了逻辑
架构图在整个分析与设计过程中起到了两个关键的作用。
第一次：对客户业务现状的理解和梳理客户提供的原始需求是繁杂的、不清晰的，第一次是利用了现状构成图（架构模型）才知道了客户业务的原始状态，理解了客户功能需求的背景。
第二次：优化业务、精确业务逻辑关系第二次是利用了业务架构图将业务功能之间的逻辑关系进行了精确定位，明确了所有业务功能之间的关系，特别是流程上节点间的前后顺序，从而间接地奠定了数据表和数据间的关系。如果不做业务架构图，就不清楚业务逻辑，不清楚业务逻辑就不能确定流程上每个节点的上下游关系，以及每个节点的数据输入输出关系，没有这个数据的输入输出关系，就给不出字段的定义（控件定义表），最终，技术开发人员就没有依据做数据关系的设计图了。
开发人员之所以能够直接利用业务4件套（包括业务原型和控件定义）做开发，是因为业务人员两次利用业务架构图将原始的、杂乱的需求梳理出业务逻辑，业务逻辑又帮助确定了功能之间的关系，从而确定了数据间的关系，所以开发人员才能收到一份干净、整齐、清晰的字段定义。可以说，开发人员是间接地利用了业务架构图做的数据关系设计。
13.4 功能设计1——活动
13.4.1 活动的概念
1．定义
活动，对应着现实中一个独立的数据处理工作。活动设计是将现实的工作转换为系统处理的业务功能。活动的数量是4类业务功能中最多的。
“处理”的含义为：数据的输入、资料上传等操作。
1）活动的来源
信息系统中的哪些功能可以归入到活动功能的范围内呢？除去用于输入和维护基础数据的功能称为“字典”以外，其他凡用于输入过程数据的功能都归集到“活动”功能中。
2）活动的粒度对一个活动包含多少数据处理内容的划分原则如下。
（1）可以完成一个独立的业务目标。
（2）其大小有利于用户的分工安排。
（3）符合系统的处理效率上的要求等。
一个活动的内容多少是由客户的工作习惯与系统处理效率之间的平衡关系决定的，最终的决定需要业务设计师与用户进行商量决定。
2．功能活动具有的处理功能主要由两个部分构成：业务处理功能和管理处理功能。
（1）业务处理：指对业务数据进行输入、计算、查看、展示等的功能。
（2）管理处理：指对业务处理过程中加载的管理规则，这些规则可以保证数据合乎标准。
3．作用
（1）活动具有的基本处理功能包括：输入、查看等。
（2）一个活动对应现实中的一个具体工作，因此对活动的设计是两大业务优化设计之一（另一个是业务流程的优化），它可以带来工作效率的提升。活动也是管理的主要载体，用户与业务设计师的想法大多数都要落实在活动的界面上，特别是对管理处理而言。
13.4.2 活动的设计
虽然在需求调研、分析阶段已经有了需求原型，但是如前所述，那时的重点是“收集需求”而不是“业务设计”，所以在功能详细设计时还要对功能进行一次完整的分析和设计。对活动进行设计时，除去按照前述业务功能规格书的4个模板依次进行记录以外，还需要从下面4个视角进行思考和分析：设计理念、业务内容、业务标准、管理规则。
1．设计理念
要将一个普通的活动功能设计成为一个具有较高客户价值的业务功能，首先要将活动看成一个具有明确目标的“任务”，而不仅是一个数据的处理功能，无论是处理一个复杂的“合同签订”业务，还是处理一个简单的“领料单”业务，业务设计师都要保证这个业务处理可以正确、完美地达成目标，否则，如果仅从功能视角出发去做设计，那么关注点放在字段上就够了。仅关注字段的设计做法有可能造成对业务功能的设计结果只有系统的操作者关心，而操作者的上级领导不关心，因为这个功能仅做到了用计算机替代手工操作，没有保证完成的工作符合业务标准、管理规则。因此，设计每一个活动时，除去字段的设计外，还要思考如下问题（不限于此）。
● 什么时候该活动可以开始运行？如何判断该活动被正确地处理完成？
● 在处理过程中，每一个步骤都需要遵守哪些业务标准或管理规则？
● 如果违反了标准或是规则时如何判断、应对？等等。
2．业务内容
确定这个活动的业务目标、范围、字段、规则等。
（1）目标：确定这个活动要完成的工作，如签订一份采购合同。
（2）范围：涉及的业务范围，如合同编制、合同变更。
（3）字段：需要哪些字段来描述这个活动，有本活动产生的，还有上游活动参照的。
（4）规则：处理需要遵守哪些规则（业务规则、管理规则）。
3．业务标准
要研究业务内容中每个字段的数值许可范围，这个范围就是“业务标准”。
4．管理规则
管理规则就是用来保障业务标准被正确地执行,管理规则是针对业务标准建立的，管理是为业务可以按照标准运行提供的保障措施。
13.5 功能设计2——字典
13.5.1 字典的概念
1．定义
字典，是对企业基础数据进行标准化管理的运维功能。基础数据的来源是企业要保护的标准数据，如材料编码、客户信息、员工信息等。字典可以看成是一个特殊的“活动”，只用来维护特殊的数据，即基础数据。
2．功能
字典具有两个基本的管理功能：数据输入、数据维护。其中：
（1）数据输入：用于对基础数据的输入和保存。
（2）数据维护：对基础数据的维护包括：追加、变更、发布等。
3．作用
通过设计字典功能，可以建立一套支持数据标准、数据输入、数据维护等的工作体系。谈到“字典”，首先要理解它是一个用来规范企业基础数据的功能，字典在这里是“功能”的概念（不是数据库概念）。它的主要作用有三个：建立基础数据、维护基础数据、支持快速输入。
（1）建立数据标准：在整理基础数据时，建立基础数据的标准，包括结构、分类、编号。
（2）维护基础数据：用来维护和管理基础数据，包括追加、变更、发布等。
（3）支持快速输入：利用字典协助活动的数据输入工作，不但快捷，而且可以避免输入错误；这也起着一种变相的对基础数据的管理作用。字典功能设计是从事业务设计的业务设计师非常重要的工作之一，而且要求业务设计师对企业需要进行标准化的基础数据有一定的理解和研究。
4．字典功能的特殊性
由于字典与其余的三个业务功能有着密切的关联，同时又容易产生一些概念上的模糊，下面就将这4个功能之间做一些对比。
1）字典与数据库的区别
（1）字典：是一个业务处理的“功能”，用来建立结构化的基础数据。
● 将数据资源进行标准化、结构化的梳理。
● 限制基础数据的使用范围。
● 帮助快速地输入过程数据，等等。
（2）数据库：是一个存储电子文件的场所。利用字典功能梳理过的数据被保存到了该字典对应数据库，利用字典的功能可以对该数据库的数据进行查询、调用、维护以及发布等。注：关于字典库的称呼字典库是字典功能和数据库功能的合体，通常习惯于将记录企业基础数据的数据库称为“字典库”，这个词的含义有以下两个。
含义1：它是一个特殊的数据库，专门用来记录企业基础数据。
含义2：它是由字典功能进行管理的数据库（可以增减、发布、查询等）。
2）字典与活动的区别
（1）活动功能的作用：是随着生产过程，按照数据的发生顺序记录过程数据。
（2）字典功能的作用：是对字典数据库中的相同数据进行长期的、反复的维护。
两者的最大区别就在于：活动产生的数据不许维护（违法），字典产生的数据必须维护。
3）字典与看板、表单的区别字典提供的基础数据是设计各类表单、用看板抽提数据、分析统计的主要条件、属性，例如，组织、产品、材料、客商、知识等。
● 用组织字典：可以按照组织口径统计、分析不同部门、个人的产值、收入等情况。
● 用材料字典：可以按照材料类型统计、分析不同材料的数量。
4）字典的设计特殊性
字典的设计就相当于对一个业务模块或是系统的设计，它需要能够独立地进行维护。
（1）字典的实体多，字典本身可能需要若干个小的字典来支持。
（2）重要基础数据对应的字典需要复杂的编号设计，包括资源的分类、分类的层级等。
（3）字典的管理需要具有一套专门的企业管理规则，如标准的制定、监控措施等。小结字典功能，是企业数据管理标准化的重要手段之一。建立企业标准化对象有很多，其中最为重要的有两个，即“业务流程的标准化”与“基础数据的标准化”。
小结
（1）业务流程的优化是通过业务架构实现的。
（2）基础数据的标准化是通过字典功能实现的。
13.5.2 字典的设计
设计好字典功能，可以从以下4个方面进行思考：设计理念、数据选择、数据标准、数据维护。
1．设计理念
基础数据包括企业中所有需要统一、保护的公用数据，基础数据也是未来系统中构成主数据的核心，基础数据是所有数据类型中生命周期最长的，因此字典设计不但要考虑维护的方便性和输入的快捷性，而且还要思考如何能让基础数据适合维护方便和输入快捷。
2．数据选择
选择数据就要判断企业数据中哪些是属于基础数据的，判断的参考条件如下（不限于此）。
（1）需要保护的核心数据，如组织机构、客商信息、市场价格、材料编码等。
（2）企业知识库数据，全员要遵守，如工艺功法、法律法规、质量标准等。
（3）其他，如反复使用的数据、支持快速输入的数据，以及分析统计的属性数据等。
3．数据标准
确定了字典的对象数据后，下一步要确定研究对象数据标准，标准包括数据的分类、数据的结构、数据的编号等.
4．数据维护
基础数据不同于过程数据，需要经常维护以做到与时俱进，基本功能如下（不限于此）。
1）数据的输入
确定记录数据采用的业务原型。
2）数据的调整（维护）
与活动功能在记录数据后就不能再改动的原则不同，在基础数据的生命周期内需要利用字典功能对其进行多次的调整，为了让引用不同时期基础数据的表单都可以如实地再现，字典不但要具有调整功能，而且必须保留完整的基础数据变更履历，再现时不能让调整后的基础数据影响历史表单的还原。
3）数据的发布
很多基础数据在不同时间段有不同的数值，所以字典功能还要具有数据发布的功能字典界面打开时看到的是最新的单价数据。另外，既然是企业需要保护的基础数据，还必须有相应的管理规则、权限等。
13.6 功能设计3——看板
13.6.1 看板的概念
1．定义
看板，是以窗体为载体进行数据展示的功能。通过设计看板功能，可以静态或动态地展示统计分析数据、监控过程数据是否超标以及导引各类信息等。
2．功能
看板的功能主要分为两大类：展示和查询。
（1）展示：采用不同的形式展示数据、信息，展示形式包括：列表、曲线、图形等。
（2）查询：采用不同的方法进行查询，如条件查询、模糊查询、数据发掘等。
3．作用
利用看板功能可以对生产过程的数据进行展示、监控，以及过程的导引等。
（1）展示看板：根据不同的查询内容、企业中不同的角色建立不同的信息展示板。例如，生产部门、采购部门的进度展示板，董事长、材料管理员的专用展示板等。
（2）监控看板：将生产过程产生的各类数据与企业制定的相应指标进行对比，达到对生产的监控、提示，以及发出预警等，将问题消除在过程管理中。
（3）导引看板：作为智能化系统设计的手法，可以利用看板将所有的生产过程串联起来，在看板上显示实时的通知、待办事项、导航菜单等。
4．看板功能的特殊性
通过对比看板与活动、看板与表单的异同，可以加深对看板功能的理解。
1）看板与活动的区别
（1）形式：都采用了窗体的形式。
（2）作用：活动主要是用于记录过程数据、承载管理规则等，看板不能记录过程数据，主要用于展示数据（包括过程数据、加工数据）。
2）看板与表单的区别
（1）形式：看板采用窗体形式，表单采用表格、单据的形式。
（2）作用：看板可以使用包括数据钻取在内的丰富查询和表达方式，但不能打印；表单只支持固化内容的表达形式、支持打印或将数据整体地导出到其他载体上。
13.6.2 看板的设计
设计好看板功能需要从以下4个方面进行思考：设计理念、展示对象、展示目的、展示内容。看板的作用是展示数据，判断是否使用看板功能的方法很简单，除去记录数据的工作（活动、字典），以及打印数据的工作以外，都是属于看板范畴的对象。
1．设计理念
所谓的“门户”就是信息系统的入口，因为用途不同、布局不同，所以显示的内容和位置也会有所不同，但是设计原则应该是，让每一个用户在打开信息系统的门户时，做到：
（1）最快地让用户寻找到“主动想找的信息和功能”。
（2）最快地让用户接收到“由信息系统推送而来的信息”。门户是信息系统的“脸面”，它不但是一日工作的开始点，而且也是一日工作的结束点，所以业务设计师要能够做到让每个用户早上打开系统的门户时要知道：今天要做什么工作；晚上结束关闭门户前要知道：今天完成了什么工作、还有哪些工作未完成等。
2．展示对象
这里“展示对象”指的是观看数据的用户，每个用户打开系统后的第一界面就是门户，因此门户是放置每个用户每日必看信息的地方，也是布置看板的最佳位置。因为不同用户的角色不同，他所关注的信息内容不同，许可查看的范围也不同，所以首先要确定数据展示的对象是谁。例如:公司级的领导可以看到全公司的数据，部门领导可以看到本部门的数据，个人只能看到本人的数据等。
3．展示的目的
确定了观看数据的对象后，那么第二个要研究的就是通过展示的内容要达到什么目的，也就是要向观看者传递什么信息，因为系统中的数据非常多，不可能都在这个门户上一次都显示出来，因此需要针对这个角色设计他所需要展示的信息，内容有两个维度：自主关心、被动关心。
4．展示的内容
确定了对象、目的后，就可以围绕着对象和目的确定展示内容，内容包括：数据信息、展示形式等。
13.7 功能设计4——表单
13.7.1 表单的概念
1．定义
表单，是以纸质形式为载体（包括电子版）的数据展示功能。表单的代表形式有报表和单据两种。通过设计表单功能，可以将常用的凭证类数据、分析类数据用固化的格式展示与打印。
2．功能
表单主要是用来展示某类固化形式的数据，其功能包括：抽提数据、加工数据、形成表单，以及打印或是导出电子版的数据。
3．作用
此类功能通常用于要用纸保存、提交、盖章的场合，主要有两类表达形式：报表、单据。
（1）报表形式：针对某个目标将某个时间段内符合条件的数据进行抽提、加工，形成分析报表，如成本分析、销售排名一览、财务月报等。
（2）单据式样：展示单条数据，表现形式大多为卡式、列表。常见的使用场景有：合同书、领料单、工资条、发票、收据等。
13.7.2 表单的设计
设计表单和设计看板的内容是一样的，但是由于是固化形式，同时它的格式要求也大都来自于用户，所以不需要考虑设计理念，相对来说比较简单（这个简单指的是设计表达层面，不是技术实现层面）。它需要从三个方面确定，即展示对象、展示目的、展示内容。
注：“模板”与“模型”的区别
模板多为表格，模型多为图形，两者的目的和用途是完全相反的。
● 模板：用于“约束”，使用者要按模板要求（格式、标准）做，目的是为了统一交付物。
● 模型：用于“启发”，使用者可参考模型按具体条件做，目的是为了传递事物的规律。
小结
以功能的概要设计成果——业务功能一览为依据，并参考需求工程获得的功能需求规格书等资料，完整地给出了功能的业务设计细节。对功能的详细设计包括三个内容。
1．业务功能的数据来源
（1）数据表：设计业务功能，就必须知道界面上的数据表的概念，因为数据表是界面布局的依据，同时也是数据的载体。
（2）数据：有了数据表，还需要知道如何甄别数据表上的数据，判断这些数据的内容，表示数据需要哪些属性、管理规则等，这些都是保证数据质量的必要措施。
2．业务功能的记录模板
信息系统处理业务数据的主要工具是“界面”，而界面上的核心部分就是本章介绍的设计内容，对功能的详细设计分类和模板类型可以归集为两个“4”。
（1）第一个“4”：将全部的业务处理功能按照处理数据类型的不同，分为4大类，即：活动功能、字典功能、看板功能和表单功能。
（2）第二个“4”：每个业务功能的设计结果都需要4个不同形式的模板做记录，即：模板1=业务原型，模板2=控件定义，模板3=规则说明，模板4=逻辑图形。
3．业务功能的设计步骤
有了数据和记录模板，完成每一类业务功能的设计还需要4个步骤，分别如下。
（1）活动设计的4个步骤：设计理念、业务内容、业务标准、管理规则。
（2）字典设计的4个步骤：设计理念、数据选择、数据标准、数据维护。
（3）看板设计的4个步骤：设计理念、展示对象、展示目的、展示内容。
（4）表单设计的4个步骤：设计理念*、展示对象、展示目的、展示内容。
关于“表单功能”的设计理念
因为在很多情况下表单功能的设计内容和格式是由用户而不是由业务设计师决定的，所以针对表单功能的设计理念不是必需的。掌握了这个部分的知识后，业务设计师就可以设计信息系统界面的业务部分内容，这个设计为后续将业务功能转换为系统的“组件”奠定了基础，后续的应用设计是为这些业务功能“穿上系统的外衣”（没有系统的“外衣”，界面就无法操作）。功能的详细设计内容，是作为一名业务设计师的最基础知识和能力。
4件套的格式，是典型的工程化设计的样本