国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

本文總結了當前的B端設計理念的優(yōu)劣并在此基礎上衍生出個人的另外一種新的B端設計理念；也闡述了基于數(shù)據(jù)型B端設計理念重新設計的模型劃分以及數(shù)據(jù)型B端需求設計文檔中的編寫規(guī)則。

本文目錄如下：

1.1 B端設計原理探討

1.2 當前主流B端設計理念的問題探討

1.2.1 數(shù)據(jù)型B端設計理念

2.1 數(shù)據(jù)型B端設計元素

2.1.1 數(shù)據(jù)型B端設計元素簡介

2.2數(shù)據(jù)型B端各設計元素間的關聯(lián)關系

2.2.1 數(shù)據(jù)型B端各設計元素間的關聯(lián)關系解讀

2.2.2 設計與案例

3.1 數(shù)據(jù)型B端需求設計文檔理念

3.2 數(shù)據(jù)型B端需求設計文檔的優(yōu)劣

3.3 數(shù)據(jù)型B端需求設計文檔的劃分

3.3.1 數(shù)據(jù)

3.3.2 控件

3.3.3 界面

3.4 數(shù)據(jù)型B端需求設計文檔與數(shù)據(jù)型B端設計理念的結合

3.4.1 數(shù)據(jù)型B端系統(tǒng)設計理念回顧與深入

3.5?數(shù)據(jù)型B端設計理念與UML設計理念簡單回顧

4.1?數(shù)據(jù)型B端設計的后續(xù)優(yōu)化

4.1.1數(shù)據(jù)類的優(yōu)化

4.1.2系統(tǒng)層級的優(yōu)化

5.1主流B端設計理念簡介

5.1.1主流B端設計元素簡單劃分

5.2主流B端設計文檔的組成

5.3主流B端設計文檔與主流B端設計理念的結合

5.4主流B端設計文檔與主流B端設計理念的優(yōu)劣

6.1總結

1.1 B端設計原理探討

請允許本人在這里淺顯地探討一下系統(tǒng)的本質，系統(tǒng)的本質不同人會有不同的解讀，有人會認為系統(tǒng)是協(xié)助進行管理流程、監(jiān)控流程，從而實現(xiàn)流程的標準化，有人會認為系統(tǒng)是一個全方位的功能，對于企業(yè)文化、企業(yè)管理、企業(yè)決策等有很大的作用等等，個人認為系統(tǒng)的作用需要在系統(tǒng)的本質上去確定下來，只有了解了事物的本質與規(guī)律才能較好地掌握事物、運作事物、看清楚事物

將系統(tǒng)作為一個事物看待并深入理解本質之后，個人認為系統(tǒng)的本質為數(shù)據(jù)，系統(tǒng)中的所有按鈕、操作、界面展示無一不是對數(shù)據(jù)的修改以及對數(shù)據(jù)的閱讀需要，人們所說的作用均建立于這點的基礎上去進行延伸。例如：人們認為的系統(tǒng)對企業(yè)文化、企業(yè)管理、企業(yè)決策起到作用，均建立于數(shù)據(jù)的設置、數(shù)據(jù)的整合并展示上去實現(xiàn)。數(shù)據(jù)可以說是一個系統(tǒng)的靈魂，需求乃至系統(tǒng)的功能無不通過對數(shù)據(jù)的改造和解讀產(chǎn)生，其余均為數(shù)據(jù)的左肩右臂，所以本文的數(shù)據(jù)型B端設計理論以及數(shù)據(jù)型B端需求設計文檔均基于數(shù)據(jù)圍繞展開。希望給讀者一種新的思考與思路。

1.2 當前主流B端設計理念的問題探討

一般B端設計理念或者主流設計理念（UML設計理念）是基于流程或用戶故事對用戶以及操作進行劃分產(chǎn)生系統(tǒng)的設計。但業(yè)務發(fā)展或者人員調整的問題往往會導致流程的變動以及操作的變動，使得這一設計理念后期會產(chǎn)生一系列的問題。

• 盲目性：系統(tǒng)的改進方案在系統(tǒng)的發(fā)展過程中容易失去計劃性。
• 復雜性：系統(tǒng)的復雜性會增加，導致很多操作無意義。
• 滯后性：基于流程的系統(tǒng)往往落后于業(yè)務，只是較為簡單地提供數(shù)據(jù)。

1.2.1 數(shù)據(jù)型B端設計理念

結合個人對于B端系統(tǒng)以及主流B端設計理念的理解，得出一點微小的思考結果——數(shù)據(jù)型B端設計。數(shù)據(jù)型B端設計理念將分為兩大部分進行闡述：數(shù)據(jù)型B端設計理念和數(shù)據(jù)型B端需求文檔設計。數(shù)據(jù)型B端設計理念可以理解為在數(shù)據(jù)為設計理念的基礎上整理用戶群體的需求并進行表達。數(shù)據(jù)型B端需求文檔設計可以理解為將用戶群體的需求結合數(shù)據(jù)型B端需求文檔這種新的表達方法去展示。通過數(shù)據(jù)型B端設計理念和數(shù)據(jù)型B端需求文檔設計這兩者的結合，從而達到系統(tǒng)扁平化以及數(shù)據(jù)的清晰化管理的目標。

1.2.1.1 數(shù)據(jù)型B端設計理念簡介

數(shù)據(jù)型B端設計理念包括數(shù)據(jù)、類、用戶群體、任務四大元素，通過對元素的重新劃分以及一些規(guī)則的制定體現(xiàn)數(shù)據(jù)型B端設計理念。這一部分的重點在于將系統(tǒng)設計需求劃分為四個元素并將劃分后的元素在數(shù)據(jù)為前提下進行有機組合從以明確各用戶群體的任務以及任務所需要的對應的數(shù)據(jù)。

1.2.1.2 數(shù)據(jù)型B端需求設計文檔簡介

數(shù)據(jù)型B端需求設計文檔包括需求文檔元素的劃分和整合。數(shù)據(jù)型B端需求設計文檔設計中有數(shù)據(jù)、控件、界面這三個元素。同樣的，數(shù)據(jù)型B端需求設計文檔的編寫規(guī)則也會相應地發(fā)生一些變化。和傳統(tǒng)需求文檔不同，數(shù)據(jù)型B端需求設計文檔類似于流程圖，將系統(tǒng)背后的邏輯進行扁平化顯示。數(shù)據(jù)型B端需求設計文檔的方法也有利于數(shù)據(jù)型B端設計理念進行任務量和難度進行規(guī)劃。

1.2.1.3 數(shù)據(jù)型B端設計理念的目標

數(shù)據(jù)型B端設計理念主要解決的問題為UML設計流程中以及一般B端系統(tǒng)設計流程中出現(xiàn)的問題。

• 調研時間過長，調研方向不明確，對于新需求人員需要重新調研。
• 系統(tǒng)設計過于依賴流程的改進，依賴他人意見，缺少較強的主觀能動性。
• 邏輯描述，因為文本的緣故導致一定程度上程序開發(fā)人員的誤解。
• 提高系統(tǒng)的易理解程度，降低需求人員設計需求的難度。

數(shù)據(jù)型B端設計理念主要達到的成績。

• 通過數(shù)據(jù)的整理與規(guī)劃推動業(yè)務部門進行發(fā)展。
• 優(yōu)化當前系統(tǒng)設計理念，提高需求人員的需求水平。
• 建立一定的系統(tǒng)判斷標準，減少人員的主觀判斷。

2.1 數(shù)據(jù)型B端設計元素

