當我們進行業務流程分析時，只空對空而不落到紙面上是不可以的。過去，在面向過程的時代，我們繪制DFD圖、流程圖，以及編寫流程說明來描繪這一部分分析；而現在，在面向對象的時代，我們則是繪制行動圖、狀態圖，以及編寫用例說明來完成這部分工作。
在這部分工作中，編寫用例說明應當是最主要的工作，之后在一些關鍵部分輔之以行動圖、狀態圖?，F在我們來看看用例說明應當怎樣編寫。
毫不疑問，做用例分析首先是要繪制出用例圖（前面已經說過了）。圖形的最大優勢是能夠形象生動地描述我們的分析，但它最大的缺點是會遺失許多的細節信息，因此我們必須要對它進行進一步的文字描述。
由于不同的人對用例的理解不同，格式也不盡相同，但一些基本的元素是一樣的。以上表格是我采用的用例說明格式，其中用例名稱、用例描述、參與者、前置條件、事件流、后置條件是公認的、用例說明的基本元素。
用例標識：就是用例的編號，一般采用“項目編號-子系統編號-模塊編號-序號”來編號。
用例名稱：沒啥可說的，就是用例圖中該用例的名稱。注意用例的命名規則：用例名稱通常是一個動詞短語或短句，而不是一個名詞短語。它可以是一個動詞（如：自動考核），一個動賓短語（如：提取存款），一個被動句（如：發票填報），或者一個主謂句（如：用戶提款，這個不推薦，因為主語就是參與者，顯得有些多余）。
用例類型：在我看來，不同類型的用例，其用例說明的格式是不一樣的。以上給出的是“業務操作”類用例的格式，它更加著重地在描述業務操作的流程。而“查詢報表”類用例則沒有什么流程，它更加著重地在描述報表格式及顯示內容（后面再給出）。還有用例類型還包括“子用例”、“擴展用例”。
用例描述：對該用例的功能定義、要實現的業務需求，以及誰（參與者）應該如何使用進行描述。同時，這部分還可以整體概述實現業務需求的主要流程，以及與其它用例、其它外部系統的關系。通過用例描述，閱讀者可以對該用例有一個整體的認識。
參與者：用例圖中該用例的參與者，通常是業務操作的觸發者和施與對象（如外部系統）。
觸發事件：誰干了什么，觸發了這個用例。
前置條件：在觸發該用例相關操作前必須達到的條件。
事件流：這是用例說明中最重要的部分，它詳細描述了該用例可能出現的所有流程。
1. 基本流程：另一個名稱更能表達它的意義：最佳流程（The Best Flow）。它描述的是該用例以最佳的、最正常的方式流轉，沒有出現任何異常，并且最終成功完成操作的流程。基本流程在編寫時，應當通過數字對流程中的每一步進行編號。
2. 擴展流程：或者叫“分支流程”，它描述的是基本流程在流轉過程中可能出現的所有分支。擴展流程最大的特點就是，它應當是在基本流程的某一步驟發生的分支，因此它的編號規則是“基本流程號+序號”。基本流程號就是發生分支的那一個基本流程的編號。在同一個基本流程上發生多個分支時，它們的序號從1依次開始編號。
另一種情況是，某個擴展流程本身擁有多個步驟，這時應當在“基本流程號+自身序號”的基礎上再添加序號，如“2.1.1”。
擴展流程在描述時，應當首先描述進入這個分支的條件，即“如果××則××”、“當××時××”。
3. 異常流程：就是發生異常情況時的處理流程。注意，用例說明是站在用例角度進行的說明，因此這里并不是我們通常一樣的發生程序異常的處理流程，而是用戶在處理業務操作時發生的異常情況，如：如果顧客不能提供身份證，則??????
后置條件：又稱為“成功保證”，就是執行基本流程獲得成功以后所達到的狀態（條件）。后置條件往往體現的是執行該用例的最終目的。如：完成用戶檔案的填寫并提交。
非功能需求：簡稱為“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。這一部分的需求分析相當重要而又最容易被忽略，后面我們再詳細討論。
假設與約束：就是隱藏于業務功能中的各項規則與條件，如各種邏輯條件、計算公式、環境限制等等。
優先級：沒啥可說的，最關鍵的是怎么去評定。這里我賣一個官子，在需求評審階段，我會給大家一個比較準確而又可操作的評定方法。
除此之外，我還往往在每一個用例說明的后面與該用例相關的需求列表，便于需求跟蹤。用例分析實質是需求人員的一份設計。既然是設計就可能出現偏差，最終偏離原始的需求（這種情況特別容易出現在日后的升級維護中）。因此，將需求列表附在用例后面，便于日后的需求評審與確認。當每次需要升級時，則添加上新的需求，或對以往的需求進行更新。
我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會
（續）
在這部分工作中，編寫用例說明應當是最主要的工作，之后在一些關鍵部分輔之以行動圖、狀態圖?，F在我們來看看用例說明應當怎樣編寫。
毫不疑問，做用例分析首先是要繪制出用例圖（前面已經說過了）。圖形的最大優勢是能夠形象生動地描述我們的分析，但它最大的缺點是會遺失許多的細節信息，因此我們必須要對它進行進一步的文字描述。
由于不同的人對用例的理解不同，格式也不盡相同，但一些基本的元素是一樣的。以上表格是我采用的用例說明格式，其中用例名稱、用例描述、參與者、前置條件、事件流、后置條件是公認的、用例說明的基本元素。
用例標識：就是用例的編號，一般采用“項目編號-子系統編號-模塊編號-序號”來編號。
用例名稱：沒啥可說的，就是用例圖中該用例的名稱。注意用例的命名規則：用例名稱通常是一個動詞短語或短句，而不是一個名詞短語。它可以是一個動詞（如：自動考核），一個動賓短語（如：提取存款），一個被動句（如：發票填報），或者一個主謂句（如：用戶提款，這個不推薦，因為主語就是參與者，顯得有些多余）。
用例類型：在我看來，不同類型的用例，其用例說明的格式是不一樣的。以上給出的是“業務操作”類用例的格式，它更加著重地在描述業務操作的流程。而“查詢報表”類用例則沒有什么流程，它更加著重地在描述報表格式及顯示內容（后面再給出）。還有用例類型還包括“子用例”、“擴展用例”。
用例描述：對該用例的功能定義、要實現的業務需求，以及誰（參與者）應該如何使用進行描述。同時，這部分還可以整體概述實現業務需求的主要流程，以及與其它用例、其它外部系統的關系。通過用例描述，閱讀者可以對該用例有一個整體的認識。
參與者：用例圖中該用例的參與者，通常是業務操作的觸發者和施與對象（如外部系統）。
觸發事件：誰干了什么，觸發了這個用例。
前置條件：在觸發該用例相關操作前必須達到的條件。
事件流：這是用例說明中最重要的部分，它詳細描述了該用例可能出現的所有流程。
1. 基本流程：另一個名稱更能表達它的意義：最佳流程（The Best Flow）。它描述的是該用例以最佳的、最正常的方式流轉，沒有出現任何異常，并且最終成功完成操作的流程。基本流程在編寫時，應當通過數字對流程中的每一步進行編號。
2. 擴展流程：或者叫“分支流程”，它描述的是基本流程在流轉過程中可能出現的所有分支。擴展流程最大的特點就是，它應當是在基本流程的某一步驟發生的分支，因此它的編號規則是“基本流程號+序號”。基本流程號就是發生分支的那一個基本流程的編號。在同一個基本流程上發生多個分支時，它們的序號從1依次開始編號。
另一種情況是，某個擴展流程本身擁有多個步驟，這時應當在“基本流程號+自身序號”的基礎上再添加序號，如“2.1.1”。
擴展流程在描述時，應當首先描述進入這個分支的條件，即“如果××則××”、“當××時××”。
3. 異常流程：就是發生異常情況時的處理流程。注意，用例說明是站在用例角度進行的說明，因此這里并不是我們通常一樣的發生程序異常的處理流程，而是用戶在處理業務操作時發生的異常情況，如：如果顧客不能提供身份證，則??????
后置條件：又稱為“成功保證”，就是執行基本流程獲得成功以后所達到的狀態（條件）。后置條件往往體現的是執行該用例的最終目的。如：完成用戶檔案的填寫并提交。
非功能需求：簡稱為“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。這一部分的需求分析相當重要而又最容易被忽略，后面我們再詳細討論。
假設與約束：就是隱藏于業務功能中的各項規則與條件，如各種邏輯條件、計算公式、環境限制等等。
優先級：沒啥可說的，最關鍵的是怎么去評定。這里我賣一個官子，在需求評審階段，我會給大家一個比較準確而又可操作的評定方法。
除此之外，我還往往在每一個用例說明的后面與該用例相關的需求列表，便于需求跟蹤。用例分析實質是需求人員的一份設計。既然是設計就可能出現偏差，最終偏離原始的需求（這種情況特別容易出現在日后的升級維護中）。因此，將需求列表附在用例后面，便于日后的需求評審與確認。當每次需要升級時，則添加上新的需求，或對以往的需求進行更新。
我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會
（續）
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
