编辑导语：在上篇文章《软件质量的双保险（1）——设计验证与软件测试》中，作者谈到判断软件设计的结果是正确的，要用到“设计验证”的方法，包括“业务设计验证”和“应用设计验证”两个部分，本篇文章中，作者继续分析了设计系统的验证用例。

对需求工程师来说，编写一次完整、完美的业务用例所带来的能力提升，可匹敌多次设计同类系统的收获，因为带有业务场景的用例整合了架构、功能、数据、管理等多层面的内容，且由于用例是用数据、规则的细粒度写成的，如验证结果没有问题则为系统上线成功提供了保证。

如果写不出自己设计系统的验证用例，说明他对系统是否能够成功运行是没有把握的。有用例帮助检验结果，不但能减少设计和编程错误，还能在设计阶段就掌握上线后的细节和效果、提升客户满意度，同时详细完整的用例还可以用作上线培训资料。

一、定义

1. 业务设计验证

通过编写一套业务数据用以模拟某个业务处理场景的全过程，用这套数据将系统中要验证的对象串联起来，用以验证业务设计的整体架构、业务流程、界面字段、数据关系、计算公式、管控规则等内容是否正确，确保系统中的业务逻辑、数据逻辑是正确的，业务设计验证的主要工作是编写业务用例。

2. 业务用例

是针对业务设计阶段成果的验证依据，业务用例将专业知识、业务设计部分（业务与管理）的成果，通过业务场景将流程、功能、数据、规则等串联在一起，用以验证业务逻辑、数据逻辑是否正确、功能是否可以满足设计的要求。

• 用例构成：业务用例是由三个部分构成的，用例场景、数据结构图、数据推演表；
• 编写期间：业务用例是在业务设计期间编写的，在业务设计完成时进行验证。

3. 作用

业务用例的粒度包含了从架构（粗）-数据（细），因此可以精确地验证如下的内容（不限于此）。图1 表示了在软件工程框架上编写的业务用例的位置，业务验证的作用如下：

图1 软件工程框架上业务用例的位置

1）支持验证业务设计结果

• 确认业务架构的合理性、业务优化的效果；
• 检查业务逻辑、数据逻辑的正确性，找出隐性的逻辑错误；
• 通过数据推演，找到业务流程设计上的“断点”、或是“多余点”等。

2）支持应用用例的编制

作为后面应用设计用例的“业务数据来源”，与应用设计成果（界面、控件）等共同组合，形成应用用例。

3）支持测试用例的编制

由于业务用例含有精确的“业务数据”，可以为测试工程师编写测试用例提供数据、规则等来源，同时也可以帮助测试工程师更好地理解系统的业务背景、业务逻辑。

4）支持上线培训

业务用例的数据、规则等由于模拟的是实际业务场景，上线培训时用户可以直接按照业务用例中的数据进行练习，加快学习和理解的系统的速度。

5）使用对象、使用场合

• 业务设计师进行内部讨论、验证；
• 与客户的相关部门、岗位进行沟通、确认；
• 向后续设计、验证提供逻辑、数据的支持等。

6）对软件客户价值的检验

软件客户价值来源于业务设计和应用设计，其中业务设计产生的业务价值包括：

• 经过业务设计后，企业的各类过程清晰（业务流程），如：合同流程、采购流程等；
• 企业的各类规则标准化（字典），如：客商、材料、采购、支付等；
• 各类需求调研时的客户痛点的解决方案等。

二、业务用例内容

编写业务用例是业务设计验证的主要工作。一个完整的业务用例由三个部分构成：用例场景、数据结构图和数据推演表，其中：

• 用例场景：用以确定需要验证的对象、目的；
• 数据结构图：利用架构图来表达用例场景的数据流转过程；
• 数据推演表：利用数据结构图，详细数据、规则来推演验证用例场景描述的过程。

1. 用例场景

一个系统的业务设计完成后，需要对那些部分进行验证是根据需求工程师（或业务专家）的判断来决定的，通常判断是否需要验证的条件如下（仅做参考）：

• 业务场景、业务逻辑非常复杂的部分；
• 业务计算的逻辑复杂、数据来源复杂、且需要多重计算；
• 待开发的软件是新产品、或涉及到新的业务；
• 软件涉及到多人协同、多系统协同等的场景；
• 客户对某个业务场景非常关心、且需求工程师把握也不大的情况等。

大型的、复杂系统可能要编写多个，甚至十几个业务用例。每个业务用例的对象、目的都不同，它们的验证结果合起来就给出了该系统的业务设计成果是否满足要求。

下面给出具体的用例提纲（作为后续设计用例场景），用例的数据关系参见图2。

• 题目：工程项目的成本过程管理；
• 目的：一是验证成本发生过程的逻辑的正确性、二是成本过程的可控性；
• 价值：充分展示“信息化环境”下的成本管理方式、带来的价值（传统方式做不到）。

