編輯導語：在上一篇文章中，作者介紹了關於軟件開發設計驗證中的檢驗應用設計的質量，但是在應用設計驗證中，還有更多重點項目，比如工作效率、運行流程等等方面；本文作者分享了關於應用設計驗證與應用用例，我們一起來了解一下。
設計驗證的第二層是檢驗應用設計的質量。應用設計的檢驗是對軟件“好用”的保證，它解決了如何用信息化手段提升客户的工作效率。
應用設計驗證重點包括：業務設計的結果在系統中的落地是否順利？流程的流轉是否合理？界面操作是否友好？工作效率是否有明顯提升？等等，應用設計的成果“為客户構建了信息化的工作環境”。
軟件如果不好用，則業務設計得再好、領導給的壓力再大，用户都會排斥使用系統，可以説系統的易操作性直接關係到了軟件的生命週期也不為過；應用用例是後續測試用例的重要輸入，同時也是用户上線培訓的教材。
一、定義1. 應用設計驗證通過編寫一套操作步驟，用以模擬某個業務處理場景的實際操作過程，應用驗證最好採用高保真的界面原型、並且可以按照預定的流程進行跳轉。
這套操作步驟將包括登錄、啓動流程、打開界面、數據輸入、通知、監控等在內的功能串聯在一起，用以驗證操作過程是否滿足用户的實操需求，可以説是對業務用例的內容在信息化環境下“操作滿意度”的檢查。
應用設計驗證的主要工作是編寫應用用例和驗證結果。
2. 應用用例是針對應用設計階段成果的驗證依據。應用用例是將應用設計的組件（界面）、按鈕控件、菜單、監控、通知、權限等構成了一個虛擬的操作環境，在界面上運行業務用例的數據。
應用用例的運行要符合業務用例中的業務邏輯和數據邏輯關係，因此應用用例可以模擬系統完成後的實際使用場景，它可以讓用户、需求工程師、技術人員（設計、開發、測試）等所有相關方在系統完成開發前，就基本上知道了系統完成後的運行效果。
- 用例構成：用例場景、運行導圖和基礎數據；
- 編寫期間：是在應用設計期間編寫的，在應用設計完成時進行驗證；
注：應用設計與業務設計的關係。
應用設計的成果相當於業務設計成果加上了一個可以操作的“外殼”。用户是通過應用設計內容（界面、按鈕等）去操作業務設計的內容（數據、規則）的。
圖1 業務設計與應用設計的關係
應用設計要求需求工程師具有跨界的知識和能力，包括（不限於此）：客户專業知識、業務設計知識、技術開發知識、UI設計、美工設計知識、系統上線經驗等。
3. 應用用例的作用應用設計驗證檢驗了所有的系統功能的使用方法、使用順序、操作步驟、相應的規則等，圖2 表示了在軟件工程框架上編寫應用用例的位置。
圖2 軟件工程框架上應用用例的位置
應用用例可以模擬“人-機-人”的工作環境，通過與用户的共同確認幫助進行以下的驗證（不限於此）。
1）支持驗證應用設計結果
- 模擬系統完成後的操作環境，感受應用操作的效率、人機友好滿意度；
- 可以提前發現和解決隱性設計缺陷，減少開發完成後的軟件商與用户之間的認知誤差；
- 統一系統干係人對設計的認知，認知包括對以下內容的理解：架構、功能、操作等；
2）支持測試用例的編制
作為後面測試用例的“操作流程”案例，與應用設計成果（界面、控件）、業務設計成果（業務邏輯、數據邏輯）等共同組合，支持編寫測試用例。
3）使用對象、使用場合
- 在軟件公司的設計相關人中間進行討論、驗證。
- 與用户的相關部門、崗位進行溝通、確認。
- 向後續設計、驗證提供功能、邏輯、數據、機制的支持。
- 做為客户上線培訓的重要資料等。
4）客户價值
除去對功能方面設計成果的驗證外，應用用例還有一個重要作用就是對應用價值的驗證，應用用例可以讓用户直接感受到應用價值的存在。
感受應用價值的方法有很多，比如
- 按照角色：應用用例可以按照不同的企業角色去編寫，如董事長、財務總監、項目經理、庫管員等，讓各角色都清楚地知道他在系統中的工作內容和要遵守的規則。
- 按照流程：應用用例可以沿着不同的流程去編寫，如採購流程、報銷流程、物流流程等，將每一條流程相關的功能全部串聯起來，用以檢查流程上各角色之間的協同是否有問題等。
編寫應用用例是應用設計驗證的主要工作。一個完整的應用用例由三個部分構成：用例場景、運行導圖和基礎數據。
應用用例與業務用例在場景設計選擇上有所不同，業務用例更多的是驗證業務本身（以某個業務線為主軸設計），而不在意該業務由那個角色來處理，但是應用用例的“應用”不但要有主線而且還要針對角色而設置的用例；重點在站在某個角色的立場上將“該角色關心的內容整合成流程”加以推演，因此，在確定題目、目的和價值之前需要首先確定操作角色。
- 角色：按照部門、角色規劃（董事長、成本會計、倉庫管理員、…），或是一組角色。
- 題目：從該角色的視角出發，選定題目。
- 目的：根據上述的題目，確定該角色關心什麼、要什麼結果。
- 價值：達到了目的後，可以給該角色帶來什麼價值。
從角色出發設置用例場景，這就是為什麼説應用用例可以驗證客户的信息化價值的原因。
1.用例場景以某個工程項目的項目總監為對象，參見圖3。
圖3 項目總監的看板
- 角色：項目總監。
- 題目：項目總監的項目管理看板。
- 目的：項目總監打開界面就可找到他所需要的信息、完成想做的事。
- 價值：項目總監可以及時地掌握公司全部項目的走向，快遞地做出判斷。
為了可以達到目的，場景設計時在一個界面上將項目總監關心的信息、材料、以及總監需要操作的功能、待辦事宜、發佈的通知等全部功能集中，甚至將企業知識庫（公司規章制度、法律法規等）全部鏈接起來，讓項目總監不用頻繁地點擊菜單四處尋找就可以知道自己在信息系統中能夠到什麼信息、處理什麼工作等。
同理，也可以設計出董事長、總經理、總會計師、倉庫管理員等各類企業運營中關鍵角色的應用用例，在系統上線前讓他們充分地理解和意識到系統上線後的變化，可以提前做好準備，包括：組織、崗位的調整，相關管理規則的調整。
2. 運行導圖運行導圖，是用圖形的方式，將場景的內容按照操作流程的順序詳細地呈現出來，它包含了在系統中操作的主要步驟、主要操作功能（節點）、以及想要呈現給觀者的信息化環境下最具應用價值的內容。
1）運行導圖的構成
運行導圖的內容、方式可以根據應用設計師向用户、技術設計師展示的內容而定，但是有以下幾個必須要有的核心內容：
- 操作導圖：給出應用用例的主線。
- 操作界面：給出操作流程圖上每個節點的組件原型界面截圖。
- 數據導圖：給出每個節點上需要的外部數據源，比如：基礎數據（字典）等。
- 管控導圖：給出具有管控功能的系統機制，説明如何進行管控。
系統運行時的操作流程不是業務設計中的業務流程，可以看做是在系統上運行的“業務流程”；比如，在業務用例中，業務流程是將業務功能用邏輯串聯起來，但是在應用用例中，實現同樣流程可以採用“事找人”的主動推送流轉方式。
2）運行導圖的設計
【操作導圖】：
下圖是用來描繪“成本管理”模塊的操作流程示意圖，參見圖4。
圖4 操作導圖
- 目的：應用用例的主要導圖，可以讓用户完整地、準確地知道系統上線後的工作環境。是系統完成前用户就瞭解系統帶來信息化價值的主要途徑。
- 特點：雖然不是真實系統，但是用户的感受與完成後的真實系統是一樣的、否則用户不能提前指出系統是否存在問題、或是雙方之間是否有理解上的誤差。
- 內容：需要詳細到具體點擊的是哪一個按鈕、哪一條有鏈接的數據等，雖然界面是原型但是由於有控件（字段、按鈕）、鏈接、提示框等系統的要素，用户完全可以體會到系統完成後的環境。
【數據導圖】：
當推演的場景非常複雜，僅僅依靠操作導圖、界面截圖等內容不足以説明業務邏輯、數據來源等隱性的設計成果時，可以採用數據導圖作為輔助，揭示運行導圖（節點）背後的支持的數據等內容，如圖5所示：
圖5 數據導圖
- ①繪製簡單的運行導圖（只要有節點名稱，不需要看清楚界面的內容）。
- ③在節點下方標示出該節點必需的基礎數據、管理規則庫的名稱等（在該節點首次輸入）。
- ③在節點數據源下面給出數據之間的邏輯關係、以及內部的複雜處理算式規則等。
這裏講的基礎數據是個廣義的概念，它包括了所有系統運行前需要準備的數據。
1）基礎數據設置
這是重要的企業信息化管理內容，它包括瞭如何編制所有的系統運行所需的用字典形式進行管理的數據，對象有：材料字典、設備字典、產品字典、組織字典等。
2）管理規則設置
管理規則也是一套“數據”，這些規則需要由客户的相關部門根據自己部門所管的業務功能，預先制定出可以支持信息系統用的標準和對應的規則，然後在系統運行前設定到系統中，比如時限用的規則表。
3）分歧條件設置
通過運行導圖的推演，與用户具體的確認有關聯流程的基本設定條件，如
- 業務流程：流程的分歧、流轉所依據的業務標準、對應的管理規則等。
- 審批流程：審批條件、通過、拒絕等的標準、對應的管理規則等。
4）系統權限設置
為每個系統用户設定權限，體現了“信息化環境”管理的方式，這個方式可以協助組織管理部門進行精確地管理，它也是信息化環境下的組織管理的重要內容和手段。
三、應用設計驗證過程驗證過程在編寫應用場景、繪製操作導圖、數據導圖的時候就開始了：
- 系統運行前必須準備好的基礎數據（輸入）。
- 按照應用場景進行流程啓動、結束、通知。
- 對流程上的每個功能界面的進行操作。
- 檢驗每一步操作的合理性、易用性，等。
按照這樣的方法推演下來，基本上就可以確認應用設計的結果是否正確了。
注1：應用設計驗證與業務設計驗證的區別。
業務設計驗證只關心與數據相關的內容，如：對合同編制功能的業務驗證，重點在與合同相關的業務邏輯、數據邏輯、數據來源、管控規則等是否正確；但是對操作合同編制界面的輸入效率、如何查詢合同相關信息、合同完成後如何鎖定數據的等內容不涉及。
注2：應用用例與操作手冊的區別。
操作手冊一般是按照界面操作的每個字段、按鈕進行説明的，非常細，是對完成的軟件操作知道；應用用例是對操作是否合理的檢查、驗證，當然有了應用用例後編寫操作手冊會容易。
四、總結相對於建築業、製造業、影視業等都要進行設計階段和製作階段兩次的檢驗來説，軟件行業基本上只有製作完成後的一次檢驗。
軟件行業為了保證產品質量也應該加上雙保險：設計驗證和軟件測試。目前對設計階段成果的驗證還不普及，研究也不夠深入。
從前面的探討可以看出來，如果沒有進行設計驗證，僅僅依靠軟件測試，待發現了設計問題時就一定要進行返工了，這樣做是不能保證軟件產品的最終質量的。
軟件行業的發展還很年輕，經驗還不足，因此應該借鑑其它行業的好方法好經驗，快速提升軟件行業的產品質量，提升客户對軟件產品的滿意度。
作者：李鴻君；著有《大話軟件工程—需求分析與軟件設計》一書。
本文由 @李鴻君 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議