编辑导语：在上一篇文章中，作者介绍了关于软件开发设计验证中的检验应用设计的质量，但是在应用设计验证中，还有更多重点项目，比如工作效率、运行流程等等方面；本文作者分享了关于应用设计验证与应用用例，我们一起来了解一下。

设计验证的第二层是检验应用设计的质量。应用设计的检验是对软件“好用”的保证，它解决了如何用信息化手段提升客户的工作效率。

应用设计验证重点包括：业务设计的结果在系统中的落地是否顺利？流程的流转是否合理？界面操作是否友好？工作效率是否有明显提升？等等，应用设计的成果“为客户构建了信息化的工作环境”。

软件如果不好用，则业务设计得再好、领导给的压力再大，用户都会排斥使用系统，可以说系统的易操作性直接关系到了软件的生命周期也不为过；应用用例是后续测试用例的重要输入，同时也是用户上线培训的教材。

一、定义

1. 应用设计验证

通过编写一套操作步骤，用以模拟某个业务处理场景的实际操作过程，应用验证最好采用高保真的界面原型、并且可以按照预定的流程进行跳转。

这套操作步骤将包括登录、启动流程、打开界面、数据输入、通知、监控等在内的功能串联在一起，用以验证操作过程是否满足用户的实操需求，可以说是对业务用例的内容在信息化环境下“操作满意度”的检查。

应用设计验证的主要工作是编写应用用例和验证结果。

2. 应用用例

是针对应用设计阶段成果的验证依据。应用用例是将应用设计的组件（界面）、按钮控件、菜单、监控、通知、权限等构成了一个虚拟的操作环境，在界面上运行业务用例的数据。

应用用例的运行要符合业务用例中的业务逻辑和数据逻辑关系，因此应用用例可以模拟系统完成后的实际使用场景，它可以让用户、需求工程师、技术人员（设计、开发、测试）等所有相关方在系统完成开发前，就基本上知道了系统完成后的运行效果。

• 用例构成：用例场景、运行导图和基础数据；
• 编写期间：是在应用设计期间编写的，在应用设计完成时进行验证；

注：应用设计与业务设计的关系。

应用设计的成果相当于业务设计成果加上了一个可以操作的“外壳”。用户是通过应用设计内容（界面、按钮等）去操作业务设计的内容（数据、规则）的。

图1 业务设计与应用设计的关系

应用设计要求需求工程师具有跨界的知识和能力，包括（不限于此）：客户专业知识、业务设计知识、技术开发知识、UI设计、美工设计知识、系统上线经验等。

3. 应用用例的作用

应用设计验证检验了所有的系统功能的使用方法、使用顺序、操作步骤、相应的规则等，图2 表示了在软件工程框架上编写应用用例的位置。

图2 软件工程框架上应用用例的位置

应用用例可以模拟“人-机-人”的工作环境，通过与用户的共同确认帮助进行以下的验证（不限于此）。

1）支持验证应用设计结果

• 模拟系统完成后的操作环境，感受应用操作的效率、人机友好满意度；
• 可以提前发现和解决隐性设计缺陷，减少开发完成后的软件商与用户之间的认知误差；
• 统一系统干系人对设计的认知，认知包括对以下内容的理解：架构、功能、操作等；

2）支持测试用例的编制

作为后面测试用例的“操作流程”案例，与应用设计成果（界面、控件）、业务设计成果（业务逻辑、数据逻辑）等共同组合，支持编写测试用例。

3）使用对象、使用场合

• 在软件公司的设计相关人中间进行讨论、验证。
• 与用户的相关部门、岗位进行沟通、确认。
• 向后续设计、验证提供功能、逻辑、数据、机制的支持。
• 做为客户上线培训的重要资料等。

4）客户价值

除去对功能方面设计成果的验证外，应用用例还有一个重要作用就是对应用价值的验证，应用用例可以让用户直接感受到应用价值的存在。

感受应用价值的方法有很多，比如

• 按照角色：应用用例可以按照不同的企业角色去编写，如董事长、财务总监、项目经理、库管员等，让各角色都清楚地知道他在系统中的工作内容和要遵守的规则。
• 按照流程：应用用例可以沿着不同的流程去编写，如采购流程、报销流程、物流流程等，将每一条流程相关的功能全部串联起来，用以检查流程上各角色之间的协同是否有问题等。

二、应用用例内容

编写应用用例是应用设计验证的主要工作。一个完整的应用用例由三个部分构成：用例场景、运行导图和基础数据。

应用用例与业务用例在场景设计选择上有所不同，业务用例更多的是验证业务本身（以某个业务线为主轴设计），而不在意该业务由那个角色来处理，但是应用用例的“应用”不但要有主线而且还要针对角色而设置的用例；重点在站在某个角色的立场上将“该角色关心的内容整合成流程”加以推演，因此，在确定题目、目的和价值之前需要首先确定操作角色。

• 角色：按照部门、角色规划（董事长、成本会计、仓库管理员、…），或是一组角色。
• 题目：从该角色的视角出发，选定题目。
• 目的：根据上述的题目，确定该角色关心什么、要什么结果。
• 价值：达到了目的后，可以给该角色带来什么价值。

从角色出发设置用例场景，这就是为什么说应用用例可以验证客户的信息化价值的原因。

1.用例场景

以某个工程项目的项目总监为对象，参见图3。

图3 项目总监的看板

• 角色：项目总监。
• 题目：项目总监的项目管理看板。
• 目的：项目总监打开界面就可找到他所需要的信息、完成想做的事。
• 价值：项目总监可以及时地掌握公司全部项目的走向，快递地做出判断。