數(shù)據(jù)型B端系統(tǒng)設計理念設計的大致流程為，先明確需要的數(shù)據(jù)，在此基礎上確立用戶群體，并確定數(shù)據(jù)的特性，然后設計對應的任務，再者是確定類。在明確需要的數(shù)據(jù)時，需要站在公司的層面上進行思考。若僅僅從用戶的角度出發(fā)，很容易就落入根據(jù)流程去設計系統(tǒng)的思維模式上，不能達到去偽存真的目的。

2.1.1 數(shù)據(jù)型B端設計元素簡介

數(shù)據(jù)型B端設計理念，是將一個體系中的人員劃分為數(shù)據(jù)、類、用戶群體、任務四個部分。利用劃分后的元素重新表達用戶的需求。

2.1.1.1用戶群體

用戶群體：產(chǎn)生相同類型數(shù)據(jù)的用戶組成的群體，根據(jù)定義，即可在設計的時候將這一類用戶劃分出來組成一種用戶群體。一般地，一個崗位可稱為一個用戶群體。例如：倉庫文員即作為一類崗位也作為一個用戶群體。

2.1.1.2 類

類：承載從屬于類的數(shù)據(jù)的主體稱為類，類的劃分方法類似于數(shù)據(jù)庫中表的劃分，是區(qū)分現(xiàn)實或者系統(tǒng)中不同事物的方法，這個類的定義與目前系統(tǒng)設計中類的定義是一致的。例如：一個采購單中，采購單創(chuàng)建時間、采購明細對應的預定數(shù)、采購明細、供應商名稱這四個數(shù)據(jù)均從屬于采購單，可稱采購單為一個類。

2.1.1.3 數(shù)據(jù)

（1）數(shù)據(jù)

由用戶群體產(chǎn)生的或者接受的信息稱為數(shù)據(jù)。在數(shù)據(jù)型B端設計理念中，數(shù)據(jù)的處理由為重要，用戶的任務涉及到數(shù)據(jù)，用戶需要了解的信息通過數(shù)據(jù)去體現(xiàn)，用戶群體的操作邏輯體現(xiàn)在數(shù)據(jù)的限制和輸入輸出中。這里的數(shù)據(jù)不單單是系統(tǒng)上的數(shù)據(jù)，更包含自然環(huán)境中提供數(shù)據(jù)的事物與事件。忽略這種數(shù)據(jù)的重要性，往往會導致邏輯上行得通，但是實際需求與用戶情況產(chǎn)生出入。

（2）數(shù)據(jù)矩陣

通過數(shù)據(jù)的確定程度、對后續(xù)影響的程度兩個維度去進行判斷。獲得是否需要針對這些數(shù)據(jù)去進行后續(xù)的修改或者推送通知。

A類數(shù)據(jù)是錄入的不確定程度較高，對后續(xù)影響較大的數(shù)據(jù)。所以后續(xù)的用戶群體可以對其進行修改，或者修改A類的時候可以讓用戶群體及時知道。例如：餐廳的點菜數(shù)據(jù)屬于不確定性較高的數(shù)據(jù)，所以后續(xù)的環(huán)節(jié)允許經(jīng)理層可單獨修改客戶的下單數(shù)據(jù)且將修改信息推送給廚房工作人員。其他數(shù)據(jù)如此類推。

2.1.1.4 任務

任務：在不同數(shù)據(jù)組合的支持下去實現(xiàn)業(yè)務并產(chǎn)生數(shù)據(jù)稱為任務，每一個任務的組成元素為輸入數(shù)據(jù)、輸出數(shù)據(jù)（或輸出的實際事物），各種任務組成任務群，不同的用戶群體對應各自的任務群。任務元素的加入是為了更好地方便需求人員在運用這種方式分析時，比較貼近實際情況，方便從流程中分析出需求轉變?yōu)閺臄?shù)據(jù)中分析出需求，并賦予需求相關的實際意義。

用戶群體的任務可以分為單一型任務和復合型任務。

（1）單一型任務：明確所需要的數(shù)據(jù)，如果產(chǎn)生的數(shù)據(jù)較為單一并且與其他任務輸入和輸出的數(shù)據(jù)不重復稱為單一型任務。

（2）復合型任務：復合型任務與單一型任務不同點在于用戶群體接受一系列的多種類型的數(shù)據(jù)，并處理出不同的結果，下面給出復合型任務中兩種不同任務類型的數(shù)據(jù)劃分方法。

1.完全分離的多任務，適用于任務之間的獨立性較強，需要的數(shù)據(jù)重復度為零，對于這種多任務，劃分是簡單的，只需要重復單一型操作的數(shù)據(jù)劃分即可

*兩個任務數(shù)據(jù)重復度=（任務一需要的數(shù)據(jù)∩任務二需要的數(shù)據(jù)）/（任務一需要的數(shù)據(jù)+任務二需要的數(shù)據(jù)）

2.有一定交集的任務。存在任務重復度不為零。

2.2 數(shù)據(jù)型B端各設計元素間的關聯(lián)關系

數(shù)據(jù)型B端設計元素的運用的前提是對需要的數(shù)據(jù)進行充分的調研以及思考。并利用元素對整個范圍進行劃分以及整理。下面是對這些元素間的關聯(lián)關系解讀。

2.2.1 數(shù)據(jù)型B端設計元素的關聯(lián)關系解讀

UML設計中對于多個元素重新定義、劃分并闡述各元素的關聯(lián)關系，相較于UML的版本。突出以數(shù)據(jù)為基礎的新設計理念中的元素同樣存在著關聯(lián)關系，四種元素的組合圖如下：

如圖所示：任務是依賴在用戶群體上的，任務是依賴在數(shù)據(jù)的基礎上。根據(jù)用戶群體的需求以及公司發(fā)展需要去確立對應的數(shù)據(jù)，并用圖表的方式進行展示，使用Axure或者其他畫圖軟件進行繪制，方便日后檢索。

由于這種圖例是弱化實際流程，強調流程的本質——數(shù)據(jù)，進行調研的時候需要較為認真深入，并且認真記錄輸入輸出的數(shù)據(jù)和任務，這樣后面進行調整以及升級的時候，公司發(fā)展需要作出改變的時候可以對用戶群體的任務量，用戶群體的輸入輸出結果進行合理的數(shù)據(jù)分析并作出對應改造和判斷。由于新設計原則不同于UML以及一般的設計原則，建立于數(shù)據(jù)上的新設計原則對思維能力要求較強。

2.2.2設計與案例

以下設計案例根據(jù)單一型任務與復合型任務兩種類型進行闡述。

• 單一型任務中數(shù)據(jù)：財務中需要人員對賬單進行審核。在分析過后認為這個數(shù)據(jù)需要財務審核人員去產(chǎn)生。那么任務可以這樣分析。財務審核人員需要的數(shù)據(jù)為單據(jù)照片、付款金額、對應單據(jù)的入庫記錄等，這些數(shù)據(jù)不一定屬于同一類，這個時候需要對財務審核需要的數(shù)據(jù)進行設計，對于各數(shù)據(jù)屬性的理解，可以分為單據(jù)、入庫記錄兩類，兩類數(shù)據(jù)中的單據(jù)照片數(shù)據(jù)與付款金額為付款單據(jù)類，入庫數(shù)量，不合格數(shù)量為入庫記錄類，供應商賬號、供應商資質、供應商優(yōu)惠條件為供應商信息類，這樣分析即得出財務審核人員完成這個任務需要的數(shù)據(jù)類型以及設計出對應的類（或在原有的類中增加對應的數(shù)據(jù)），設計圖務必建于唯一的設計版圖中，方便他人查閱，和新需求設計時參考，如下圖所示：
• 
• 復合型任務中的數(shù)據(jù)：采購跟單需要生成倉庫的交接單，生成財務需要的支付賬單，更新訂單進度，處理異常訂單，這些操作中，都涉及到了入庫數(shù)量以及不合格數(shù)量的數(shù)據(jù)，所以這個用戶群體的任務進行劃分時需要區(qū)分數(shù)據(jù)來源相同，但是用途不同的特點。數(shù)據(jù)劃分起來的時候，留意可以合并的數(shù)據(jù)來源。數(shù)據(jù)的輸入時候還會進行特定變化再輸入的情況。

