當我們進行業(yè)務流程分析時，只空對空而不落到紙面上是不可以的。過去，在面向過程的時代，我們繪制DFD圖、流程圖，以及編寫流程說明來描繪這一部分分析；而現(xiàn)在，在面向?qū)ο蟮臅r代，我們則是繪制行動圖、狀態(tài)圖，以及編寫用例說明來完成這部分工作。

在這部分工作中，編寫用例說明應當是最主要的工作，之后在一些關(guān)鍵部分輔之以行動圖、狀態(tài)圖。現(xiàn)在我們來看看用例說明應當怎樣編寫。

毫不疑問，做用例分析首先是要繪制出用例圖（前面已經(jīng)說過了）。圖形的最大優(yōu)勢是能夠形象生動地描述我們的分析，但它最大的缺點是會遺失許多的細節(jié)信息，因此我們必須要對它進行進一步的文字描述。




由于不同的人對用例的理解不同，格式也不盡相同，但一些基本的元素是一樣的。以上表格是我采用的用例說明格式，其中用例名稱、用例描述、參與者、前置條件、事件流、后置條件是公認的、用例說明的基本元素。

用例標識：就是用例的編號，一般采用“項目編號-子系統(tǒng)編號-模塊編號-序號”來編號。

用例名稱：沒啥可說的，就是用例圖中該用例的名稱。注意用例的命名規(guī)則：用例名稱通常是一個動詞短語或短句，而不是一個名詞短語。它可以是一個動詞（如：自動考核），一個動賓短語（如：提取存款），一個被動句（如：發(fā)票填報），或者一個主謂句（如：用戶提款，這個不推薦，因為主語就是參與者，顯得有些多余）。

用例類型：在我看來，不同類型的用例，其用例說明的格式是不一樣的。以上給出的是“業(yè)務操作”類用例的格式，它更加著重地在描述業(yè)務操作的流程。而“查詢報表”類用例則沒有什么流程，它更加著重地在描述報表格式及顯示內(nèi)容（后面再給出）。還有用例類型還包括“子用例”、“擴展用例”。

用例描述：對該用例的功能定義、要實現(xiàn)的業(yè)務需求，以及誰（參與者）應該如何使用進行描述。同時，這部分還可以整體概述實現(xiàn)業(yè)務需求的主要流程，以及與其它用例、其它外部系統(tǒng)的關(guān)系。通過用例描述，閱讀者可以對該用例有一個整體的認識。

參與者：用例圖中該用例的參與者，通常是業(yè)務操作的觸發(fā)者和施與對象（如外部系統(tǒng)）。

觸發(fā)事件：誰干了什么，觸發(fā)了這個用例。

前置條件：在觸發(fā)該用例相關(guān)操作前必須達到的條件。

事件流：這是用例說明中最重要的部分，它詳細描述了該用例可能出現(xiàn)的所有流程。
1. 基本流程：另一個名稱更能表達它的意義：最佳流程（The Best Flow）。它描述的是該用例以最佳的、最正常的方式流轉(zhuǎn)，沒有出現(xiàn)任何異常，并且最終成功完成操作的流程。基本流程在編寫時，應當通過數(shù)字對流程中的每一步進行編號。
2. 擴展流程：或者叫“分支流程”，它描述的是基本流程在流轉(zhuǎn)過程中可能出現(xiàn)的所有分支。擴展流程最大的特點就是，它應當是在基本流程的某一步驟發(fā)生的分支，因此它的編號規(guī)則是“基本流程號+序號”。基本流程號就是發(fā)生分支的那一個基本流程的編號。在同一個基本流程上發(fā)生多個分支時，它們的序號從1依次開始編號。
另一種情況是，某個擴展流程本身擁有多個步驟，這時應當在“基本流程號+自身序號”的基礎(chǔ)上再添加序號，如“2.1.1”。
擴展流程在描述時，應當首先描述進入這個分支的條件，即“如果××則××”、“當××時××”。
3. 異常流程：就是發(fā)生異常情況時的處理流程。注意，用例說明是站在用例角度進行的說明，因此這里并不是我們通常一樣的發(fā)生程序異常的處理流程，而是用戶在處理業(yè)務操作時發(fā)生的異常情況，如：如果顧客不能提供身份證，則??????

后置條件：又稱為“成功保證”，就是執(zhí)行基本流程獲得成功以后所達到的狀態(tài)（條件）。后置條件往往體現(xiàn)的是執(zhí)行該用例的最終目的。如：完成用戶檔案的填寫并提交。

非功能需求：簡稱為“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。這一部分的需求分析相當重要而又最容易被忽略，后面我們再詳細討論。

假設與約束：就是隱藏于業(yè)務功能中的各項規(guī)則與條件，如各種邏輯條件、計算公式、環(huán)境限制等等。

優(yōu)先級：沒啥可說的，最關(guān)鍵的是怎么去評定。這里我賣一個官子，在需求評審階段，我會給大家一個比較準確而又可操作的評定方法。

除此之外，我還往往在每一個用例說明的后面與該用例相關(guān)的需求列表，便于需求跟蹤。用例分析實質(zhì)是需求人員的一份設計。既然是設計就可能出現(xiàn)偏差，最終偏離原始的需求（這種情況特別容易出現(xiàn)在日后的升級維護中）。因此，將需求列表附在用例后面，便于日后的需求評審與確認。當每次需要升級時，則添加上新的需求，或?qū)σ酝男枨筮M行更新。

我們應當怎樣做需求分析
我們應當怎樣做需求調(diào)研：初識
我們應當怎樣做需求調(diào)研：拜訪
我們應當怎樣做需求調(diào)研：研討會
我們應當怎樣做需求調(diào)研：需求研討
我們應當怎樣做需求調(diào)研：迭代
我們應當怎樣做需求調(diào)研：需求捕獲（上）
我們應當怎樣做需求調(diào)研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業(yè)務流程分析（上）
我們應當怎樣做需求分析：業(yè)務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態(tài)圖
我們應當怎樣做需求分析：業(yè)務領(lǐng)域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領(lǐng)域驅(qū)動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規(guī)格說明書
我們應當怎樣做需求確認：評審與簽字確認會

（續(xù)）

我們應當怎樣做需求分析：用例說明