第3篇 设计工程——概要设计
第8章 设计工程概述
设计工程，是基于需求工程的成果进行信息系统设计的部分。业务设计是设计工程中以客户业务为中心的设计部分，业务设计的成果决定了客户信息化的业务价值，是后续所有设计与开发的基础和指南，也是业务设计师需要掌握的核心知识和能力。涉及软件工程框架图中两个部分的概述：设计工程及业务设计部分。
（1）设计工程的整体：包括业务设计部分、应用设计部分、技术设计部分。
（2）业务设计的部分：包括概要设计、详细设计。
8.1 基本概念
8.1.1 定义与作用
1．定义
设计工程，是运用软件设计的理论、方法、工具，对需求工程获取的需求按照不同的理论和方法进行分阶段、分层地细化，给出满足客户需求和符合软件开发要求的设计资料。
①业务设计部分：含概要设计和详细设计两个阶段。业务设计的重点是对业务优化、业务功能以及业务价值的设计。成果包括设计规范、业务架构、业务功能等。
②应用设计部分：将业务设计的成果转向系统的架构、组件以及应用价值的设计。成果包括应用架构、系统机制、系统功能等，②是①和③的桥梁。
③技术设计部分：将业务和应用的设计成果转换为支持编码开发的设计资料。成果包括语言选择、基础框架、数据接口、系统部署、硬件选择、环境构建等。由于业务设计的概念使用不广泛，定义也比较模糊，有的软件企业有“需求设计”的环节。这里对业务设计与需求设计的内容做个比较，以帮助理解业务设计的概念。
1）需求与业务的区别
（1）需求：指的是客户针对引入“信息系统”所提出来的需要和要求。
（2）业务：指的是客户企业所“从事的工作”（经营、管理、生产、销售等）。
2）需求设计与业务设计的区别
（1）需求设计：直接设计的是系统需要的“功能”，包括功能的构成及实现方法。需求设计的主要对象是“功能的需求”。
（2）业务设计：业务设计分为三个层面（架构、功能和数据）。首先是对客户的业务“流程”进行梳理、优化、完善（架构层），再对业务的“操作”（功能层）进行设计，最后对业务的操作“结果”（数据层）进行设计。业务设计的过程是“架构→功能→数据”。
两者的设计理念是不同的：“需求设计”直接关注的就是“功能需求”；而“业务设计”首先是对“业务”进行梳理、优化。获得了功能需求，但不熟悉业务背景，就是“知其然，不知其所以然”。在充分地理解了业务、优化了业务并确定了未来信息化环境下业务的处理方式的基础上，再去确定功能需求，那么才是做到了“知其然，也知其所以然”。
业务设计，是将“需求”放在“业务”这个背景中去思考、设计的。明确功能是为业务提供信息化支持服务的。也就是说，功能需求的真伪、包含的内容、处理的形式等都是通过对客户业务处理过程的充分理解后才能确定的。
基于不同的设计理念产生的系统会给客户带来不同的功能、感受、价值以及满意度。
2．作用
在设计工程中，需求工程的成果被设计师进行了进一步的理解、阐释，并融入了设计师的理念、思想，开发完成的产品必须要符合设计师和设计资料的要求（这里设计师提出的设计资料已经不是需求，而是要求），它是所有相关人交流、工作、检查的共同语言和标准。
在设计工程中，业务设计部分的主要工作是优化、梳理、完善业务，并在此基础上确定业务功能；应用设计的目的是将业务设计成果转换为系统的功能；技术设计部分的目的是实现业务设计和应用设计的成果。业务设计和应用设计的结果决定了产品的最高价值。应用设计，是业务设计部分和技术设计部分的融合之处。
8.1.2 内容与能力
设计工程篇的作业内容是按照两个维度进行的，即：工程分解维度（X轴），共分为三个阶段（概要、详细、应用）；工作分解维度（Y轴），共分为三个层（架构、功能、数据）
根据分离原理，构成企业的内容可以分为4个部分，即：业务、管理、组织和物品。其中，业务设计和管理设计分为两个层面分别进行设计，然后再进行叠加，因为业务设计成果是管理设计的“载体”，因此先做业务设计并将“工程分解／工作分解”作为第一层，将管理设计作为第二层，两者内容划分如下。
注：关于价值设计的构成
通常情况下，应用类软件绝大部分的客户价值是由业务设计阶段-业务价值、应用设计-应用价值两部分形成，因为这些价值是客户购买软件产品的直接目的
另外，因为管理是保障业务价值和应用价值的实现而存在的，因此不存在管理设计价值。
8.1.3 思路与理解
在进行设计工程的说明前，还需要再回顾一下分离原理和组合原理，因为这两个原理是建立设计工程体系以及相关设计模型的基础。
1．分离原理的应用
在设计工程的每个阶段中都采用了先将业务与管理进行分别架构、规划、设计，然后再组合在一起协同工作的方式。采用这样的设计方式可以让设计师感受到：企业管理的设计首先要理清楚业务载体的情况以及业务处理的标准，然后再去匹配相应的管理方法，管理是为了业务达到标准而做的保障措施。
1）业务设计
业务设计关注的是按照业务处理所必须遵循的目标、工艺、标准等要求，并设计出满足这些要求的信息处理系统，在这个设计过程中，暂不关注如何管理业务的处理过程，只集中精力研究业务运行的事理。
2）管理设计
有了业务处理形式和对应的标准之后再来确定管理方法，以业务为载体确定管控的位置并加入管理规则，确保业务处理不出现违反业务标准的问题。
2．组合原理／基干原理的应用
设计工程在不同的阶段、分层中都有不同表达形式的逻辑图形，组合原理的三元素对应的内容会沿着软件工程的推进方向不断地发生变化。
1）要素的变化沿着软件工程的三个阶段推进，要素在三个层面上的称呼变化如下（由粗到细）。
（1）需求工程各阶段：原始需求（客户语言）→业务分类（业务、管理、组织、物品）。
（2）设计工程-架构层：用框架图表达，有系统、子系统、模块、功能等。
（3）设计工程-功能层：用原型图表达，有业务领域、业务功能、业务组件、控件。
（4）设计工程-数据层：用数据架构图表达，有全系统、领域、数据表、数据。
2）逻辑的变化
在①需求工程阶段，收集到的客户需求大多都是采用文字以及表单的形式表达的专业知识、业务经验以及现实的做法，此时的说明和表达并不特别强调逻辑的概念。
在②设计阶段中，贯穿全过程的主线就是业务逻辑，业务设计部分的工作本质上是在做理解、解释、转换，也就是将需求中所包含的专业知识、业务经验、目标期望、痛点难点等内容，通过分析、设计的一系列转换工作，最终为以“逻辑图形”为主的表达方式所替代，这种逻辑表达方式最为符合软件设计和开发的习惯。在②的区间内，用知识和经验表达的内容越来越少，最终绝大部分都由逻辑的表达方式替代了业务知识和经验的表达方式。
在进入到③应用设计区间后，逻辑表达再被转换为机制表达，机制是逻辑的实现方式，将逻辑转换为机制也是信息系统具有复用性、应变性的基础。可以看出，在②的区间内，代表知识和经验的内容渐渐地减少，而代表逻辑的内容渐渐增大，以至于在接近应用设计区域的时候几乎完全替代了知识和经验的内容。
这个示意图说明了：②业务设计的作用是将客户的业务知识、经验转换为用业务逻辑表达，进入到④技术设计阶段后，原则上技术设计师的工作不能依据源于①的业务知识、经验表达的原始需求，而必须依据通过②和③获得的设计资料（需求阶段的资料可以作为参考，不能作为依据）。在④技术设计区间内，技术设计师再将前阶段的逻辑和机制的表达方式转换为开发工程师易于理解的形式。从上述的说明中可以得出如下两个重要的关注点。
注1：按照软件工程的要求，开发工程师不能直接应用需求调研成果。
为什么说开发工程师直接按照需求工程的成果进行开发是有缺陷的？因为这样做缺失了设计工程中对业务逻辑的抽提、优化，以及向机制转换的过程，其结果很可能造成交付的系统逻辑不清，达不到为客户带来信息化的预期价值，同时没有进行规律性的抽提也难让系统做到复用和应变。理解这个知识→逻辑→机制的转变意义和过程非常重要。
注2：业务逻辑与业务知识的作用区别
业务逻辑的主要表达方式存在于业务架构图中，业务逻辑对设计和开发的重要性是毋庸置疑的，那么掌握了业务逻辑的表达方法是否就具有了业务优化的能力了呢？回答是否定的！业务逻辑可以使得优化结果的表现得非常清晰、直观，但业务优化的依据是“业务知识、业务经验、管理理论”等内容，因此，没有相应的业务知识和经验的设计师是难以正确地进行业务优化的（尽管他可以清晰地表达优化的结果）。
业务逻辑：打开架构意图的钥匙
在业务架构图中，“逻辑”是对所有的知识、经验、想法等内容的替代，业务架构图中的“逻辑”表达的不是思考的过程，而是思考的结果。架构图中的“逻辑”会被一直引用（功能设计、数据设计、应用设计）直至到编码开发的阶段。将需求中的业务知识转换为用逻辑表达之后逻辑不再被更改，这就使得从设计到开发直到测试验证有了一条“逻辑主线”，所有的工序都与这个主线对标，极大地提升了设计和开发的质量，减少了失误和失真。
3）模型的变化
进入了设计阶段，分析模型基本上就不再使用了（因为分析模型的逻辑只适用于做分析），设计阶段基本上都是采用架构模型（架构层）、原型界面（功能层）和数据模型（数据层）等进行设计结果的表达。
8.2 工程分解
软件工程的“工程分解”分为三个阶段，即概要设计、详细设计、应用设计。其中，概要设计和详细设计又构成了“业务设计”部分。
8.2.1 工程分解1——概要设计
概要设计是设计工程的第一个阶段，设计的依据是需求工程的成果——现状构成图、功能需求一览、需求规格说明书等。概要设计主要负责对系统进行以下四大方面的规划。
（1）规范：从顶层设计的视点出发，确定目标、理念、主线、原则、定义、标准等。
（2）架构：基于目标对业务进行优化，确定业务架构、系统、子系统、模块等的划分。
（3）功能：基于架构对业务功能进行分类、规划，确定功能间的关系以及功能一览。
（4）数据：基于架构和功能对数据的范围、内容进行规划，确定主数据、数据标准等。
概要设计阶段，设计师关注的应该是大的系统间规划、顶层的设计，不过多地纠结于细节或系统内部小模块之间的关系，或是某个具体的功能。概要设计一般不是一次就能做到位，而是需要反复地进行调整的。在概要设计阶段，应最大限度地提取可以复用的模块，建立合理的结构体系，节省后续各设计阶段的工作量。
8.2.2 工程分解2——详细设计
详细设计是设计工程的第二个阶段，依据概要设计文档对架构、功能和数据层面的内容进行精细设计。由于有了概要设计文档做总控，所以在详细设计阶段就可以展开由多人协同并行设计。在详细设计阶段，每个设计师面对的都是一个独立的系统／模块，根据概要设计约定好的局部任务和对外接口，设计并表达出定义、关系、算法等内容。这里要注意，如果发现有结构调整的必要，必须返回到概要设计阶段，将调整反映到概要设计文档中，而不能只解决详细设计问题而不再维护概要设计的资料了。详细设计完成后，形成详细设计规格书。详细设计工作全部完成后，对系统中的业务部分的设计就完成了，后续设计中就不能对业务部分的内容再进行任意修改了，如果需要变更，务必要取得业务设计师的确认。
8.2.3 工程分解3——应用设计
应用设计是设计工程的第三个阶段，主要内容是将概要设计规格书和详细设计规格书的设计成果与系统实现的手法结合在一起，给出系统实现后的业务处理、管理控制的操作效果，以及非业务的功能设计部分。应用设计可以看成是“业务设计部分”与“技术设计部分”的结合部，它给出了软件开发完成后的应用效果（包括：布局、操作、规则等），企业管理信息化的价值最终体现在这个部分的设计成果中。
应用设计应该是包括业务、技术、UI、美工以及体验等诸方面知识和技术的集合体。这个部分的设计需要应用设计师具有跨界的知识和能力，包括一定的客户的专业知识、业务设计知识、技术开发知识、UI设计和美工设计知识以及系统上线的经验等。
8.2.4 工程分解4——三个阶段的关系
1．三个阶段的差异
1）三个阶段的重点
相对于需求分析是站在客户业务的角度理解需求而言：
（1）概要设计的重点：从设计的角度出发对需求的定义和解释，经过一系列粗粒度的规划和设计，让后续的设计师大致了解系统的结构和操作模式。
（2）详细设计的重点：描述业务设计的实现细节、方法、函数等。
（3）应用设计的重点：将前面设计的内容转换为系统的表达方式。
2）三个阶段的协同
各个模块之间是有层次关系的，也有先后的逻辑关系。在概要设计中，还必须考虑模块的实现细节，概要设计、详细设计和应用设计三个设计之间需要反复迭代进行。在概要设计阶段，设计师就要能够规划和确定出详细设计和应用设计的范围、深度，所以对概要设计担当人的能力要求是软件工程全过程中最高的。
3）三个阶段带来的不同价值
这三个阶段完成了系统的绝大部分价值，它们的设计让用户感受到了业务的变化、工作环境的变化，感受到了信息化带来的价值。
（1）概要设计／详细设计，确定系统中业务方面的最高价值。
（2）应用设计，确定系统中应用方面的最高价值（也可以称为体验价值）。
2．三个阶段的用语
在需求工程阶段收集客户需求时，采用的是客户使用的“客户用语”，因为只有用客户最为熟悉的语言才容易交流、沟通、表达，这个时候的用语是描述客户行业知识、实践经验、客户现状的。
1）概要设计阶段／详细设计阶段
由于业务设计阶段的重点是针对业务的设计，所以使用的表达语言是“业务设计用语”，它们不是技术设计和开发时使用的技术用语，业务设计用语如业务架构、业务流程图、工作分解图、业务功能分类、管控模型、管理规则等。
● 此时的重点是对业务的优化、完善，是找出业务价值，而不是技术的实现方法，因此过度使用技术用语会影响到干系人对业务的理解、表达。
● 在业务设计阶段使用技术用语表达也会影响业务设计的正确性。
2）应用设计阶段
应用设计，是介于业务设计与技术设计之间的转换期，它使用的既不是完全的业务用语，也不是完全的技术用语，而是介于业务和技术之间的用语，有偏业务的用语，例如，事找人的流程机制、红字更正（删除）、提交检查、时限管理、权限管理等；也有偏技术的用语，例如，组件、窗体、界面、权限等。进入技术设计阶段以后，就完全是技术的表达方式了（如UML、编码语言等）。在技术设计阶段如果可以做到少用或基本不用客户的专业语言，那就说明前面的每个设计环节都做得非常到位，没有遗漏，反之，到了技术设计阶段还要大量地使用需求阶段客户的专业用语，那就说明前面各个阶段的转换做得不到位。
8.2.5 业务设计与技术设计的关系
在软件工程的框架上，业务设计（概要、详细）与技术设计中间隔着应用设计，两者没有发生直接交付与继承的关系。两者之间有如下的特征（仅供参考）。
● 业务设计是以业务知识和设计知识为基础进行设计、表达的方法。
● 技术设计是以计算机技术为基础，用技术设计特有的方法来转换应用设计的成果。
● 业务设计可以“不知”技术设计或技术开发的方法，它只关注业务自身的内容。
● 技术设计必须要满足业务设计的要求，也就是说，技术设计依赖于业务设计成果。
● 业务人员（咨询、需求、业务设计师）是否懂技术不是工作的前提条件（但多懂为佳）。
● 技术人员（技术设计、开发、测试）必须要能够理解业务设计资料，是否懂业务知识不是工作的前提条件（但多懂为佳）。
由于各个软件企业的组织构成、涉及来源不同，所以业务设计与技术设计的划分也不尽相同，这里“应用设计”的环节设置与否有着非常大的影响。
● 设置应用设计环节，则业务设计和技术设计就可以分离得比较大。
● 如果不设应用设计环节，则业务设计和技术设计就要发生直接交互，对业务人员和技术人员的能力要求都会提高。
8.2.6 工程分解与资料引用
由于按照工程化设计的方法进行设计，所以软件工程上的各个阶段产生的设计资料都是必须要继承的
其中①和②为需求工程的内容。
③概要设计：对②需求分析的内容进行规划，并制定指导后续进行设计的设计规范等。
④详细设计：在③概要设计确定的范围内，依据②、③的内容进行细化设计，全部的设计成果需要符合③概要设计制定的标准及各项约定。
⑤应用设计：是将④详细设计的成果转换为系统的表达方式，同时还要设计③概要设计中已规划好的、但④详细设计中没有涉及的内容，如系统功能（来源于②）。
⑥技术设计：由于③、④和⑤三个设计中都有不重叠的内容，因此，⑥技术设计要参考前面的需求分析资料和全部的设计资料。
⑦软件开发：严格依据技术设计成果进行开发。
⑧软件测试：需要用到业务设计和应用设计的用例。
⑨系统验收：与客户签订合同的依据是需求规格说明书（来源于②）。注：设计原则
（1）对于⑥技术设计来说，①和②的需求工程资料只是“参考资料”，而不是“设计依据”（除去需求资料中关于技术方面的需求）。
（2）当③～⑤发生了遗漏或错误时，技术设计师必须首先与担当的设计师确认，在获得一致意见后，首先由担当的设计师把遗漏部分追加到相应的业务／应用设计资料中，然后依据修改后的业务／应用设计资料再进行技术方面的修改。
8.3 工作分解
从软件工程结构图上可以看出，在设计工程的三个阶段中，纵向的“工作分解”是一样的，都是分为三个设计层，即架构层、功能层和数据层。工作分解的顺序是由粗到细、由上到下，设计工程的三个阶段都是围绕着架构、功能和数据三个层进行不断地细化和深化。
8.3.1 工作分解1——架构层
架构层是工作分解的第一层，它的核心工作是进行业务架构，通过从概要、详细和应用三个阶段接力式的设计，完成了从业务架构的规划、详细的流程分歧，到最终转换为系统应用架构的机制。
8.3.2 工作分解2——功能层
功能层是工作分解的第二层，它的核心工作是用户操作界面的设计，通过从概要、详细和应用三个阶段接力式的设计，完成功能需求→业务功能→业务组件的转换过程，最终完成用户的操作界面设计。
8.3.3 工作分解3——数据层
数据层是工作分解的第三层，它的核心工作是对数据的设计，通过从概要、详细和应用三个阶段接力式的设计，完成了对数据整体规划、领域规划、主数据选择、数据标准制定、数据模型、数据的复用机制等一系列的设计。
8.3.4 工作分解4——三分层的关系
1．价值方面的不同
简单地说，架构是功能产生和确定的基础，功能是数据产生和确定的基础。但三个设计层的目的不同，架构与数据本身是客户的价值所在，而功能是工具。
1）架构层
架构层的内容是对业务优化后的成果表达，业务优化的成果可以直接为客户带来成本下降、效率提升、效益收获等价值，因此架构层的成果是客户投资的直接目的之一。
2）功能层
功能，是组成架构的要素，通过功能可以产生数据。没有功能形成不了业务架构，也无法记录和查看数据，但是功能并不是客户投资的直接目的，最终的业务价值和信息化价值是体现在架构和数据上的，功能是产生上述价值的工具（没有这个工具无法产生价值）。
3）数据层
数据层的内容是企业的资产，数据的积累和有效利用（统计、分析、挖掘）会为客户提供解决旧问题的途径、找到新商机的启示，因此数据层的成果是客户投资的直接目的之一。
2．生命周期的不同
企业的管理方式会随着时间和环境的变化而变化，这个变化会带来业务架构的变化；同样随着IT技术的进步，功能的显示和操作方式也会随之发生变化（PC端→移动端），但是无论架构和功能如何变化，都希望数据的结构和标准可以保持5年、10年甚至几十年都不改变，如果因为架构和功能发生了变化而不能再利用已有的历史数据，则这个数据资产就不存在了。这也是为什么业务设计师也必须要关注、掌握数据的规划和设计能力的原因。只重视功能设计，而不重视架构和数据的设计，这为系统长期使用带来以下两个大隐患。
（1）架构设计不足，由于缺乏顶层规划和设计，会造成系统的应变性差。
（2）数据设计不足，复数系统间的数据难以打通，数据无法共享、复用，造成信息孤岛现象。
三分层内容的生命周期由长到短分别为：数据＞架构＞功能。
（1）功能的形态最容易发生变化（客户需求变化、硬件技术的进步等），生命周期最短。
（2）架构的形态随着业务标准变化而变化（业务不变，架构也不变），生命周期的长短居中。
（3）数据如果做好标准化设计，其生命周期则可以做到最长（也是客户最希望的），因为只有数据生命周期长且大量积累，才能发挥出数据的价值来。
8.3.5 工作分解5——业务与技术的分层关系
1．技术设计的三层构成
理解上述分层的成果与技术设计三层结构的对应关系，可以理解业务设计分层的作用和价值。技术设计的三层结构通常为：应用界面层、业务逻辑层和数据访问层
（1）应用界面层：位于最外层（最上层），最接近用户。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。
（2）业务逻辑层：位于三层之中，它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计。
（3）数据访问层：位置居于三层之后，其功能主要是负责数据库的访问。
2．非技术设计
与技术设计的三层对比非技术设计（业务设计、应用设计）三分层的成果支持了技术三分层的设计工作，非技术设计的各层成果如下。
1）架构层成果
①主要是获取“业务逻辑”，它向技术的“业务逻辑层”提供了业务逻辑、机制（逻辑的应用表达）。
2）功能层成果
主要成果是获取了“界面形式”和“数据”，分别向技术各层提供如下信息。
②向应用界面层：提供业务操作的原型等。
③向业务逻辑层：提供界面操作过程、数据处理规则、管理规则等。
④向数据访问层：提供数据和定义。
3）数据层成果
主要成果是获取了“数据逻辑”，分别向技术各层提供了：
⑤向业务逻辑层：提供了数据逻辑（算式等）。
⑥向数据访问层：提供了数据表关系。
可见，非技术设计中的每个阶段、每个阶段中的每一层的设计成果都是直接或间接地为后续的技术设计各层提供了输入和依据。
8.4 管理设计
在分离原理中已经讲过了，业务与管理分离，业务是管理的载体，管理是对业务标准执行的保证措施，因此，管理的思想、理念、原则等可以先行规划，但是具体的管理设计要在业务载体的相关设计完成之后才能进行。
由于管理功能是以业务功能为载体的，所以管理设计的内容分布在功能层的三个设计阶段中。
（1）管理的概要设计：进行管理的顶层设计、规划。
（2）管理的详细设计：在业务功能的详细设计（业务4件套）之上进行管理细化设计。
（3）管理的应用设计：将业务设计中的管理设计成果转换为机制，给出实现管理的方法。
8.5 组织设计
企业组织管理具有三个重要的职能：建立管理机构，配备岗位人员，制定规章制度。在信息系统中，上述三个职能工作被融合到以下的功能中。
1．建立管理机构
通过建立组织基础数据库的形式，将组织结构的形式固定下来，其中包括公司、子公司、部门、岗位等。另外，组织结构在信息系统中有一个非常重要的作用，大量的查询、抽提、统计和分析操作都是要以组织属性为关键词进行的，它也是各类统计、分析报表的“维度”属性。组织，作为数据设计的部分内容。
2．配备岗位人员
在系统上线后，通过系统的“权限功能”，为所有在组织结构内有“岗位”的员工给予一个在系统中对应的“角色”，所有具有系统权限的角色都被称为“系统的用户”。权限，作为组合设计的部分内容。
3．制定规章制度
企业的组织部门制定的企业管理规则，如果参与信息化管理，则一定要设置到相应的操作环节中，有效的规章制度一定要以规则的形式融入到系统操作的各个环节中去才能发挥出作用。
组织部门相对于其他部门的工作是一种“管理行为”，但是组织部门内部的工作则与其他部门的工作是一样的，也是具有“业务”和“管理”两个层次，同样符合分离原理。虽然领域的专业知识不同，但是针对组织对象的分析与业务设计方法是一样的。
8.6 物品设计
分属于物品类的要素由于都是“硬件”，所以通常不会直接影响到企业管理的业务架构、管理架构和组织架构，对物品的架构在企业的业务活动中一般是自成体系的。物品类要素在企业管理系统中主要是以“基础数据”的形式存在的，对物品类对象的设计工作主要有两个内容：数据编号和数据管理。
1．数据编号
对物品类数据的编号是企业管理信息化的重要内容，物品类要素的数据属于企业的基础数据，它牵扯到企业的标准化、规范化工作，编制物品的数据编号需要很强的专业知识。但是如何标准化、如何标准化才能最大限度地发挥出信息化的价值并非是客户所擅长的工作，这是需要业务设计师给予他们指导的。
2．数据管理
对数据进行编号实际上也是一种管理，完成了数据编号后，为了保证这个编号体系在实际运用中得以被正确运用，就需要有相应的保障措施，这个保障措施就是“字典”功能，对物品编号是企业标准化管理的重要组成部分，通过字典功能上的各项管理规则，可以保证物品数据被正确地应用、统计。
8.7 价值设计
价值设计并非是一种新的和独立的设计体系，它提倡的是在做系统设计的同时，重点思考一下：通过信息化手段改造了企业的管理模式后，给客户带来了哪些可以直接感受到的变化和价值，重点思考两个方面的价值，即业务价值和应用价值。
● 业务价值：客户业务的本身，通过软件商的优化设计，有了哪些变化和价值。
● 应用价值：客户业务与信息化环境结合后，为客户生产方式带来了哪些变化和价值。“业务价值”和“应用价值”一定要能够用最终的客户“效率”和“效益”进行表达，这些价值是通过设计融入到系统中的。
8.8 验证用例与规格书
8.8.1 验证用例
对设计成果的验证分为两个阶段：业务验证用例、应用验证用例。
1．业务设计阶段
业务设计阶段的验证用例称为“业务验证用例”（简称业务用例），由于业务的概要设计和详细设计成果构成了一个完整的业务设计，因此业务设计两个阶段共用一个验证用例，它利用具有连续性的业务场景从业务视角出发，在用例中加入了包括流程、数据、管理规则等内容，通过模拟运行对业务设计的成果进行验证。
2．应用设计阶段应用设计阶段的验证用例称为“应用验证用例”（简称应用用例），将业务验证脚本与应用设计成果（组件、机制）相融合，编制出一个可以模拟系统完成后的应用效果，对业务设计和应用的成果进行综合验证。
8.8.2 设计规格书
软件工程每个设计阶段完成时，需要有对这个阶段设计成果的汇总，以及对设计成果的验证，这就是各类规格书与验证用例。
1）业务设计阶段
（1）概要设计规格书。概要设计是设计阶段的开始，因此，概要设计的成果汇总成概要设计规格书，它是指导后续所有设计、开发、测试的依据。概要设计规格书包括架构、功能和数据三个分层的概要设计资料。
（2）详细设计规格书。所有系统中与业务相关的架构、功能和数据细节都在此确定，在此之后的设计（应用、技术）都应该遵循业务设计结果，不得改变（除业务设计师许可外）。详细设计规格书包括架构、功能和数据三个分层的详细设计资料。概要设计规格书与详细设计规格书两者构成了完整的业务设计。
2）应用设计阶段
在业务设计的成果之上加入系统的要素，完成的设计成果汇总成应用设计规格书，它确定了系统中关于用户应用的方法，在此之后的技术设计与编程实现不得改变（除应用设计师许可外）。应用设计规格书包括架构、功能和数据三个分层的应用设计资料。
小结
设计工程的工作，是软件工程中决定系统的设计规范、架构、功能、数据以及客户价值的核心部分。最终客户的信息化价值体现、满意度主要取决于设计工程的工作，这其中业务设计部分和应用设计部分又是对客户的信息化价值起着最为核心的作用。
设计工程的内容很多，按照设计的内容形成了一个3×3的设计矩阵。通过4条设计线①～④，可以看出设计工程的构成思路如下。
线①：设计工程分为三个阶段：概要设计阶段、详细设计阶段和应用设计阶段。
线②：每个阶段内再分为三层：架构层、功能层和数据层。
线③：每个层的设计分为三步：将需求转换为系统的形式，如功能层通过功能概要、功能详细和功能应用的三步设计，将功能需求最终转换为系统的组件。
线④：对研究对象，从最大粒度的设计（架构）到最小粒度的设计（数据）进行了全面的、体系化的分析和设计。按照分离原理4分类的内容，设计安排如下。
（1）由于业务设计、组织设计和物品设计的方法相似，所以将这三者的内容融合到一起设计见中c1。
（2）“管理设计”由于要以业务设计的结果为载体，c2所以放到最后的综合设计篇中。
（3）其他的“价值设计、用例设计、规格书与模板”由于是针对总体的设计，所以也一并放在综合设计中讲述，c3～c5。
这个结构给出了从上到下、从粗到细、从业务到系统、从架构到数据、从逻辑到机制的分析、设计和转换的过程，按照这个设计矩阵进行作业，就可以达到设计工程化的目的。
软件工程，不但可以支持分析与设计，而且可以支持软件的项目管理