*上圖中標黃以及標藍的數(shù)據(jù)，是重復使用的數(shù)據(jù)，部分數(shù)據(jù)沒有在圖中顯示。訂單數(shù)據(jù)輸入至生成倉庫交接單，以及訂單數(shù)據(jù)、供應商信息、異常訂單信息輸入至上傳合同的鏈接沒有在圖中顯示。

由圖中可見訂單數(shù)據(jù)以及異常訂單數(shù)據(jù)是重復使用的數(shù)據(jù)，訂單數(shù)據(jù)重復使用于更新訂單進度、生成倉庫交接單，意味著兩個任務之間是存在聯(lián)系，并可以進行部分合并，即完成生成倉庫交接單的時候，完成部分更新訂單進度的任務，下面把這兩個任務以及處理異常訂單單獨拿出來進行分析。

由上圖中可以看出處理異常訂單的任務數(shù)據(jù)取自異常訂單數(shù)據(jù)，更新訂單進度需要的數(shù)據(jù)也是需要異常訂單數(shù)據(jù)，所以，這兩部分的任務可以認為有合并的可能，合并通常為結合于相同界面顯示，合并結果為在處理異常訂單的同時修改訂單進度狀態(tài)的數(shù)據(jù)。同理，生成倉庫交接單的時候也是會有部分重疊故也可以考慮進行合并任務。針對數(shù)據(jù)進行考慮后，任務可以進行合并操作的可行性也分析出來。分析結果如下：

• 處理異常訂單頁面（更新訂單進度、處理異常訂單）
• 生成倉庫交接單（更新訂單進度、生成倉庫交接單）

分析得出界面設計如上圖所示，設計方法實現(xiàn)了相同度較高的任務進行合并操作。并能增強和明確用戶群體的責任和任務內(nèi)容。原型圖合并的功能是更新訂單狀態(tài)以及處理異常訂單，這兩個任務重疊的部分可以一并處理。

總結：將當前的設計范圍內(nèi)的數(shù)據(jù)進行深入的調研以及思考，在此基礎上確立用戶群體，并確定數(shù)據(jù)的矩陣，然后設計對應的任務，再者是確定類。能較為有效地完成系統(tǒng)設計層面的分析工作，并能規(guī)范用戶群體需要執(zhí)行的任務以及任務的價值?？傮w來說屬于比較清晰的設計思路。

3.1數(shù)據(jù)型B端需求文檔設計理念

數(shù)據(jù)型B端需求文檔設計理念：由于數(shù)據(jù)型B端設計理念突出的是以數(shù)據(jù)為重點，為了更好地突出這個特點，對應需求文檔的設計以及格式需要結合一起進行調整。在說明設計理念前，需要對系統(tǒng)有整體的認識，個人理解的B端系統(tǒng)無不可以分為三個部分：數(shù)據(jù)、控件、界面。系統(tǒng)作為一個事物，數(shù)據(jù)控制著系統(tǒng)的內(nèi)容、控件控制著數(shù)據(jù)的內(nèi)容、界面包含著控件以及數(shù)據(jù)。將系統(tǒng)作這般拆解的意義在于需要將原來文本化的需求文檔轉化為可以被系統(tǒng)記錄并且較為清晰地反應邏輯的需求文檔以便更好地結合新設計理念。其中一個較為重要的原則是，需要將所有邏輯以及所有涉及的數(shù)據(jù)標簽化，這樣才能叫邏輯利用計算機去快速檢索并透明化顯示。

數(shù)據(jù)型B端需求文檔期望達到以下目標：

• 系統(tǒng)以及數(shù)據(jù)邏輯的透明化展示。
• 結合數(shù)據(jù)型B端設計理念，對系統(tǒng)進行更科學的管理。

數(shù)據(jù)型B端需求文檔具有以下特點：

• 文檔界面化設計。方便對于歷史需求文檔以及邏輯的查看。
• 標簽化表達界面，清楚每一個界面的流轉以及使用人員。
• 控件標簽化設置，清楚每一個控件的作用。
• 數(shù)據(jù)流轉、數(shù)據(jù)限制以及數(shù)據(jù)邏輯標簽化，方便查看數(shù)據(jù)的流轉以及運用方式。
• 整體標簽化設計與規(guī)劃，方便日后查看，與梳理。
• 與數(shù)據(jù)型B端設計原則結合，形成有機整體，提高系統(tǒng)的可設計性與清晰度。

數(shù)據(jù)型B端需求設計文檔設計中的原則是將系統(tǒng)中的數(shù)據(jù)標簽化，達成作為系統(tǒng)背后的系統(tǒng)的目標，有利于監(jiān)控目前的系統(tǒng)運行情況，并方便人員對系統(tǒng)進行規(guī)劃和梳理。以及與新設計理念形成一套體系，從系統(tǒng)需求設計開始直至需求文檔的編寫都可以在同一原則下進行和管理。

3.2 數(shù)據(jù)型B端需求文檔設計的優(yōu)劣

數(shù)據(jù)型B端需求文檔設計的好處在于：

1. 實現(xiàn)系統(tǒng)邏輯以及數(shù)據(jù)流轉的清晰度，方便日后系統(tǒng)的升級與優(yōu)化。
2. 方便操作人員理解系統(tǒng)結構，有助于提高需求的質量。

數(shù)據(jù)型B端需求文檔設計的壞處在于：

1. 前期轉換難度較大，因為數(shù)據(jù)型B端需求文檔的編寫對于目前需求文檔的編寫會更有規(guī)則性，目前需求文檔的編寫門檻較低。
2. 數(shù)據(jù)型B端需求文檔的改動難度會大于目前需求文檔，因為編寫的復雜性增加導致文檔中的邏輯/頁簽描述增加。后期改動較復雜。

3.3 數(shù)據(jù)型B端需求文檔設計的劃分

首先，根據(jù)系統(tǒng)的原理和運用系統(tǒng)的方法，對于系統(tǒng)，我們嘗試進行劃分為數(shù)據(jù)、控件、界面三大部分，這三個部分包含了系統(tǒng)全部的主要要素，當然還可以將系統(tǒng)劃分為數(shù)據(jù)、邏輯兩大部分，但是為了配合新設計原則，需要將系統(tǒng)的功能劃分至數(shù)據(jù)、控件、界面才能方便大家的理解和運用，下面分別對這三個部分進行展開，并加入例子方便理解。

在描述數(shù)據(jù)型B端需求文檔的元素前，需要簡單解釋數(shù)據(jù)庫。一般形式的數(shù)據(jù)庫如下表。