为了可以达到目的，场景设计时在一个界面上将项目总监关心的信息、材料、以及总监需要操作的功能、待办事宜、发布的通知等全部功能集中，甚至将企业知识库（公司规章制度、法律法规等）全部链接起来，让项目总监不用频繁地点击菜单四处寻找就可以知道自己在信息系统中能够到什么信息、处理什么工作等。

同理，也可以设计出董事长、总经理、总会计师、仓库管理员等各类企业运营中关键角色的应用用例，在系统上线前让他们充分地理解和意识到系统上线后的变化，可以提前做好准备，包括：组织、岗位的调整，相关管理规则的调整。

2. 运行导图

运行导图，是用图形的方式，将场景的内容按照操作流程的顺序详细地呈现出来，它包含了在系统中操作的主要步骤、主要操作功能（节点）、以及想要呈现给观者的信息化环境下最具应用价值的内容。

1）运行导图的构成

运行导图的内容、方式可以根据应用设计师向用户、技术设计师展示的内容而定，但是有以下几个必须要有的核心内容：

• 操作导图：给出应用用例的主线。
• 操作界面：给出操作流程图上每个节点的组件原型界面截图。
• 数据导图：给出每个节点上需要的外部数据源，比如：基础数据（字典）等。
• 管控导图：给出具有管控功能的系统机制，说明如何进行管控。

系统运行时的操作流程不是业务设计中的业务流程，可以看做是在系统上运行的“业务流程”；比如，在业务用例中，业务流程是将业务功能用逻辑串联起来，但是在应用用例中，实现同样流程可以采用“事找人”的主动推送流转方式。

2）运行导图的设计

【操作导图】：

下图是用来描绘“成本管理”模块的操作流程示意图，参见图4。

图4 操作导图

• 目的：应用用例的主要导图，可以让用户完整地、准确地知道系统上线后的工作环境。是系统完成前用户就了解系统带来信息化价值的主要途径。
• 特点：虽然不是真实系统，但是用户的感受与完成后的真实系统是一样的、否则用户不能提前指出系统是否存在问题、或是双方之间是否有理解上的误差。
• 内容：需要详细到具体点击的是哪一个按钮、哪一条有链接的数据等，虽然界面是原型但是由于有控件（字段、按钮）、链接、提示框等系统的要素，用户完全可以体会到系统完成后的环境。

【数据导图】：

当推演的场景非常复杂，仅仅依靠操作导图、界面截图等内容不足以说明业务逻辑、数据来源等隐性的设计成果时，可以采用数据导图作为辅助，揭示运行导图（节点）背后的支持的数据等内容，如图5所示：

图5 数据导图

• ①绘制简单的运行导图（只要有节点名称，不需要看清楚界面的内容）。
• ③在节点下方标示出该节点必需的基础数据、管理规则库的名称等（在该节点首次输入）。
• ③在节点数据源下面给出数据之间的逻辑关系、以及内部的复杂处理算式规则等。

3. 基础数据

这里讲的基础数据是个广义的概念，它包括了所有系统运行前需要准备的数据。

1）基础数据设置

这是重要的企业信息化管理内容，它包括了如何编制所有的系统运行所需的用字典形式进行管理的数据，对象有：材料字典、设备字典、产品字典、组织字典等。

2）管理规则设置

管理规则也是一套“数据”，这些规则需要由客户的相关部门根据自己部门所管的业务功能，预先制定出可以支持信息系统用的标准和对应的规则，然后在系统运行前设定到系统中，比如时限用的规则表。

3）分歧条件设置

通过运行导图的推演，与用户具体的确认有关联流程的基本设定条件，如

• 业务流程：流程的分歧、流转所依据的业务标准、对应的管理规则等。
• 审批流程：审批条件、通过、拒绝等的标准、对应的管理规则等。

4）系统权限设置

为每个系统用户设定权限，体现了“信息化环境”管理的方式，这个方式可以协助组织管理部门进行精确地管理，它也是信息化环境下的组织管理的重要内容和手段。

三、应用设计验证过程

验证过程在编写应用场景、绘制操作导图、数据导图的时候就开始了：

• 系统运行前必须准备好的基础数据（输入）。
• 按照应用场景进行流程启动、结束、通知。
• 对流程上的每个功能界面的进行操作。
• 检验每一步操作的合理性、易用性，等。

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

注1：应用设计验证与业务设计验证的区别。

业务设计验证只关心与数据相关的内容，如：对合同编制功能的业务验证，重点在与合同相关的业务逻辑、数据逻辑、数据来源、管控规则等是否正确；但是对操作合同编制界面的输入效率、如何查询合同相关信息、合同完成后如何锁定数据的等内容不涉及。

注2：应用用例与操作手册的区别。

操作手册一般是按照界面操作的每个字段、按钮进行说明的，非常细，是对完成的软件操作知道；应用用例是对操作是否合理的检查、验证，当然有了应用用例后编写操作手册会容易。

四、总结

相对于建筑业、制造业、影视业等都要进行设计阶段和制作阶段两次的检验来说，软件行业基本上只有制作完成后的一次检验。

软件行业为了保证产品质量也应该加上双保险：设计验证和软件测试。目前对设计阶段成果的验证还不普及，研究也不够深入。

从前面的探讨可以看出来，如果没有进行设计验证，仅仅依靠软件测试，待发现了设计问题时就一定要进行返工了，这样做是不能保证软件产品的最终质量的。

软件行业的发展还很年轻，经验还不足，因此应该借鉴其它行业的好方法好经验，快速提升软件行业的产品质量，提升客户对软件产品的满意度。

作者：李鸿君；著有《大话软件工程—需求分析与软件设计》一书。

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

题图来自 Unsplash，基于 CC0 协议