根据上述提纲，用例场景具体数据设定如下，其中，企业为两级组织（公司、项目部）：

• 场景的起始数据①=合同总额=1100万元；
• 目标数据④公司预留利润额=100万、目标数据②项目部预留利润额=50万；
• 预算总额分为4条线支出，即：材料线、设备线、劳务线和经费线；
• 结果数据①公司实得利润额=80万（减）、结果数据②项目组实得利润额=-20万（亏）。

这个用例场景给出了“成本管理”的关键环节（节点数据），有了这个关键节点的指引，第二步做出“数据结构图”（验证用的框架）、第三步写出“数据推演表（验证用的内容）”

2. 数据结构图

用例场景不但要用文字描述，还需要用一个可以表达场景的数据结构图，这个图可以给出：场景开始的目标数据、场景结束的结果数据、以及表达从目标数据→结果数据的变化过程的结构图。

图2 数据结构图

1）结构图

数据结构图，是以功能的结果数据为节点、以数据间的关系为连接形成的图形，给出了从目标数据→结果数据的变化过程这个结构图中同时体现了“业务逻辑”和“数据逻辑”。

• 形式：采用流程与分解两种模型的混合体，来源于流程图的流向和和数据的分解结构；
• 来源：结构图的内容来源为用例场景；
• 节点：节点标注的是“功能名称+数据”，这个“数据”是该功能的处理结果，节点不一定都来自于流程，也可以是“数据库名称+数据”；
• 关系：节点之间的关系是数据关系，前后之间是计算关系。

2）节点

根据用例的题目、场景来确定涉及到的哪些业务设计的成果，节点要素可能是一个功能（活动、字典）、或是一个数据库，设计数据结构图需要将所有参与场景的要素找出来，然后用数据关系把它们关联起来。

由于本课题是“成本管理”，所以节点一定都是来自于与成本管理有关的功能（或数据库）。图21-7为本用例的数据结构图，解读如下：

• 合同总额①=1100万，①=②+③+④=950+50+100；
• 目标1：公司预留利润额④=100万，结果1：公司获得利润额⑧=80万（减少）；
• 目标2：预算总额②=950万， 结果2：成本结算额⑤=1020万（超标）；
• 项目部预算超额⑥：⑥=②-⑤=950–1020=-70万，预算超额70万；
• 项目部实际利润⑦：⑦=③-⑥=50–70=-20万，项目部实际利润额为-20万；
• 公司为项目部承担了20万的亏损额，因此，公司实际利润额⑧=④+（-20）=100-20= 80万（公司实际利润额为80万，减少了20万）。

另外，要注意数据结构图的节点设置原则：

• 节点上的数据一定是该功能内部处理完成、且与成本管理相关的数据；
• 节点上的数据必须是“数字型”（需要进行计算），而不能是“文字型”；
• 节点上只标注计算的结果，而不要计算的过程数据（留在后面的数据推演表中表达）；
• 节点的粒度都要一致，包括：数据类型、数据的单位。

3. 数据推演表

有了数据结构图，目标和结果数据后，下面用一个数据推演表，将数据结构图中的从“目标数据”→“结果数据”的数据变化过程用完整地列出来，数据推演表涉及到的主要内容可以分为三个部分：

• 用例场景的要求，比如：项目部的预算要亏损，最终项目部利润为负值；
• 场景中每个节点内部的数据计算方法、公式；
• 用例目的中规定的管理规则要求，如：成本过程的可控性。

数据推演表是对数据结构图上每个节点的内部数据进行详细地表达，每个数据推演表的最终合计值填写到数据结构图的相应节点上，以数据结构图上“预算总额 = 950万”为例，预算总额见表1。

表1 预算总额表（数据推演表） 注：表中的红字为“父”节点。

每个节点对应一张类似上述的数据推演表，这个数据推演表里记录的就是功能中数据和数据的计算过程。

虽然数据推演表编制时的工作量很大，但正是有了详实的数据对后面的测试、以及系统上线培训都起了很大的帮助，因为不返工或是减少了返工总的周期可以大幅度地缩短，提升了一次上线的成功率。

反过来也可以说明，如果复杂系统的数据不进行预先的纸上推演，怎么保证软件开发完成后可以准确的运行呢？凭什么说设计是正确无误的呢？

三、业务设计验证过程

验证过程在编写业务场景、绘制数据结构图的时候就开始了：

• 绘制数据结构图的依据是对应的业务流程图，绘制数据结构图时可以确认业务逻辑；
• 数据结构图上的每个节点都对应着一个具体的业务功能；
• 每个功能又对应着一个或一组原型界面；
• 每个原型界面上的数据对应着一个或一组数据推演表；
• 每个数据推演表中的数据在填写时都必须给出清晰的数据来源；
• 确认数据推演表中的所有数据及相关计算公式、管控规则，可以确认数据逻辑。

按照这样的方法推演下来，基本上就可以确认业务设计的结果是否正确了。

本文由 @李鸿君 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议