這個表的形式類似于數(shù)據(jù)庫，一般來說，系統(tǒng)中展示的值從數(shù)據(jù)庫中取值而來。表頭為數(shù)據(jù)庫的數(shù)據(jù)名稱。表頭下面的內(nèi)容為組成這一條數(shù)據(jù)的數(shù)據(jù)組成。例如：需要展示金剛負責的訂單的時候，只需要取訂單跟進人為金剛的數(shù)據(jù)量進行匯總展示即可。

3.3.1 數(shù)據(jù)

在數(shù)據(jù)型B端需求文檔設計中將數(shù)據(jù)描述清楚需要重點關注三個詞語：標簽化、邏輯運算符、數(shù)值運算符。

標簽化：對于運行需要的符號、數(shù)據(jù)、條件進行標簽化表達。標簽中，表的意思是“的···數(shù)據(jù)表中”、值的意思是“的···值”兩者都是可基于目前已有的數(shù)據(jù)表選擇，標簽化是在新設計原則設計了系統(tǒng)原型并確立數(shù)據(jù)庫的形式以及內(nèi)容后才能進行新需求文檔的標簽化設計。

邏輯運算符號：運算符號包括了且、或、滿足、（）四個符號，與“表”、“值”、“大于/小于/等于等”一起運用于邏輯表達。其中“且”表達的意思是滿足兩個條件、“或”表達的意思是任意滿足其中一個條件、“滿足”為動詞，表示滿足的條件、“（）”的意思為條件，括號內(nèi)代表的是數(shù)值或其他的條件。例如：“錄入”“數(shù)值”“條件限制”“小于”（“滿足”“采購表中”“采購金額值”“小于”“5”）的“采購表中”“采購金額值”“匯總量”，表達的意思是：此空格的數(shù)值填寫的限制為填寫的數(shù)值小于采購表中采購金額值小于5的采購金額值匯總數(shù)值。

*例子中為了凸顯標簽，特意用“”代表一個標簽。

數(shù)值運算符：數(shù)值運算符針對的是數(shù)值的運算，因為單單從邏輯運算會導致系統(tǒng)數(shù)據(jù)描述的不完善。數(shù)值運算符能較好地解決這個問題。例如，“錄入”“數(shù)值”“條件限制”“小于”（“滿足”“采購表中”“采購金額值”“小于”“5”）的“采購表中”“采購金額值”“匯總量”“÷”“5”，表達的意思是：此空格的數(shù)值填寫的限制為填寫的數(shù)值小于采購表中采購金額值小于5的采購金額值匯總數(shù)的五分之一。

*例子中為了凸顯標簽，特意用“”代表一個標簽。

3.3.1.1 數(shù)據(jù)類型

針對數(shù)據(jù)方面的描述可以分為以下三個類型去進行“錄入格式”、“文本屬性變化”、“默認數(shù)據(jù)”三種，代表了描述系統(tǒng)中所有數(shù)據(jù)的展示、限制、讀寫等控制方法。由于新需求設計文檔采用的是標簽化的表達方式，所以以下針對數(shù)據(jù)類型的描述內(nèi)容也是根據(jù)標簽去進行表達。

錄入格式：針對錄入系統(tǒng)的數(shù)據(jù)所作出的數(shù)據(jù)限制、指導以及規(guī)范。其中涉及到運用邏輯運算符號以及數(shù)學運算符號輔助描述錄入格式中的限制以及規(guī)范。從而達到通過標簽化描述清楚錄入格式這個數(shù)據(jù)類型的目的。

文本屬性變化：針對數(shù)據(jù)的形狀以及樣式變化作出限制、指導以及規(guī)范。其中涉及到運用邏輯運算符號以及數(shù)學運算符號輔助描述顏色形狀變化中的限制以及規(guī)范。從而達到通過標簽化描述清楚文本屬性變化這個數(shù)據(jù)類型的目的。

數(shù)據(jù)默認：針對數(shù)據(jù)的數(shù)值大小以及取值作出限制、指導以及規(guī)范。其中涉及到運用邏輯運算符號以及數(shù)學運算符號輔助描述數(shù)據(jù)默認中的限制以及規(guī)范。從而達到通過標簽化描述清楚數(shù)據(jù)默認這個數(shù)據(jù)類型的目的。

（1）錄入格式——類型一

對應可選內(nèi)容：數(shù)值、文本、下拉框。對應三種錄入格式。每一種格式都會有不同標簽組成的限制或者引導。實現(xiàn)對于數(shù)據(jù)錄入的文檔型描述轉化為標簽化描述。

錄入格式解讀：標簽一下面細分為三個標簽分別是“數(shù)值”、“下拉框”、“文本”，對應不同的輸入框以及邏輯表達，這里只對數(shù)值進行限制，并不對數(shù)據(jù)的作用以及數(shù)據(jù)的流轉進行描述，數(shù)據(jù)的流轉以及作用的描述在控件中會提及。

圖中描述的是只是控制的例子，并不是所有控制都是如此，具體限制邏輯可以較為自由去編寫。類似于數(shù)學中的符號，可以將數(shù)學中的符號只有組合表達不同的公式。

錄入格式中數(shù)值限制主要分為兩種限制模式：一種為源數(shù)據(jù)限制，意思為只是簡單地受數(shù)據(jù)的數(shù)值去進行限制。另外一種為條件限制，意思為在數(shù)值的基礎上加入條件去進行限制。條件限制的描述是較為多變，需要加入邏輯運算符以及數(shù)值運算符去輔助描述這個限制。

例如：粉紅色的例子中的第一條，表達的意思為：取值范圍為數(shù)據(jù)表中的某一個數(shù)據(jù)值。

（2）文本屬性變化——類型二

系統(tǒng)中數(shù)據(jù)的顏色形狀會根據(jù)對應數(shù)值內(nèi)容的變化而變化。所以，這部分描述的特點為數(shù)據(jù)的展示方式。

文本屬性變化解讀：文本屬性變化下面細分為兩個變化分別是“源數(shù)據(jù)導致變化”、“其他數(shù)據(jù)導致變化”，對應不同的變化形式以及變化原因。其中針對時間這一變化單獨拿出來，因為時間是系統(tǒng)本身具備的自變量，屬于特殊的自變量。那么關于顏色形狀變化主要為四種類型。

這里僅對數(shù)據(jù)的變化導致的變動進行描述。文本屬性變化的描述里面同樣需要加入邏輯運算符以及數(shù)值運算符去描述不同條件下顏色形狀的變化。由于變化的結果屬于較難描述的情況，所以這部分大致分為圖形變化、顏色變化、文本變化。（數(shù)值變化放在數(shù)據(jù)默認這個版塊介紹）

其中下圖紅框所示的為導致的變化：

*紅框的意思為“導致”在顏色形狀變化中可以作為一個單獨的標簽，也可以不描述。

（3）數(shù)據(jù)默認——類型三

數(shù)據(jù)默認里面包含的是數(shù)據(jù)的展示內(nèi)容以及一些含有邏輯計算后的數(shù)據(jù)展示內(nèi)容類型。主要描述的是數(shù)據(jù)應該如何在系統(tǒng)中展示。

