分析得出界面设计如上图所示，设计方法实现了相同度较高的任务进行合并操作。并能增强和明确用户群体的责任和任务内容。原型图合并的功能是更新订单状态以及处理异常订单，这两个任务重叠的部分可以一并处理。

　　总结：将当前的设计范围内的数据进行深入的调研以及思考，在此基础上确立用户群体，并确定数据的矩阵，然后设计对应的任务，再者是确定类。能较为有效地完成系统设计层面的分析工作，并能规范用户群体需要执行的任务以及任务的价值。总体来说属于比较清晰的设计思路。

　　3.1数据型B端需求文档设计理念

　　数据型B端需求文档设计理念：由于数据型B端设计理念突出的是以数据为重点，为了更好地突出这个特点，对应需求文档的设计以及格式需要结合一起进行调整。在说明设计理念前，需要对系统有整体的认识，个人理解的B端系统无不可以分为三个部分：数据、控件、界面。系统作为一个事物，数据控制着系统的内容、控件控制着数据的内容、界面包含着控件以及数据。将系统作这般拆解的意义在于需要将原来文本化的需求文档转化为可以被系统记录并且较为清晰地反应逻辑的需求文档以便更好地结合新设计理念。其中一个较为重要的原则是，需要将所有逻辑以及所有涉及的数据标签化，这样才能叫逻辑利用计算机去快速检索并透明化显示。

　　数据型B端需求文档期望达到以下目标：

　　系统以及数据逻辑的透明化展示。

　　结合数据型B端设计理念，对系统进行更科学的管理。

　　数据型B端需求文档具有以下特点：

　　文档界面化设计。方便对于历史需求文档以及逻辑的查看。

　　标签化表达界面，清楚每一个界面的流转以及使用人员。

　　控件标签化设置，清楚每一个控件的作用。

　　数据流转、数据限制以及数据逻辑标签化，方便查看数据的流转以及运用方式。

　　整体标签化设计与规划，方便日后查看，与梳理。

　　与数据型B端设计原则结合，形成有机整体，提高系统的可设计性与清晰度。

　　数据型B端需求设计文档设计中的原则是将系统中的数据标签化，达成作为系统背后的系统的目标，有利于监控目前的系统运行情况，并方便人员对系统进行规划和梳理。以及与新设计理念形成一套体系，从系统需求设计开始直至需求文档的编写都可以在同一原则下进行和管理。

　　3.2 数据型B端需求文档设计的优劣

　　数据型B端需求文档设计的好处在于：

　　实现系统逻辑以及数据流转的清晰度，方便日后系统的升级与优化。

　　方便操作人员理解系统结构，有助于提高需求的质量。

　　数据型B端需求文档设计的坏处在于：

　　前期转换难度较大，因为数据型B端需求文档的编写对于目前需求文档的编写会更有规则性，目前需求文档的编写门槛较低。

　　数据型B端需求文档的改动难度会大于目前需求文档，因为编写的复杂性增加导致文档中的逻辑/页签描述增加。后期改动较复杂。

　　3.3 数据型B端需求文档设计的划分

　　首先，根据系统的原理和运用系统的方法，对于系统，我们尝试进行划分为数据、控件、界面三大部分，这三个部分包含了系统全部的主要要素，当然还可以将系统划分为数据、逻辑两大部分，但是为了配合新设计原则，需要将系统的功能划分至数据、控件、界面才能方便大家的理解和运用，下面分别对这三个部分进行展开，并加入例子方便理解。

　　在描述数据型B端需求文档的元素前，需要简单解释数据库。一般形式的数据库如下表。

　　这个表的形式类似于数据库，一般来说，系统中展示的值从数据库中取值而来。表头为数据库的数据名称。表头下面的内容为组成这一条数据的数据组成。例如：需要展示金刚负责的订单的时候，只需要取订单跟进人为金刚的数据量进行汇总展示即可。

　　3.3.1 数据

　　在数据型B端需求文档设计中将数据描述清楚需要重点关注三个词语：标签化、逻辑运算符、数值运算符。

　　标签化：对于运行需要的符号、数据、条件进行标签化表达。标签中，表的意思是“的···数据表中”、值的意思是“的···值”两者都是可基于目前已有的数据表选择，标签化是在新设计原则设计了系统原型并确立数据库的形式以及内容后才能进行新需求文档的标签化设计。