陕西十一选五任八|陕西十一选五前二走势

37路论坛

搜索
查看: 908|回复: 0
打印 上一主题 下一主题

数据型B端设计理念探讨

[复制链接]
跳转到指定楼层
楼主
发表于 2018-2-2 17:07:51 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式

本文总结了当前的B端设计理念的优劣并在此基础上衍生出个人的另外一种新的B端设计理念;也阐述了基于数据型B端设计理念重新设计的模型划分以及数据型B端需求设计文档中的编写规则。

  

  本文目录如下

  

  1.1 B端设计原理探讨

  1.2 当前主流B端设计理念的问题探讨

  1.2.1 数据型B端设计理念

  2.1 数据型B端设计元素

  2.1.1 数据型B端设计元素简介

  2.2数据型B端各设计元素间的关联关系

  2.2.1 数据型B端各设计元素间的关联关?#21040;?#35835;

  2.2.2 设计与案例

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

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

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

  3.3.1 数据

  3.3.2 控件

  3.3.3 界面

  3.4 数据型B端需求设计文档与数据型B端设计理念的结合

  3.4.1 数据型B端系统设计理念回顾与深入

  3.5 数据型B端设计理念与UML设计理念简单回顾

  4.1 数据型B端设计的后续优化

  4.1.1数据类的优化

  4.1.2系统层级的优化

  5.1主流B端设计理念简介

  5.1.1主流B端设计元素简单划分

  5.2主流B端设计文档的组成

  5.3主流B端设计文档与主流B端设计理念的结合

  5.4主流B端设计文档与主流B端设计理念的优劣

  6.1总结

  1.1 B端设计原理探讨

  请允许本人在这里浅显地探讨一下系统的本质系统的本质不同人会有不同的解读有人会认为系统是协助进行管理流程、监控流程从而实现流程的标准化有人会认为系统是一个全方位的功能对于企业文化、企?#20498;?#29702;、企业决策等有很大的作用等等个人认为系统的作用需要在系统的本质上去确定下来只有了解了事物的本质与规律才能较好地掌?#24080;?#29289;、运作事物、看清楚事物。毛泽东研究事物也是?#19981;?#20174;最本质的问题开始鄙人借鉴了一点点毛泽东的思想对系统设计进行一点点的研究得出了一些微小的成果希望能起到抛砖引玉的作用。

  将系统作为一个事?#38175;?#24453;并深入理解本质之后个人认为系统的本质为数据系统中的所有按钮、操作、界面展示无一不是对数据的修改以及对数据的阅?#21015;?#35201;人们所说的作用均建立于这点的基础上去进行延伸。例如人们认为的系统对企业文化、企?#20498;?#29702;、企业决策起到作用均建立于数据的设置、数据的整合并展示上去实现。数据可以说是一个系统的灵魂需求乃?#26009;?#32479;的功能无不通过对数据的改造和解读产生其余均为数据的左肩右臂所?#21592;?#25991;的数据型B端设计理论以及数据型B端需求设计文档均基于数据围绕展开。希望给读者一种新的思考与思路。

  1.2 当前主流B端设计理念的问题探讨

  一般B端设计理念或者主流设计理念(UML设计理念)是基于流程或用户故事对用户以及操作进行划分产生系统的设计。但业务发展或者人员调整的问题往往会导致流程的变动以及操作的变动使得这一设计理念后期会产生一系列的问题。

  盲目性系统的改进方案在系统的发展过?#35752;?#23481;?#36164;?#21435;计划性。

  复?#26377;圍?#31995;统的复?#26377;?#20250;增加导致很多操作无意义。

  滞后性基于流程的系统往往落后于业务只是较为简单地提供数据。

  1.2.1 数据型B端设计理念

  结?#32454;?#20154;对于B端系统以及主流B端设计理念的理解得出一点微小的思考结果!!数据型B端设计。数据型B端设计理念将分为两大部分进行阐述数据型B端设计理念和数据型B端需求文档设计。数据型B端设计理念可以理解为在数据为设计理念的基础上整理用户群体的需求并进行表达。数据型B端需求文档设计可以理解为将用户群体的需求结合数据型B端需求文档这种新的表达方法去展示。通过数据型B端设计理念和数据型B端需求文档设计这两者的结合从而达到系统扁?#20132;?#20197;及数据的清晰化管理的目标。

  1.2.1.1 数据型B端设计理念简介

  数据型B端设计理念包括数据、类、用户群体、任务四大元素通过对元素的重新划分以及一些规则的制定体现数据型B端设计理念。这一部分的重点在于将系统设计需求划分为四个元素并将划分后的元素在数据为前提?#38470;?#34892;有机组合从以明确各用户群体的任务以及任务所需要的对应的数据。

  1.2.1.2 数据型B端需求设计文?#23548;?#20171;

  数据型B端需求设计文档包括需求文档元素的划分和整合。数据型B端需求设计文档设计中有数据、控件、界面这三个元素。同样?#27169;?#25968;据型B端需求设计文档的编写规则也会相应地发生一些变化。和传统需求文档不同数据型B端需求设计文?#36947;?#20284;于流程图将系统背后的逻辑进行扁?#20132;允M?#25968;据型B端需求设计文档的方法也有利于数据型B端设计理念进行任务量和?#35759;?#36827;行规划。

  1.2.1.3 数据型B端设计理念的目标

  数据型B端设计理念主要解决的问题为UML设计流?#35752;?#20197;及一般B端系统设计流?#35752;?#20986;现的问题。

  调研时间过长调研方向不明确对于新需求人员需要重新调研。

  系统设计过于?#35272;?#27969;程的改进?#35272;?#20182;人意见?#37145;?#36739;强的主观能动性。

  逻辑描述因为文本的?#20498;?#23548;致一定程度上程序开发人员的误解。

  提高系统的易理解程度?#26723;?#38656;求人员设计需求的?#35759;取?/font>

  数据型B端设计理念主要达到的成绩。

  通过数据的整理与规划推动业务部门进行发展。

  优化当前系统设计理念提高需求人员的需求水平。

  建立一定的系统判断标准减少人员的主观判断。

  2.1 数据型B端设计元素

  数据型B端系统设计理念设计的大致流程为先明确需要的数据在此基础上确立用户群体并确定数据的特性然后设计对应的任务再者是确定类。在明确需要的数据时需要站在公司的层面上进行思考。若仅仅从用户的角度出发很容易就落入根据流程去设计系统的思维模式上不能达到去伪存真的目的。

  2.1.1 数据型B端设计元素简介

  数据型B端设计理念是将一个体系中的人员划分为数据、类、用户群体、任务四个部分。利用划分后的元素重新表达用户的需求。

  2.1.1.1用户群体

  用户群体产生相同类型数据的用户组成的群体根据定义即可在设计的时候将这一类用户划分出来组成一种用户群体。一般地一个岗位可称为一个用户群体。例如仓库文员即作为一类岗位也作为一个用户群体。

  2.1.1.2 类

  类承载从属于类的数据的主体称为类类的划分方法类似于数据库中表的划分是区分?#36136;?#25110;者系统中不同事物的方法这个类的定义与目前系统设计中类的定义是一致的。例如一个采购单中采购单创建时间、采?#22909;?#32454;对应的预定数、采?#22909;?#32454;、供应商名称这四个数据均从属于采购单可称采购单为一个类。

  2.1.1.3 数据

  (1)数据

  由用户群体产生的或者接受的信息称为数据。在数据型B端设计理念中数据的处理由为重要用户的任务涉及到数据用户需要了解的信息通过数据去体现用户群体的操作逻辑体现在数据的限制和输入输出中。这里的数据不单单是系统上的数据更包含自然环境中提供数据的事物与?#24405;?#24573;略这种数据的重要性往往会导致逻辑上行得通但是?#23548;?#38656;求与用户情况产生出入。

  (2)数据矩阵

  通过数据的确定程度、对后续影响的程度两个维度去进行判断。获得是否需要针对这些数据去进行后续的修改或者推送通知。

  A类数据是录入的不确定程度?#32454;]?#23545;后续影响较大的数据。所以后续的用户群体可以对其进行修?#27169;?#25110;者修改A类的时候可以让用户群体及时知道。例如餐厅的点菜数据属于不确定性?#32454;?#30340;数据所以后续的?#26041;?#20801;许经理层可单独修改客户的下单数据且将修改信息推送给厨房工作人员。其他数据如此类推。

  

  2.1.1.4 任务

  任务在不同数据组合的支持下去实现业务并产生数据称为任务每一个任务的组成元素为输入数据、输出数据(或输出的?#23548;?#20107;物)各种任务组成任务群不同的用户群体对应各自的任务群。任务元素的加入是为了更好地?#22870;?#38656;求人员在运用这?#22336;?#24335;分析时比较贴近?#23548;是?#20917;?#22870;?#20174;流?#35752;?#20998;析出需求转变为从数据中分析出需求并赋予需求相关的?#23548;?#24847;义。

  用户群体的任务可以分为单一型任务和复合型任务。

  (1)单一型任务?#22909;?#30830;所需要的数据如果产生的数据较为单一并且与其他任务输入和输出的数据不重复称为单一型任务。

  (2)复合型任务复合型任务与单一型任务不同点在于用户群体接受一系列的多种类型的数据并处理出不同的结果下面给出复合型任务中两种不同任务类型的数据划分方法。

  1.完全分离的多任务适用于任务之间的独立性较强需要的数据重复度为零对于这种多任务划分是简单?#27169;?#21482;需要重复单一型操作的数据划分即可

  *两个任务数据重复度=(任务一需要的数据”任务二需要的数据)/(任务一需要的数据+任务二需要的数据)

  2.有一定交集的任务。存在任务重复度不为零。

  2.2 数据型B端各设计元素间的关联关系

  数据型B端设计元素的运用的前提是对需要的数据进行充分的调研以及思考。并利用元素对整个范围进行划分以及整理。下面是对这些元素间的关联关?#21040;?#35835;。

  2.2.1 数据型B端设计元素的关联关?#21040;?#35835;

  UML设计中对于多个元素重新定义、划分并阐述各元素的关联关系相较于UML的版本。突出以数据为基础的新设计理念中的元素同样存在着关联关系四种元素的组合图如下

  

  如图所示任务是?#35272;?#22312;用户群体上?#27169;?#20219;务是?#35272;?#22312;数据的基础上。根据用户群体的需求以及公司发展需要去确立对应的数据并用图表的方式进行展示使用Axure或者其他画图软件进行绘制?#22870;?#26085;后检索。

  由于这种图例是弱化?#23548;?#27969;程强调流程的本质!!数据进行调研的时候需要较为认真深入并且认真记录输入输出的数据和任务这样后面进行调整以?#21543;?#32423;的时候公司发展需要作出改变的时候可以对用户群体的任务量用户群体的输入输出结果进行合理的数据分析并作出对应改造和判断。由于新设计原则不同于UML以及一般的设计原则建立于数据上的新设计原则对思维能力要求较强。

  2.2.2设计与案例

  以下设计案例根据单一型任务与复合型任务两种类型进行阐述。

  单一型任务中数据财务中需要人员对账单进行审核。在分析过后认为这个数据需要财务审核人员去产生。那么任务可以这样分析。财务审核人员需要的数据为单据?#25484;?#20184;款金额、对应单据的入库记录等这些数据不一定属于同一类这个时候需要对财务审核需要的数据进行设计对于各数据属性的理解可以分为单据、入库记录两类两类数据中的单据?#25484;?#25968;据与付款金额为付款单据类入库数量不?#32454;?#25968;量为入库记录类供应商账号、供应商资质、供应商优惠条件为供应商信息类这样分析即得出财务审核人员完成这个任务需要的数据类型以及设计出对应的类(或在原有的类中增加对应的数据)设计图务必建于唯一的设计版图中?#22870;?#20182;人查阅和新需求设计时参考如下图所示

  

  复合型任务中的数据采购跟单需要生成仓库的交接单生成财务需要的支付账单更新订单进度处理异常订单这些操作中都涉及到了入库数量以及不?#32454;?#25968;量的数据所以这个用户群体的任务进行划分时需要区分数据来源相同但是用途不同的特点。数据划?#21046;?#26469;的时候留意可以合并的数据来?#30784;?#25968;据的输入时候还会进行特定变化再输入的情况。

  

  *上图中标黄以及标蓝的数据是重复使用的数据部分数据没有在图中?#20801;M?#35746;单数据输入至生成仓库交接单以及订单数据、供应商信息、异常订单信息输入至上传合同的链?#29992;?#26377;在图中?#20801;M?/font>

  由图中可见订单数据以及异常订单数据是重复使用的数据订单数据重复使用于更新订单进度、生成仓库交接单意味着两个任务之间是存在联系并可以进行部分合并即完成生成仓库交接单的时候完成部分更新订单进度的任务下面把这两个任务以及处理异常订单单独拿出来进行分析。

  

  由上图中可以看出处理异常订单的任务数据取自异常订单数据更新订单进度需要的数据也是需要异常订单数据所以这两部分的任务可以认为有合并?#30446;?#33021;合并通常为结合于相同界面?#20801;G?#21512;并结果为在处理异常订单的同时修改订单进度状态的数据。同理生成仓库交接单的时候也是会有部分重叠故也可以考虑进行合并任务。针对数据进行考虑后任务可以进行合并操作?#30446;?#34892;性也分析出?#30784;?#20998;析结果如下

  处理异常订单页面(更新订单进度、处理异常订单)

  生成仓库交接单(更新订单进度、生成仓库交接单)

  

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

  总结?#33322;?#24403;前的设计范围内的数据进行深入的调研以及思考在此基础上确立用户群体并确定数据的矩阵然后设计对应的任务再者是确定类。能较为有效地完?#19978;?#32479;设计层面的分析工作并能规范用户群体需要执行的任务以及任务的价值。总体?#27492;?#23646;于比较清晰的设计思路。

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

  数据型B端需求文档设计理念由于数据型B端设计理念突出的是以数据为重点为了更好地突出这个特点对应需求文档的设计以及格式需要结合一起进行调整。在?#24471;?#35774;计理念前需要对系统有整体的认识个人理解的B端系统无不可以分为三个部分数据、控件、界面。系统作为一个事物数据控制着系统的内容、控件控制着数据的内容、界面包含着控件以及数据。将系统作这般拆解的意义在于需要将原来文本化的需求文档转化为可?#21592;?#31995;统记录并且较为清晰地?#20174;?#36923;辑的需求文档?#21592;?#26356;好地结合新设计理念。其中一个较为重要的原则是需要将所有逻辑以及所有涉及的数据标签化这样才能?#26032;?#36753;利用计算机去快速检索并?#35813;?#21270;?#20801;M?/font>

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

  系统以及数据逻辑的?#35813;?#21270;展示。

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

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

  文?#21040;?#38754;化设计。?#22870;?#23545;于历史需求文档以及逻辑的查看。

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

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

  数据流转、数据限制以及数据逻辑标签化?#22870;?#26597;看数据的流转以及运用方式。

  整体标签化设计与规划?#22870;?#26085;后查看与梳理。

  与数据型B端设计原则结合形成有机整体提高系统?#30446;?#35774;计性与清晰度。

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

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

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

  实现系统逻辑以及数据流转的清晰度?#22870;?#26085;后系统的升级与优化。

  ?#22870;?#25805;作人员理解系统结构有助于提高需求的质量。

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

  前期转换?#35759;?#36739;大因为数据型B端需求文档的编写对于目前需求文档的编写会更有规则性目前需求文档的编写门槛?#31995;諭?/font>

  数据型B端需求文档的改动?#35759;?#20250;大于目前需求文档因为编写的复?#26377;?#22686;加导致文档中的逻辑/页签描述增?#21360;?#21518;期改动较复?#21360;?/font>

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

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

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

  

  这个表的形式类似于数据库一般?#27492;担?#31995;统中展示的值从数据库中取值而?#30784;?#34920;头为数据库的数据名称。表头下面的内容为组成这一条数据的数据组成。例如需要展示金刚负责的订单的时候只需要取订单跟进人为金刚的数据?#25335;?#34892;汇总展示即可。

  3.3.1 数据

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

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

  逻辑运算符号运算符号包括了且、或、满足、()四个符号与^表 ̄、^值 ̄、^大于/小于/等于等 ̄一起运用于逻辑表达。其中^且 ̄表达的意思是满足两个条件、^或 ̄表达的意思是任意满足其中一个条件、^满足 ̄为动词表示满足的条件、^() ̄的意思为条件括号内代表的是数值或其他的条件。例如此录入 ̄^数值 ̄^条件限制 ̄^小于 ̄(^满足 ̄^采购表中 ̄^采?#33322;?#39069;值 ̄^小于 ̄^5 ̄)的^采购表中 ̄^采?#33322;?#39069;值 ̄^汇总量?#20445;?#34920;达的意思是此空格的数值填写的限制为填写的数值小于采购表中采?#33322;?#39069;值小于5的采?#33322;?#39069;值汇总数值。

  *例子中为了凸?#21592;?#31614;特意用^ ̄代表一个标签。

  数值运算符数值运算符针对的是数值的运算因为单单从逻辑运算会导致系统数据描述的不完善。数值运算符能较好地解决这个问题。例如^录入 ̄^数值 ̄^条件限制 ̄^小于 ̄(^满足 ̄^采购表中 ̄^采?#33322;?#39069;值 ̄^小于 ̄^5 ̄)的^采购表中 ̄^采?#33322;?#39069;值 ̄^汇总量 ̄^‖ ̄^5?#20445;?#34920;达的意思是此空格的数值填写的限制为填写的数值小于采购表中采?#33322;?#39069;值小于5的采?#33322;?#39069;值汇总数的五分之一。

  *例子中为了凸?#21592;?#31614;特意用^ ̄代表一个标签。

  3.3.1.1 数据类型

  针对数据方面的描述可以分为以下三个类型去进行^录入格式 ̄、^文本属?#21592;?#21270; ̄、^默认数据 ̄三种代表了描述系统中所有数据的展示、限制、?#21015;?#31561;控制方法。由于新需求设计文档采用的是标签化的表达方式所以以下针对数据类型的描述内容也是根据标签去进行表达。

  录入格式针对录入系统的数据所作出的数据限制、指?#23478;?#21450;规范。其中涉及到运用逻辑运算符号以及数学运算符号辅助描述录入格式中的限制以及规范。从而达到通过标签化描述清楚录入格式这个数据类型的目的。

  文本属?#21592;?#21270;针对数据的形状以及样?#22870;?#21270;作出限制、指?#23478;?#21450;规范。其中涉及到运用逻辑运算符号以及数学运算符号辅助描述颜色形状变化中的限制以及规范。从而达到通过标签化描述清楚文本属?#21592;?#21270;这个数据类型的目的。

  数据默认针对数据的数值大小以及取值作出限制、指?#23478;?#21450;规范。其中涉及到运用逻辑运算符号以及数学运算符号辅助描述数据默认中的限制以及规范。从而达到通过标签化描述清楚数据默认这个数据类型的目的。

  (1)录入格式!!类型一

  对应可选内容数值、文本、下拉框。对应三种录入格式。每一?#25351;?#24335;都会有不同标签组成的限制或者引导。实现对于数据录入的文档型描述转化为标签化描述。

  

  录入格式解读标签一下面细分为三个标签分别是^数值 ̄、^下拉框 ̄、^文本?#20445;?#23545;应不同的输入框以及逻辑表达这里只对数?#21040;?#34892;限制并不对数据的作用以及数据的流转进行描述数据的流转以及作用的描述在控件中会提及。

  图中描述的是只是控制的例子并不是所有控制都是如此具体限制逻辑可以较为?#26434;?#21435;编?#30784;?#31867;似于数学中的符号可以将数学中的符号只有组合表达不同的公式。

  录入格式中数值限制主要分为两种限制模式一种为源数据限制意思为只是简单地受数据的数?#31561;?#36827;行限制。另外一种为条件限制意思为在数值的基础上加入条件去进行限制。条件限制的描述是较为多变需要加入逻辑运算符以及数值运算符去辅助描述这个限制。

  例如粉红色的例子中的第一条表达的意思为取值范围为数据表中的某一个数据值。

  (2)文本属?#21592;?#21270;!!类型二

  系统中数据的颜色形状会根据对应数值内容的变化而变化。所以这部分描述的特点为数据的展示方式。

  

  文本属?#21592;?#21270;解读文本属?#21592;?#21270;下面细分为两个变化分别是^源数据导致变化 ̄、^其他数据导致变化?#20445;?#23545;应不同的变化形式以及变化原因。其中针?#20801;?#38388;这一变化单独拿出来因为时间是系统本身具备的?#21592;?#37327;属于特殊的?#21592;?#37327;。那么关于颜色形状变化主要为四种类型。

  这里仅对数据的变化导致的变动进行描述。文本属?#21592;?#21270;的描述里面同样需要加入逻辑运算符以及数值运算符去描述不同条件下颜色形状的变化。由于变化的结果属于较难描述的情况所以这部分大?#36335;?#20026;图形变化、颜色变化、文本变化。(数?#24403;?#21270;放在数据默认这个版块介绍)

  其中下图红框所示的为导致的变化

  

  *红框的意思为^导致 ̄在颜色形状变化中可以作为一个单独的标签也可以不描述。

  (3)数据默认!!类型三

  数据默认里面包含的是数据的展示内容以及一些含有逻辑计算后的数据展示内容类型。主要描述的是数据应该如何在系统中展示。

  

  数据默认解读数据默认下面细分为两个标签分别是^源数据默认 ̄、^关联数据默认?#20445;?#26681;据不同的默认数?#36947;?#28304;数据作为区分。源数据默认默认的数?#31561;?#20540;判断标准来源于同一个数据表或者固定数值例如采购单的数量汇总取值的是采购单表的当前采购单个数。关联数据默认默认的数?#31561;?#20540;判断标准来源于另外一个数据表并且可能在判断时候加入条件限制。例一取值高级客户的订单数其中高级客户的判断标准来源于客户的数据表中。例二化学工?#35752;?#30340;流量会因为其他因素导致波动但是依然需要将其参数调整到正常的数值。另外一些数据会因为其他数据的变动导致变动。例三生产中的物料如果使用较多的话那么采购单上的采购数量就需要对应的增加或者新增采购单。

  3.3.1.2 数据类型总结

  (1)数据型B端需求文档设计中的数据分为三类此录入格式 ̄、?#25226;?#33394;形状变化 ̄、^数据默认 ̄分别对应数据在系统中的录入方式、形状变动方式以及数据的展示方式。基本涵盖了目前文字的需求文档中关于数据的描述。

  (2)数据型B端需求文档设计中关于数据的描述主要使用逻辑运算符、数值运算符、表、值四种描述方式结合表达数据在系统中的情况。三种类型中的数据条件的设定较为灵活上文只是对这三种数据的类型进行了描述情况的划分和举例其中数值运算符号以及逻辑运算符号的使用参考数学中的数学符号表达。新需求文档设计中关于数据的描述基本能达到文本类文档功能并体现了新需求文档设计中标签化、?#35813;?#21270;、扁?#20132;?#30340;特点。

  (3)数据型B端需求设计文档中的数据类型的设计原则是结合上文提及的数据型B端设计理念中以数据为重的系统设计理念进行展开数据型B端设计理念以数据为重数据型B端需求设计文档的数据类型也是可以进行标签化描述并结合了数据库的取值方法。故在?#23548;使?#20316;中产生以下两个好处

  系统设计文档中新增或者删减的某一类数据会较为清晰地呈现出来其他变化关系并能较为明?#36820;?#30693;道数据的产生者以及产生速度和处理速度为运营、需求工作人员提供了较为清晰的系统脉络。

  为需求的设计提供了一定的?#23548;?#20381;据?#22870;?#38656;求人员在设计需求的时候提供基本的讨论内容以及讨论界限。

  3.3.2 控件

  数据型B端需求设计文档中的第二部分描述内容为控件。控件的类型按照功能可以分为以下三个大类与数据有关?#30446;?#20214;类、与界面相关?#30446;?#20214;类、控件的形状与其中含有的内容。

  与数据有关?#30446;?#20214;类主要是描述控件对于数据?#30446;?#21046;关系含有?#21543;?#25104; ̄、?#21543;境 ̄、?#32534;辑 ̄三个对数据控制的方法生成数据型按钮的目的是将用户群体填写的数据通过操作生成数据型按钮存储到数据库中增加的内容为数据库中的一条数据。编辑数据型按钮的目的是将数据库中的一条或多条数据中的某一个数?#21040;?#34892;修改。这里的?#22659;?#26159;指对于数据库中整条数据的?#22659;?#25110;者是修改状态已达到?#22659;?#30340;目的的数据控制方法。

  与界面相关?#30446;?#20214;类主要描述的是控件对于界面的操控作用含有^打开界面 ̄、^关闭界面 ̄、^展开或?#39038;?#30028;面 ̄、^流转并打开界面 ̄四种对于界面?#30446;?#21046;方法打开界面是在当前界面中打开一个界面即二级界面或者三级界面等与流转并打开界面不同流转并打开界面是另外开?#23478;?#20010;一级界面的意思虽然两者都有打开界面的意思。关闭界面的意思为关闭当前界面的意思一般为取消或者关闭按钮。展开或?#39038;?#30028;面的意思是针对目前的界面进行展开或者?#39038;?#20027;要是菜单型的界面中这种控件较为常见。

  控件的形状与其中含有的内容主要针对控件的形状与内容进行描述控件的形状部分因为属于图形的?#20498;剩?#25152;以还是需要使用图形进行描述。控件的内容属于数据默认的一种上文有提及数据的体?#22336;?#24335;主要体现在数据默认中控件中的较为简单的内容为固定文本的?#20801;G?#36824;有一种是控件的内容是会随着关联数据的变化而改变。所以在这里控件中的内容可以描述为数据默认的方式去展示控件中的内容。

  (1)与数据有关?#30446;?#20214;类简介

  生成数据型控件!!类型一

  生成数据分为跨表型生成数据、创建型生成数据。跨表型生成数据的意思将原有的一个表的数据进行整合后生成另外一个表的数据。创建型生成数据的意思将用户群体录入的在自然环境中数据整合后生成一个表中的数据。

  

  生成数据型控件解读生成数据型?#30446;?#20214;描述逻辑中描述的重点是录入或需要的数据与生成的数据之间的对接关系以及数据与编号之间的关系。生成数据里面隐含的一个意思是需要对数据库中的数据进行编号一般?#27492;担?#25968;据库的主键(即类的命名)是在数据库中有一个对应的编号。例如采购单的数据库中一般?#27492;?#37117;有针对采购单个数进行编号。两种关系中需要先阐明的关系是数据与编号之间的对应关系对应的关系处理出来后然后就?#21069;?#21407;数据中的部分转换为需要生成的数据表中对应的部分例如通过采购单数据生成支付账单数据时将采购单中的金额字段数值汇总后转化为支付单中的应付金额字段。

  同样?#27169;?#28041;及到数值转换变化依然需要使用到逻辑运算符号以及数学运算符号来辅助描述数值之间的数学与逻辑关系。

  总体?#27492;担?#27492;类控件的核心为不同数据表之间的数值对应关系、新数据表中的编号规则命名以及产生数据的来?#30784;?/font>

  2)编辑数据型控件!!类型二

  编辑数据型控件主要是对于当前操作数据中的其他数据进行修?#27169;?#20363;如编辑修改采购单中的预定量。这种是针对到采购单数据库中的预定?#25335;?#34892;的数量修改。分为批量修改、单条数据修改、混合型修改。这种修改因为是涉及到数据的变动需要引入数据的运算逻辑方面。

  

  编辑数据型控件解读编辑数据型?#30446;?#20214;描述逻辑中需要描述的是编辑页面中的录入的数据与数据库中数据之间的对接关系、录入数据与写入数据库的数据之间的关系一般?#27492;担?#24405;入数据与数据库之间的数据关系为一一对应。录入数据和写入数据库的数据之间的关系同样也是一一对应的关系。例如修改会员卡中的会员电话号码信息编辑数据的时候修改会对应到某一个会员的基础信息中并不会更新到其他会员中。如果是修改会员卡中的等级操作可以将消?#30740;?#24687;录入并判断金额后修改对应的会员等级后一个例子属于判断录入数据后对等级数据进行的修改。

  3)?#22659;?#25968;据型控件!!类型三

  ?#22659;?#25968;据型控件主要是对于当前操作数据中的数据进行?#22659;?#21253;括对主数据的?#22659;?#20197;及对数据下面的明细数据的?#22659;?#20363;如?#22659;?#35746;单明细?#22659;?#30340;是订单数据库中的一条数据并不是将这个采购单?#22659;?#20363;如?#22659;?#35746;单?#22659;?#30340;是订单数据库中的一条数据不只是?#22659;?#20854;中的某一个明细而是所有属于这个采购单的所有明细。两种类型控件的不一致可以大致理解为是否?#22659;?#25972;个主键的数据。

  

  ?#22659;?#25968;据型控件解读对?#22659;?#25968;据型控件逻辑进行描述其中主数据?#22659;?#22411;其操作特点为是否为选项型?#22659;?#25968;据(即?#22659;?#25152;选择的数据)以及是否针对当前操作的数据进行?#22659;?#26126;细型数据?#22659;?#25551;述的是当前被?#22659;?#25968;据与主键数据之间的关系以?#21543;境?#30340;数据位置(位于哪一个数据表)。

  *?#22659;?#20027;数据可以不一定为真的?#22659;?#24403;前数据也可以通过设置数据的状态使得当前界面不?#20801;?#27492;数据达到类似于?#22659;?#30340;功能?#22870;?#26085;后对数据进行维护。此方法不属于?#22659;?#25968;据型控件属于编辑数据型控件因为修改的内容为对应数据的状态。

  (2)与界面相关?#30446;?#20214;类

  控件的作用中对于界面?#30446;?#21046;方式为以下五种^打开界面 ̄、^关闭界面 ̄、^展开或?#39038;?#30028;面 ̄、^流转并打开界面 ̄、^清除界面数据 ̄

  打开界面打开对应的界面。

  关闭界面关闭对应的界面。

  展开或?#39038;?#30028;面?#21592;?#26469;隐藏的界面的?#20801;?#20869;容以及形状进行改变。

  流转并打开界面打开对应界面并将数据进行流转与生成跨表数据类型?#30446;?#20214;类似流转并打开界面更偏重描述打开对应界面。

  清除界面数据对界面中的数据进行清除操作并不影响数据库中的数据。

  

  与界面相关?#30446;?#20214;类解读与界面相关?#30446;?#20214;类主要描述的是控件对于界面的操控作用含有^打开界面 ̄、^关闭界面 ̄、^展开或?#39038;?#30028;面 ̄、^流转并打开界面 ̄、^清除界面数据 ̄五种对于界面?#30446;?#21046;方法分别对应界面的形?#30784;?#30028;面的出现与关闭、界面内容三个界面内容?#30446;?#21046;。因为这部分较为简单所以这里不展开描述。

  (3)控件的形状与其中含有的内容

  这里只针对控件中的内容进行较为详细的描述因为控件的形状难以用文字进行描述。

  

  控件的形状与其中含有的内容解读控件的内容属于数据默认的一种上文有提及数据的体?#22336;?#24335;主要体现在数据默认中控件中的较为简单的内容为固定文本的?#20801;G?#36824;有一种是控件的内容是会随着关联数据的变化而改变。所以在这里控件中的内容可以描述为数据默认的方式去展示控件中的内容并加入逻辑运算符号以及数学运算符号。

  *数据默认中的逻辑运算符号以及数学运算符号都是属于控件内容中此处没有体现出?#30784;?/font>

  总结控件在新需求文档设计中以及系统中的意思是一致?#27169;?#25511;件属于执行当前命令的意思命令对于系统?#27492;?#23601;是实行某一种类型的系统修?#27169;?#36890;常用户层面的系统修改为修改数据不能达到管理员级别的修?#27169;?#20363;如修改页面中的页面宽度。所以控件在新需求文档中简化为对界面、数据这两个用户可以达到的系统权限进行控制。数据?#36335;?#20026;生成、编辑、?#22659;?#19977;个对于数据?#30446;?#21046;这里面?#30446;?#21046;只是针对已有数据库中的主数据或数据的明细进行?#30446;?#21046;并不能达到创建数据库以及改变数据库中的数据固有关系的权限。对于用户层面的需求规划当前的新需求文档可以达到足够应付的级别。同理界面也是在管理员在处理好界面样式内容的情况用户对界面进行调用并不能直接对界面内容进行修?#27169;?#25925;当前的新需求文档可以达到足够应付的级别。

  3.3.3 界面

  数据型B端需求文档设计中的界面可以理解为数值的展示、生成、清除的媒介。不同的界面之所以不同因为实现的功能不一样。在用户角度?#27492;担?#19981;同的界面代表了不同的功能和使用者。界面作为一个承接用户?#23548;?#20219;务与系统功能对接的事物在数据型B端系统设计理念中也是如此接通的是数据型B端系统设计理念以及数据型B端需求文档设计理念在此基础上衍生出数据的分析。上述?#30446;?#20214;数?#36947;?#19981;开界面界面作为一个载体承载的是控件(功能)、数据(内容)。三者为一体构成了系统。

  界面不像控件以及数据那样承担其他功能对于功能主要为承载控件和数据的界面?#27492;担?#25551;述界面主要为其中包含?#30446;?#20214;以及数据。在此之前首先要做的是对控件进行编码以及对数据进行划分(可取数据库的划分)

  

  总结数据、控件、界面三位一体地支持系统的运行所以通过这个思路也可从这三个方面对系统进行描述。这个就是整个数据型B端需求文档设计的主体思路的一部分另外一部分是基于数据型B端系统设计理念!!以数据为主要出发点作为主体思路。?#38142;?#30456;信读者应该知道数据型B端需求文档设计方法与当前较为主流的需求文档不一样的地方在于将文本化的表达通过可?#21592;?#31614;化的逻辑以及描述体现出来达到系统逻辑扁?#20132;?#30340;目标类似于公司扁?#20132;?#31649;理系统扁?#20132;?#31649;理有利于决策层较为清晰并?#22870;?#22320;实行系统转变。

  3.4 数据型B端需求文档设计与数据型B端设计理念的结合

  3.4.1 数据型B端系统设计理念回顾与深入

  数据型B端系统设计理念将设计的主体划分为四个类、数据、用户群体、任务。数据型B端需求设计文?#21040;?#31995;统分为数据、控件、界面三个部分。下图阐述的是数据型B端系统设计理念以及数据型B端需求设计文档之间的对应关系。

  

  如上图所示将两部分设计元素放于图上图中橘红色的线描述的是一个元素对于另外一个元素?#30446;?#21046;箭头开始的元素对于箭头末尾的元素进行控制。图?#26032;?#33394;箭头描述的是类?#27973;?#36733;数据的载体。例如用户群体控制界面、用户群体通过界面或控件控制数据。有了这个对应的关系我们就能较为清晰地绘画系统的设计?#23478;?#21450;系统内部的结构图。并通过以上关系模型构建两图之间的联系。

  

  上图为餐厅系统设计图。图?#26032;?#33394;为输出的数据黄色为输入的数据。其中输出数据保证了其每一个数据都有对应的流向(流向在图中没有表达出来)各用户群体的责任以及所获得的数据较为清晰地展现出?#30784;?#20445;证每一步操作?#21363;?#22312;对应的意义。在此基础上延伸出系统的内部设计图。

  *图中没有画出类。

  针对每一种数据可以设计出对应的界面例如需要创建一个客户输入菜单的界面。这个界面需要包括各?#20284;返?#24403;前制作情况各?#20284;返?#21097;余量。以及一个个人查看?#20284;返?#36335;径(页面)?#20801;?#30340;内容为当前订单的制作情况以及排队情况。后期还可以在此图上增加对应的设计升级情况。

  

  客户部分的系统的系统内?#25335;?#26500;图如上图可以较为清晰地看出客户主要为两个界面接受的数据为三个输出的数据为订单数据。对于整个系统中的数据、控件、界面都能较为清晰地?#20801;G?#20197;及对应的逻辑也是可以较为清楚地进行描述。?#26723;?#26085;后系统的维护?#35759;取?/font>

  读者可以发现系统内?#25335;?#26500;?#23478;?#21450;系统设计图中任务以及界面可以结合一起并根据任务内容对界面中的细节进行检查。例如客户界面中的界面一对应客户任务中的菜单数据清单、制作情况数据。

  简单?#27492;担?#31995;统设计图可以理解为普通人员对于系统的意见、系统内?#25335;?#26500;为专业的需求人员根据意见来制作的系统需求。两者通过界面!!任务进行结合并提供一个可检查可升级的设计总图。

  3.5 数据型B端设计理念与UML设计理念简单回顾

  数据型B端设计理念设计理念以数据为出发点在数据的基础上建立任务并分配给对应的用户群体。并在任务的基础上去设计对应的界面以及相关输出和输入的数据。这个就是新设计理念的核心部分。

  UML设计理念以当前流程为出发点将每一步操作的细节、限制、关联通过操作人的表述去进行描绘并在此基础上建立对应的界面以及系统。

  两种理念最大的区别为数据型B端设计理念是基于数据的基础上面是以系统的目标为基础去进行的。UML设计理念是基于目前流程以及操作的基础上去建立系统过?#35752;?#20250;实现系统的目标但设计的目的还是以在系统上实现?#36136;?#20013;的操作以及?#36136;?#20013;的流程为目标。

  4.1 数据型B端设计的后续优化

  相信读者在阅读以上关于数据型B端设计的相关内容后对于数据型B端的设计理念以及运用有了初步的认识接下来讲解的是数据型B端设计建立后针对数据型B端设计出来的系统进行的优化方法。

  4.1.1 数据类的优化

  数据类的优化是以系统中的数据为出发点去进行的优化手段分为以下5个优化点。

  (1)合并型优化

  将当前数据的生成界面或者生成渠道进行合并。

  (2)简化型优化

  排查数据的流转方向将没有流转目标界面的数据进行简化

  人工排查数据的使用情况进行数据的优化。

  (3)扩展型优化

  将当前较为主要的用户群体需要的数据追根溯源追查相关联的数据并确认是否需要使用从而达到通过数据扩展业务。例如餐厅顾客的点菜信息与厨房的做菜信息存在关联所以可以考虑在餐厅顾客页面加入做菜进度。

  (4)用户数据优化

  将当前用户群体看到的数据进行优化以及整合将任务相同程度?#32454;?#30340;进行合并。例如?#33322;?#36134;的时候?#20801;?#24403;前用户的vip等级以及相关可以?#19968;?#30340;产品。?#22870;?#29992;户群体一次性处理任务。

  (5)数据深度优化

  对于数据产生的本?#24335;?#34892;思考通过结合?#36136;?#20013;的?#38469;?#25163;段以及解决方法使得数据产生的方法变得简介例如引有自动点数机减少?#23548;?#31649;理人员点数的任务。

  4.1.2 系统层级的优化

  数据类的优化是以系统中的数据为出发点去进行的优化手段分为以下3个优化点。

  1)系统方向优化监督筛查每一个数据是否配合公司的目标去进行优化。例如公司的目标是提高物流速度快递员的手持上是否出现到达时间的倒计时是否对于每一个用户群体优化公司目标。

  2)系统总体数据报表型优化对于重点岗位筛查是否必要提供的数据都能提供到。是否有对应的报表给管理人员展示。

  3)用户群体服务体验优化简化用户群体的任务数将用户分流并专人专用。

  5.1 主流B端设计简介

  主流B端设计元素主要为流程、类、数据、人、UML的需求设计以及需求的调研很大程度上是建立在流程的基础上调研用户目前的操作流程推导出系统的人使用到的数据并通过数据、数据限制、操作的先后顺序梳理成各种状态图、流程图等然后进行系统方面的设计。

  5.1.1 主流B端设计元素简单划分

  (1)流程

  流程在UML中有较为重要的地位一切的调研与分析都是基于流程上进行一般的流程可以归纳为人在某一个?#24405;?#20013;应该做什么应该有些什么步骤。例如付款流程扫描各商品一维码★点击付款★确?#32454;?#27454;方式★进行不同的付款操作★点击收款结束。

  示例图如下

  

  图中是付款流程的主干部分对于特殊情况的描述以及一些细节?#30446;?#30011;在UML设计理念中需要不同的图去进行表达。例如判断VIP用户的时候对应付款的金额会产生改变。这个就是下面需要说到的数据方面的问题在主流B端设计中流程是建立系统的基础。

  (2)状态图

  针对数据不同引起的流程不一致或者其他数据的改变叫做状态图。

  (3)类

  类在主流B端设计中的含义与在新设计原则中的含义是基本一致?#27169;?#37117;是描述?#23548;?#20107;物在系统中的位置例如付款账单中付款时间收款人收款金额等数据都是归属于付款账单这一个类中属于?#36136;?#20013;事物在系统上的投影。

  (4)用户

  用户在主流B端设计中是?#38405;?#22836;人去表达意思是执行这些流程的用户。

  5.2 主流B端设计文档的组成

  目前主流B端设计文档的组成为一、文字?#24471;?#22686;加或修改部分的内容的取值以及逻辑。二、图形辅助?#24471;?#20462;改的内容的形状以及位置。这两部分组成了目前主流设计文档。并添加编号保存?#26009;?#32479;中作为日后可以查询的依据。

  由于文档的复?#26377;?#20197;及阅?#21015;?#35201;时间较长导致很多需求人员在编写当前需求文档的时候没有查询以往的需求文档?#20381;?#21490;需求文档的描述并非是当前系统的逻辑以及数据结构会存在一定程度上的误差。以上为主流B端设计文档的简述。

  5.3 主流B端设计文档与主流B端设计理念的结合

  主流B端设计文档与主流B端设计理念的结合在于主流B端设计文?#30340;?#22312;流程业务模型建立后对系统语言和?#36136;?#27169;型进行关联这个关联关系需要需求人员在整理模型后设计对应的界面或者数据去承接这个模型往往这个模型的完整程度以及设计确定了系统的设计方法。因为设计文档中的内容是根据模型的建立或者修改得出模型进行了改动系统对应的部分需要作出对应的修改以适应新的业务流程模型。

  5.4 主流B端设计文档与主流B端设计理念的优劣

  主流B端文档因为其偏向于文本的描述逻辑方式在编写方面较为?#22870;磽?#35821;言的选择也是较为?#26434;稗?#36798;到可?#21592;?#36798;需求中描述的意思即可。可以说?#22870;允?#20027;流B端需求文档的一大优势。

  主流B端文档的劣势在于其难?#21592;?#20877;次运用属于一次性的文档只是适合当前系统的版本在系统有较多版本的时候历史需求文?#21040;?#23569;机会?#29615;?#38405;。多次迭代的系统由于需求人员的变动其逻辑变得难以查询或通过程序开发员去进行查询。方法较为麻烦。同理逻辑的查询在目前需求文档中也是由于其文本化描述的特?#21592;?#24471;难以看出其中的逻辑。

  主流B端设计文档的现象可以说是在UML设计理念上出现?#27169;?#22240;为UML设计模型不能转化为需求文档的内容所以需要通过人工将模型转化为系统语言。两者的优势在于建立模型较为简便并?#23376;?#36716;化在系统较为简单的时候两者起到的作用在系统前期要优于新系统设计理念。

  在系统后期版本迭代一定程度后系统中的逻辑会变得更为复杂并且由于系统的改变并不一定来自同一个人员所以系统中的逻辑会变得不清晰不同模块之间的隔?#19968;?#21152;大。系统的复?#26377;?#20250;指数级增长。

  6.1 总结

  本文总结了当前的B端设计理念的优劣并在此基础上衍生出个人的另外一种新的B端设计理念!!数据型B端设计理念的想法以及提出关于当前需求文档的改善方案!!数据型B端需求设计文档。期望借助这种数据型B端设计理念解决当前主流B端设计导致的常见问题以及主流B端需求文档导致的常见问题。

  本文也阐述了基于数据型B端设计理念重新设计的模型划分以及数据型B端需求设计文档中的编写规则。解释了由本人所想的数据型B端设计理念的基本构成。

  总体?#27492;?#26412;文只是一个B端产品设计的方向。希望建立在数据上的设计文?#30340;?#35299;决目前B端产品遇到的需求上的问题。

  希望能为广大的B端设计工作者、B端需求人员带来一些有益的思考同时也欢迎产品经理朋友或者希望从事产品经理行业的朋友指点。


您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|网络赚钱

快速回复 返回顶部 返回列表
病廉噴匯僉励販伊 皇马埃瓦尔集锦 紐櫛針04堝器音棲歎 扮扮科恠米夕蛍裂罷周 浪牽削定窮徨 pt窮徨嗄簒蝕薩 唖櫛唖砕旋vs錬性櫛徒笥圓霞 ac致声鱗杵坪帽嶄魁弌頃 屯才碕怺麼魁仇峽 鴻廉11僉5蝕襲恠米 俳櫛廉vs凧廓