數(shù)據(jù)默認解讀：數(shù)據(jù)默認下面細分為兩個標簽分別是“源數(shù)據(jù)默認”、“關聯(lián)數(shù)據(jù)默認”，根據(jù)不同的默認數(shù)值來源數(shù)據(jù)作為區(qū)分。源數(shù)據(jù)默認：默認的數(shù)值取值判斷標準來源于同一個數(shù)據(jù)表或者固定數(shù)值，例如：采購單的數(shù)量匯總，取值的是采購單表的當前采購單個數(shù)。關聯(lián)數(shù)據(jù)默認：默認的數(shù)值取值判斷標準來源于另外一個數(shù)據(jù)表并且可能在判斷時候加入條件限制。例一：取值高級客戶的訂單數(shù)，其中高級客戶的判斷標準來源于客戶的數(shù)據(jù)表中。例二：化學工程中的流量會因為其他因素導致波動，但是依然需要將其參數(shù)調整到正常的數(shù)值。另外一些數(shù)據(jù)會因為其他數(shù)據(jù)的變動導致變動。例三：生產(chǎn)中的物料如果使用較多的話，那么采購單上的采購數(shù)量就需要對應的增加，或者新增采購單。

3.3.1.2 數(shù)據(jù)類型總結

（1）數(shù)據(jù)型B端需求文檔設計中的數(shù)據(jù)分為三類：“錄入格式”、“顏色形狀變化”、“數(shù)據(jù)默認”分別對應數(shù)據(jù)在系統(tǒng)中的錄入方式、形狀變動方式以及數(shù)據(jù)的展示方式?；竞w了目前文字的需求文檔中關于數(shù)據(jù)的描述。

（2）數(shù)據(jù)型B端需求文檔設計中關于數(shù)據(jù)的描述主要使用邏輯運算符、數(shù)值運算符、表、值四種描述方式結合表達數(shù)據(jù)在系統(tǒng)中的情況。三種類型中的數(shù)據(jù)條件的設定較為靈活，上文只是對這三種數(shù)據(jù)的類型進行了描述情況的劃分和舉例，其中數(shù)值運算符號以及邏輯運算符號的使用參考數(shù)學中的數(shù)學符號表達。新需求文檔設計中關于數(shù)據(jù)的描述基本能達到文本類文檔功能并體現(xiàn)了新需求文檔設計中標簽化、透明化、扁平化的特點。

（3）數(shù)據(jù)型B端需求設計文檔中的數(shù)據(jù)類型的設計原則是結合上文提及的數(shù)據(jù)型B端設計理念中以數(shù)據(jù)為重的系統(tǒng)設計理念進行展開，數(shù)據(jù)型B端設計理念以數(shù)據(jù)為重，數(shù)據(jù)型B端需求設計文檔的數(shù)據(jù)類型也是可以進行標簽化描述，并結合了數(shù)據(jù)庫的取值方法。故在實際工作中產(chǎn)生以下兩個好處：

1. 系統(tǒng)設計文檔中新增或者刪減的某一類數(shù)據(jù)會較為清晰地呈現(xiàn)出來其他變化關系，并能較為明確地知道數(shù)據(jù)的產(chǎn)生者以及產(chǎn)生速度和處理速度，為運營、需求工作人員提供了較為清晰的系統(tǒng)脈絡。
2. 為需求的設計提供了一定的實際依據(jù)，方便需求人員在設計需求的時候提供基本的討論內(nèi)容以及討論界限。

3.3.2 控件

數(shù)據(jù)型B端需求設計文檔中的第二部分描述內(nèi)容為控件?？丶念愋桶凑展δ芸梢苑譃橐韵氯齻€大類：與數(shù)據(jù)有關的控件類、與界面相關的控件類、控件的形狀與其中含有的內(nèi)容。

與數(shù)據(jù)有關的控件類：主要是描述控件對于數(shù)據(jù)的控制關系，含有“生成”、“刪除”、“編輯”三個對數(shù)據(jù)控制的方法，生成數(shù)據(jù)型按鈕的目的是將用戶群體填寫的數(shù)據(jù)通過操作生成數(shù)據(jù)型按鈕存儲到數(shù)據(jù)庫中，增加的內(nèi)容為數(shù)據(jù)庫中的一條數(shù)據(jù)。編輯數(shù)據(jù)型按鈕的目的是將數(shù)據(jù)庫中的一條或多條數(shù)據(jù)中的某一個數(shù)值進行修改。這里的刪除是指對于數(shù)據(jù)庫中整條數(shù)據(jù)的刪除或者是修改狀態(tài)已達到刪除的目的的數(shù)據(jù)控制方法。

與界面相關的控件類：主要描述的是控件對于界面的操控作用，含有“打開界面”、“關閉界面”、“展開或壓縮界面”、“流轉并打開界面”四種對于界面的控制方法，打開界面是在當前界面中打開一個界面即二級界面或者三級界面等，與流轉并打開界面不同，流轉并打開界面是另外開始一個一級界面的意思，雖然兩者都有打開界面的意思。關閉界面的意思為關閉當前界面的意思，一般為取消或者關閉按鈕。展開或壓縮界面的意思是針對目前的界面進行展開或者壓縮，主要是菜單型的界面中這種控件較為常見。

控件的形狀與其中含有的內(nèi)容：主要針對控件的形狀與內(nèi)容進行描述，控件的形狀部分因為屬于圖形的緣故，所以還是需要使用圖形進行描述?？丶膬?nèi)容屬于數(shù)據(jù)默認的一種，上文有提及，數(shù)據(jù)的體現(xiàn)方式主要體現(xiàn)在數(shù)據(jù)默認中，控件中的較為簡單的內(nèi)容為固定文本的顯示，還有一種是控件的內(nèi)容是會隨著關聯(lián)數(shù)據(jù)的變化而改變。所以在這里，控件中的內(nèi)容可以描述為數(shù)據(jù)默認的方式去展示控件中的內(nèi)容。

（1）與數(shù)據(jù)有關的控件類簡介

生成數(shù)據(jù)型控件——類型一

生成數(shù)據(jù)分為跨表型生成數(shù)據(jù)、創(chuàng)建型生成數(shù)據(jù)?？绫硇蜕蓴?shù)據(jù)的意思將原有的一個表的數(shù)據(jù)進行整合后生成另外一個表的數(shù)據(jù)。創(chuàng)建型生成數(shù)據(jù)的意思將用戶群體錄入的在自然環(huán)境中數(shù)據(jù)整合后生成一個表中的數(shù)據(jù)。

生成數(shù)據(jù)型控件解讀：生成數(shù)據(jù)型的控件描述邏輯中，描述的重點是錄入或需要的數(shù)據(jù)與生成的數(shù)據(jù)之間的對接關系以及數(shù)據(jù)與編號之間的關系。生成數(shù)據(jù)里面隱含的一個意思是需要對數(shù)據(jù)庫中的數(shù)據(jù)進行編號，一般來說，數(shù)據(jù)庫的主鍵（即類的命名）是在數(shù)據(jù)庫中有一個對應的編號。例如：采購單的數(shù)據(jù)庫中一般來說都有針對采購單個數(shù)進行編號。兩種關系中，需要先闡明的關系是數(shù)據(jù)與編號之間的對應關系，對應的關系處理出來后，然后就是把原數(shù)據(jù)中的部分轉換為需要生成的數(shù)據(jù)表中對應的部分，例如：通過采購單數(shù)據(jù)生成支付賬單數(shù)據(jù)時，將采購單中的金額字段數(shù)值匯總后轉化為支付單中的應付金額字段。

同樣的，涉及到數(shù)值轉換變化依然需要使用到邏輯運算符號以及數(shù)學運算符號來輔助描述數(shù)值之間的數(shù)學與邏輯關系。

總體來說，此類控件的核心為不同數(shù)據(jù)表之間的數(shù)值對應關系、新數(shù)據(jù)表中的編號規(guī)則命名以及產(chǎn)生數(shù)據(jù)的來源。

2）編輯數(shù)據(jù)型控件——類型二

編輯數(shù)據(jù)型控件主要是對于當前操作數(shù)據(jù)中的其他數(shù)據(jù)進行修改，例如：編輯修改采購單中的預定量。這種是針對到采購單數(shù)據(jù)庫中的預定量進行的數(shù)量修改。分為批量修改、單條數(shù)據(jù)修改、混合型修改。這種修改因為是涉及到數(shù)據(jù)的變動，需要引入數(shù)據(jù)的運算邏輯方面。

編輯數(shù)據(jù)型控件解讀：編輯數(shù)據(jù)型的控件描述邏輯中，需要描述的是編輯頁面中的錄入的數(shù)據(jù)與數(shù)據(jù)庫中數(shù)據(jù)之間的對接關系、錄入數(shù)據(jù)與寫入數(shù)據(jù)庫的數(shù)據(jù)之間的關系，一般來說，錄入數(shù)據(jù)與數(shù)據(jù)庫之間的數(shù)據(jù)關系為一一對應。錄入數(shù)據(jù)和寫入數(shù)據(jù)庫的數(shù)據(jù)之間的關系同樣也是一一對應的關系。例如：修改會員卡中的會員電話號碼信息，編輯數(shù)據(jù)的時候修改會對應到某一個會員的基礎信息中，并不會更新到其他會員中。如果是修改會員卡中的等級操作可以將消費信息錄入，并判斷金額后，修改對應的會員等級，后一個例子屬于判斷錄入數(shù)據(jù)后，對等級數(shù)據(jù)進行的修改。

3）刪除數(shù)據(jù)型控件——類型三

刪除數(shù)據(jù)型控件主要是對于當前操作數(shù)據(jù)中的數(shù)據(jù)進行刪除，包括對主數(shù)據(jù)的刪除以及對數(shù)據(jù)下面的明細數(shù)據(jù)的刪除。例如：刪除訂單明細，刪除的是訂單數(shù)據(jù)庫中的一條數(shù)據(jù)，并不是將這個采購單刪除。例如：刪除訂單，刪除的是訂單數(shù)據(jù)庫中的一條數(shù)據(jù)，不只是刪除其中的某一個明細，而是所有屬于這個采購單的所有明細。兩種類型控件的不一致可以大致理解為是否刪除整個主鍵的數(shù)據(jù)。

刪除數(shù)據(jù)型控件解讀：對刪除數(shù)據(jù)型控件邏輯進行描述，其中主數(shù)據(jù)刪除型其操作特點為是否為選項型刪除數(shù)據(jù)（即刪除所選擇的數(shù)據(jù)）以及是否針對當前操作的數(shù)據(jù)進行刪除。明細型數(shù)據(jù)刪除描述的是當前被刪除數(shù)據(jù)與主鍵數(shù)據(jù)之間的關系，以及刪除的數(shù)據(jù)位置（位于哪一個數(shù)據(jù)表）。

*刪除主數(shù)據(jù)可以不一定為真的刪除當前數(shù)據(jù)，也可以通過設置數(shù)據(jù)的狀態(tài)，使得當前界面不顯示此數(shù)據(jù)，達到類似于刪除的功能方便日后對數(shù)據(jù)進行維護。此方法不屬于刪除數(shù)據(jù)型控件，屬于編輯數(shù)據(jù)型控件，因為修改的內(nèi)容為對應數(shù)據(jù)的狀態(tài)。

（2）與界面相關的控件類

控件的作用中對于界面的控制方式為以下五種“打開界面”、“關閉界面”、“展開或壓縮界面”、“流轉并打開界面”、“清除界面數(shù)據(jù)”

1. 打開界面：打開對應的界面。
2. 關閉界面：關閉對應的界面。
3. 展開或壓縮界面：對本來隱藏的界面的顯示內(nèi)容以及形狀進行改變。
4. 流轉并打開界面：打開對應界面并將數(shù)據(jù)進行流轉：與生成跨表數(shù)據(jù)類型的控件類似，流轉并打開界面更偏重描述打開對應界面。
5. 清除界面數(shù)據(jù)：對界面中的數(shù)據(jù)進行清除操作，并不影響數(shù)據(jù)庫中的數(shù)據(jù)。

與界面相關的控件類解讀：與界面相關的控件類主要描述的是控件對于界面的操控作用，含有“打開界面”、“關閉界面”、“展開或壓縮界面”、“流轉并打開界面”、“清除界面數(shù)據(jù)”五種對于界面的控制方法，分別對應界面的形狀、界面的出現(xiàn)與關閉、界面內(nèi)容三個界面內(nèi)容的控制。因為這部分較為簡單，所以這里不展開描述。

（3）控件的形狀與其中含有的內(nèi)容

這里只針對控件中的內(nèi)容進行較為詳細的描述，因為控件的形狀難以用文字進行描述。

控件的形狀與其中含有的內(nèi)容解讀：控件的內(nèi)容屬于數(shù)據(jù)默認的一種，上文有提及，數(shù)據(jù)的體現(xiàn)方式主要體現(xiàn)在數(shù)據(jù)默認中，控件中的較為簡單的內(nèi)容為固定文本的顯示，還有一種是控件的內(nèi)容是會隨著關聯(lián)數(shù)據(jù)的變化而改變。所以在這里，控件中的內(nèi)容可以描述為數(shù)據(jù)默認的方式去展示控件中的內(nèi)容并加入邏輯運算符號以及數(shù)學運算符號。

*數(shù)據(jù)默認中的邏輯運算符號以及數(shù)學運算符號都是屬于控件內(nèi)容中，此處沒有體現(xiàn)出來。

總結：控件在新需求文檔設計中以及系統(tǒng)中的意思是一致的，控件屬于執(zhí)行當前命令的意思，命令對于系統(tǒng)來說就是實行某一種類型的系統(tǒng)修改，通常用戶層面的系統(tǒng)修改為修改數(shù)據(jù)，不能達到管理員級別的修改，例如：修改頁面中的頁面寬度。所以控件在新需求文檔中簡化為對界面、數(shù)據(jù)這兩個用戶可以達到的系統(tǒng)權限進行控制。數(shù)據(jù)下分為生成、編輯、刪除三個對于數(shù)據(jù)的控制，這里面的控制只是針對已有數(shù)據(jù)庫中的主數(shù)據(jù)或數(shù)據(jù)的明細進行的控制，并不能達到創(chuàng)建數(shù)據(jù)庫以及改變數(shù)據(jù)庫中的數(shù)據(jù)固有關系的權限。對于用戶層面的需求規(guī)劃，當前的新需求文檔可以達到足夠應付的級別。同理界面也是在管理員在處理好界面樣式內(nèi)容的情況，用戶對界面進行調用，并不能直接對界面內(nèi)容進行修改，故當前的新需求文檔可以達到足夠應付的級別。

3.3.3 界面

數(shù)據(jù)型B端需求文檔設計中的界面可以理解為數(shù)值的展示、生成、清除的媒介。不同的界面之所以不同，因為實現(xiàn)的功能不一樣。在用戶角度來說，不同的界面代表了不同的功能和使用者。界面作為一個承接用戶實際任務與系統(tǒng)功能對接的事物，在數(shù)據(jù)型B端系統(tǒng)設計理念中也是如此，接通的是數(shù)據(jù)型B端系統(tǒng)設計理念以及數(shù)據(jù)型B端需求文檔設計理念，在此基礎上，衍生出數(shù)據(jù)的分析。上述的控件，數(shù)值離不開界面，界面作為一個載體承載的是控件（功能）、數(shù)據(jù)（內(nèi)容）。三者為一體構成了系統(tǒng)。

界面不像控件以及數(shù)據(jù)那樣承擔其他功能，對于功能主要為承載控件和數(shù)據(jù)的界面來說，描述界面主要為其中包含的控件以及數(shù)據(jù)。在此之前首先要做的是對控件進行編碼以及對數(shù)據(jù)進行劃分（可取數(shù)據(jù)庫的劃分）

總結：數(shù)據(jù)、控件、界面三位一體地支持系統(tǒng)的運行，所以通過這個思路也可從這三個方面對系統(tǒng)進行描述。這個就是整個數(shù)據(jù)型B端需求文檔設計的主體思路的一部分，另外一部分是基于數(shù)據(jù)型B端系統(tǒng)設計理念——以數(shù)據(jù)為主要出發(fā)點作為主體思路。至此相信讀者應該知道數(shù)據(jù)型B端需求文檔設計方法與當前較為主流的需求文檔不一樣的地方在于將文本化的表達通過可以標簽化的邏輯以及描述體現(xiàn)出來，達到系統(tǒng)邏輯扁平化的目標，類似于公司扁平化管理，系統(tǒng)扁平化管理有利于決策層較為清晰并方便地實行系統(tǒng)轉變。

3.4 數(shù)據(jù)型B端需求文檔設計與數(shù)據(jù)型B端設計理念的結合

3.4.1 數(shù)據(jù)型B端系統(tǒng)設計理念回顧與深入

數(shù)據(jù)型B端系統(tǒng)設計理念將設計的主體劃分為四個：類、數(shù)據(jù)、用戶群體、任務。數(shù)據(jù)型B端需求設計文檔將系統(tǒng)分為數(shù)據(jù)、控件、界面三個部分。下圖闡述的是數(shù)據(jù)型B端系統(tǒng)設計理念以及數(shù)據(jù)型B端需求設計文檔之間的對應關系。

如上圖所示，將兩部分設計元素放于圖上，圖中橘紅色的線描述的是一個元素對于另外一個元素的控制，箭頭開始的元素對于箭頭末尾的元素進行控制。圖中綠色箭頭描述的是類是承載數(shù)據(jù)的載體。例如：用戶群體控制界面、用戶群體通過界面或控件控制數(shù)據(jù)。有了這個對應的關系，我們就能較為清晰地繪畫系統(tǒng)的設計圖以及系統(tǒng)內(nèi)部的結構圖。并通過以上關系模型，構建兩圖之間的聯(lián)系。

上圖為餐廳系統(tǒng)設計圖。圖中綠色為輸出的數(shù)據(jù)，黃色為輸入的數(shù)據(jù)。其中輸出數(shù)據(jù)保證了其每一個數(shù)據(jù)都有對應的流向（流向在圖中沒有表達出來），各用戶群體的責任以及所獲得的數(shù)據(jù)較為清晰地展現(xiàn)出來。保證每一步操作都存在對應的意義。在此基礎上延伸出系統(tǒng)的內(nèi)部設計圖。

*圖中沒有畫出類。

針對每一種數(shù)據(jù)可以設計出對應的界面，例如：需要創(chuàng)建一個客戶輸入菜單的界面。這個界面需要包括各菜品的當前制作情況，各菜品的剩余量。以及一個個人查看菜品的路徑（頁面），顯示的內(nèi)容為當前訂單的制作情況以及排隊情況。后期還可以在此圖上增加對應的設計升級情況。

客戶部分的系統(tǒng)的系統(tǒng)內(nèi)部結構圖如上圖，可以較為清晰地看出客戶主要為兩個界面，接受的數(shù)據(jù)為三個，輸出的數(shù)據(jù)為訂單數(shù)據(jù)。對于整個系統(tǒng)中的數(shù)據(jù)、控件、界面都能較為清晰地顯示，以及對應的邏輯也是可以較為清楚地進行描述。降低日后系統(tǒng)的維護難度。

讀者可以發(fā)現(xiàn)系統(tǒng)內(nèi)部結構圖以及系統(tǒng)設計圖中任務以及界面可以結合一起，并根據(jù)任務內(nèi)容對界面中的細節(jié)進行檢查。例如：客戶界面中的界面一對應客戶任務中的菜單數(shù)據(jù)清單、制作情況數(shù)據(jù)。

簡單來說，系統(tǒng)設計圖可以理解為普通人員對于系統(tǒng)的意見、系統(tǒng)內(nèi)部結構為專業(yè)的需求人員根據(jù)意見來制作的系統(tǒng)需求。兩者通過界面——任務進行結合并提供一個可檢查可升級的設計總圖。

3.5 數(shù)據(jù)型B端設計理念與UML設計理念簡單回顧

數(shù)據(jù)型B端設計理念設計理念：以數(shù)據(jù)為出發(fā)點，在數(shù)據(jù)的基礎上建立任務并分配給對應的用戶群體。并在任務的基礎上去設計對應的界面以及相關輸出和輸入的數(shù)據(jù)。這個就是新設計理念的核心部分。

UML設計理念：以當前流程為出發(fā)點，將每一步操作的細節(jié)、限制、關聯(lián)通過操作人的表述去進行描繪，并在此基礎上建立對應的界面以及系統(tǒng)。

兩種理念最大的區(qū)別為：數(shù)據(jù)型B端設計理念是基于數(shù)據(jù)的基礎上面，是以系統(tǒng)的目標為基礎去進行的。UML設計理念是基于目前流程以及操作的基礎上去建立系統(tǒng)，過程中會實現(xiàn)系統(tǒng)的目標，但設計的目的還是以在系統(tǒng)上實現(xiàn)現(xiàn)實中的操作以及現(xiàn)實中的流程為目標。

4.1 數(shù)據(jù)型B端設計的后續(xù)優(yōu)化

相信讀者在閱讀以上關于數(shù)據(jù)型B端設計的相關內(nèi)容后，對于數(shù)據(jù)型B端的設計理念以及運用有了初步的認識，接下來講解的是數(shù)據(jù)型B端設計建立后，針對數(shù)據(jù)型B端設計出來的系統(tǒng)進行的優(yōu)化方法。

4.1.1 數(shù)據(jù)類的優(yōu)化

數(shù)據(jù)類的優(yōu)化是以系統(tǒng)中的數(shù)據(jù)為出發(fā)點去進行的優(yōu)化手段，分為以下5個優(yōu)化點。

（1）合并型優(yōu)化

將當前數(shù)據(jù)的生成界面或者生成渠道進行合并。

（2）簡化型優(yōu)化

排查數(shù)據(jù)的流轉方向將沒有流轉目標界面的數(shù)據(jù)進行簡化

人工排查數(shù)據(jù)的使用情況進行數(shù)據(jù)的優(yōu)化。

（3）擴展型優(yōu)化

將當前較為主要的用戶群體需要的數(shù)據(jù)追根溯源，追查相關聯(lián)的數(shù)據(jù)并確認是否需要使用，從而達到通過數(shù)據(jù)擴展業(yè)務。例如：餐廳顧客的點菜信息與廚房的做菜信息存在關聯(lián)，所以可以考慮在餐廳顧客頁面加入做菜進度。

（4）用戶數(shù)據(jù)優(yōu)化

將當前用戶群體看到的數(shù)據(jù)進行優(yōu)化以及整合，將任務相同程度較高的進行合并。例如：結賬的時候，顯示當前用戶的vip等級以及相關可以兌換的產(chǎn)品。方便用戶群體一次性處理任務。

（5）數(shù)據(jù)深度優(yōu)化

對于數(shù)據(jù)產(chǎn)生的本質進行思考，通過結合現(xiàn)實中的技術手段以及解決方法使得數(shù)據(jù)產(chǎn)生的方法變得簡介，例如引有自動點數(shù)機，減少車間管理人員點數(shù)的任務。

4.1.2 系統(tǒng)層級的優(yōu)化

數(shù)據(jù)類的優(yōu)化是以系統(tǒng)中的數(shù)據(jù)為出發(fā)點去進行的優(yōu)化手段，分為以下3個優(yōu)化點。

1）系統(tǒng)方向優(yōu)化：監(jiān)督篩查每一個數(shù)據(jù)是否配合公司的目標去進行優(yōu)化。例如：公司的目標是提高物流速度，快遞員的手持上是否出現(xiàn)到達時間的倒計時，是否對于每一個用戶群體優(yōu)化公司目標。

2）系統(tǒng)總體數(shù)據(jù)報表型優(yōu)化：對于重點崗位，篩查是否必要提供的數(shù)據(jù)都能提供到。是否有對應的報表給管理人員展示。

3）用戶群體服務體驗優(yōu)化：簡化用戶群體的任務數(shù)，將用戶分流并專人專用。

5.1 主流B端設計簡介

主流B端設計元素主要為流程、類、數(shù)據(jù)、人、UML的需求設計以及需求的調研很大程度上是建立在流程的基礎上，調研用戶目前的操作流程推導出系統(tǒng)的人使用到的數(shù)據(jù)，并通過數(shù)據(jù)、數(shù)據(jù)限制、操作的先后順序梳理成各種狀態(tài)圖、流程圖等，然后進行系統(tǒng)方面的設計。

5.1.1 主流B端設計元素簡單劃分

（1）流程

流程在UML中有較為重要的地位，一切的調研與分析都是基于流程上進行，一般的流程可以歸納為人在某一個事件中應該做什么，應該有些什么步驟。例如付款流程：掃描各商品一維碼→點擊付款→確認付款方式→進行不同的付款操作→點擊收款結束。

示例圖如下：

圖中是付款流程的主干部分，對于特殊情況的描述，以及一些細節(jié)的刻畫，在UML設計理念中需要不同的圖去進行表達。例如判斷VIP用戶的時候，對應付款的金額會產(chǎn)生改變。這個就是下面需要說到的數(shù)據(jù)方面的問題，在主流B端設計中流程是建立系統(tǒng)的基礎。

（2）狀態(tài)圖

針對數(shù)據(jù)不同引起的流程不一致或者其他數(shù)據(jù)的改變，叫做狀態(tài)圖。

（3）類

類在主流B端設計中的含義與在新設計原則中的含義是基本一致的，都是描述實際事物在系統(tǒng)中的位置，例如付款賬單中，付款時間，收款人，收款金額等數(shù)據(jù)都是歸屬于付款賬單這一個類中，屬于現(xiàn)實中事物在系統(tǒng)上的投影。

（4）用戶

用戶在主流B端設計中是以木頭人去表達，意思是執(zhí)行這些流程的用戶。

5.2 主流B端設計文檔的組成

目前主流B端設計文檔的組成為：一、文字說明增加或修改部分的內(nèi)容的取值以及邏輯。二、圖形輔助說明修改的內(nèi)容的形狀以及位置。這兩部分組成了目前主流設計文檔。并添加編號保存至系統(tǒng)中作為日后可以查詢的依據(jù)。

由于文檔的復雜性以及閱讀需要時間較長，導致很多需求人員在編寫當前需求文檔的時候沒有查詢以往的需求文檔，且歷史需求文檔的描述并非是當前系統(tǒng)的邏輯以及數(shù)據(jù)結構，會存在一定程度上的誤差。以上為主流B端設計文檔的簡述。

5.3 主流B端設計文檔與主流B端設計理念的結合

主流B端設計文檔與主流B端設計理念的結合在于主流B端設計文檔能在流程業(yè)務模型建立后，對系統(tǒng)語言和現(xiàn)實模型進行關聯(lián)，這個關聯(lián)關系需要需求人員在整理模型后，設計對應的界面或者數(shù)據(jù)去承接這個模型，往往這個模型的完整程度以及設計確定了系統(tǒng)的設計方法。因為設計文檔中的內(nèi)容是根據(jù)模型的建立或者修改得出，模型進行了改動，系統(tǒng)對應的部分需要作出對應的修改以適應新的業(yè)務流程模型。

5.4 主流B端設計文檔與主流B端設計理念的優(yōu)劣

主流B端文檔因為其偏向于文本的描述邏輯方式，在編寫方面較為方便，語言的選擇也是較為自由，達到可以表達需求中描述的意思即可?？梢哉f，方便性是主流B端需求文檔的一大優(yōu)勢。

主流B端文檔的劣勢在于其難以被再次運用，屬于一次性的文檔，只是適合當前系統(tǒng)的版本，在系統(tǒng)有較多版本的時候，歷史需求文檔較少機會被翻閱。多次迭代的系統(tǒng)由于需求人員的變動，其邏輯變得難以查詢或通過程序開發(fā)員去進行查詢。方法較為麻煩。同理，邏輯的查詢在目前需求文檔中也是由于其文本化描述的特性變得難以看出其中的邏輯。

主流B端設計文檔的現(xiàn)象可以說是在UML設計理念上出現(xiàn)的，因為UML設計模型不能轉化為需求文檔的內(nèi)容，所以需要通過人工將模型轉化為系統(tǒng)語言。兩者的優(yōu)勢在于建立模型較為簡便，并易于轉化，在系統(tǒng)較為簡單的時候，兩者起到的作用在系統(tǒng)前期要優(yōu)于新系統(tǒng)設計理念。

在系統(tǒng)后期，版本迭代一定程度后，系統(tǒng)中的邏輯會變得更為復雜，并且由于系統(tǒng)的改變并不一定來自同一個人員，所以系統(tǒng)中的邏輯會變得不清晰，不同模塊之間的隔閡會加大。系統(tǒng)的復雜性會指數(shù)級增長。

6.1 總結

本文總結了當前的B端設計理念的優(yōu)劣并在此基礎上衍生出個人的另外一種新的B端設計理念——數(shù)據(jù)型B端設計理念的想法以及提出關于當前需求文檔的改善方案——數(shù)據(jù)型B端需求設計文檔。期望借助這種數(shù)據(jù)型B端設計理念解決當前主流B端設計導致的常見問題以及主流B端需求文檔導致的常見問題。

本文也闡述了基于數(shù)據(jù)型B端設計理念重新設計的模型劃分以及數(shù)據(jù)型B端需求設計文檔中的編寫規(guī)則。解釋了由本人所想的數(shù)據(jù)型B端設計理念的基本構成。

總體來說本文只是一個B端產(chǎn)品設計的方向。希望建立在數(shù)據(jù)上的設計文檔能解決目前B端產(chǎn)品遇到的需求上的問題。

希望能為廣大的B端設計工作者、B端需求人員帶來一些有益的思考，同時也歡迎產(chǎn)品經(jīng)理朋友或者希望從事產(chǎn)品經(jīng)理行業(yè)的朋友指點。

一生二，二生三，三生萬物。系統(tǒng)與真實世界的關系將會誕生更多的事物。謝謝大家觀看。

本文由 @陳柏韜 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協(xié)議