當我們進行業務流程分析時，只空對空而不落到紙面上是不可以的。過去，在面向過程的時代，我們繪製dfd圖、流程圖，以及編寫流程說明來描繪這一部分分析；而現在，在物件導向的時代，我們則是繪製行**、狀態圖，以及編寫用例說明來完成這部分工作。
在這部分工作中，編寫用例說明應當是最主要的工作，之後在一些關鍵部分輔之以行**、狀態圖。現在我們來看看用例說明應當怎樣編寫。
毫不疑問，做用例分析首先是要繪製出用例圖（前面已經說過了）。圖形的最大優勢是能夠形象生動地描述我們的分析，但它最大的缺點是會遺失許多的細節資訊，因此我們必須要對它進行進一步的文字描述。
[img]
由於不同的人對用例的理解不同，格式也不盡相同，但一些基本的元素是一樣的。以上**是我採用的用例說明格式，其中用例名稱、用例描述、參與者、前置條件、事件流、後置條件是公認的、用例說明的基本元素。
用例標識：就是用例的編號，一般採用「專案編號-子系統編號-模組編號-序號」來編號。
用例名稱：沒啥可說的，就是用例圖中該用例的名稱。注意用例的命名規則：用例名稱通常是乙個動詞短語或短句，而不是乙個名詞短語。它可以是乙個動詞（如：自動考核），乙個動賓短語（如：提取存款），乙個被動句（如：發票填報），或者乙個主謂句（如：使用者提款，這個不推薦，因為主語就是參與者，顯得有些多餘）。
用例型別：在我看來，不同型別的用例，其用例說明的格式是不一樣的。以上給出的是「業務操作」類用例的格式，它更加著重地在描述業務操作的流程。而「查詢報表」類用例則沒有什麼流程，它更加著重地在描述報**式及顯示內容（後面再給出）。還有用例型別還包括「子用例」、「擴充套件用例」。
用例描述：對該用例的功能定義、要實現的業務需求，以及誰（參與者）應該如何使用進行描述。同時，這部分還可以整體概述實現業務需求的主要流程，以及與其它用例、其它外部系統的關係。通過用例描述，閱讀者可以對該用例有乙個整體的認識。
參與者：用例圖中該用例的參與者，通常是業務操作的觸發者和施與物件（如外部系統）。
觸發事件：誰幹了什麼，觸發了這個用例。
事件流：這是用例說明中最重要的部分，它詳細描述了該用例可能出現的所有流程。
1. 基本流程：另乙個名稱更能表達它的意義：最佳流程（the best flow）。它描述的是該用例以最佳的、最正常的方式流轉，沒有出現任何異常，並且最終成功完成操作的流程。基本流程在編寫時，應當通過數字對流程中的每一步進行編號。
2. 擴充套件流程：或者叫「分支流程」，它描述的是基本流程在流轉過程中可能出現的所有分支。擴充套件流程最大的特點就是，它應當是在基本流程的某一步驟發生的分支，因此它的編號規則是「基本流程號+序號」。基本流程號就是發生分支的那乙個基本流程的編號。在同乙個基本流程上發生多個分支時，它們的序號從1依次開始編號。
另一種情況是，某個擴充套件流程本身擁有多個步驟，這時應當在「基本流程號+自身序號」的基礎上再新增序號，如「2.1.1」。
擴充套件流程在描述時，應當首先描述進入這個分支的條件，即「如果××則××」、「當××時××」。
3. 異常流程：就是發生異常情況時的處理流程。注意，用例說明是站在用例角度進行的說明，因此這裡並不是我們通常一樣的發生程式異常的處理流程，而是使用者在處理業務操作時發生的異常情況，如：如果顧客不能提供身份證，則••••••
後置條件：又稱為「成功保證」，就是執行基本流程獲得成功以後所達到的狀態（條件）。後置條件往往體現的是執行該用例的最終目的。如：完成使用者檔案的填寫並提交。
非功能需求：簡稱為「urps+」，即可用性（usability）、可靠性（reliability）、效能（performance）、可支援性（supportability）以及其它（+）。這一部分的需求分析相當重要而又最容易被忽略，後面我們再詳細討論。
假設與約束：就是隱藏於業務功能中的各項規則與條件，如各種邏輯條件、計算公式、環境限制等等。
除此之外，我還往往在每乙個用例說明的後面與該用例相關的需求列表，便於需求跟蹤。用例分析實質是需求人員的乙份設計。既然是設計就可能出現偏差，最終偏離原始的需求（這種情況特別容易出現在日後的公升級維護中）。因此，將需求列表附在用例後面，便於日後的需求評審與確認。當每次需要公升級時，則新增上新的需求，或對以往的需求進行更新。
[url=我們應當怎樣做需求分析[/url]
[url=我們應當怎樣做需求調研：初識[/url]
[url=我們應當怎樣做需求調研：拜訪[/url]
[url=我們應當怎樣做需求調研：研討會[/url]
[url=我們應當怎樣做需求調研：需求研討[/url]
[url=我們應當怎樣做需求調研：迭代[/url]
[url=我們應當怎樣做需求調研：需求捕獲（上）[/url]
[url=我們應當怎樣做需求調研：需求捕獲（下）[/url]
[url=我們應當怎樣做需求分析：功能角色分析與用例圖[/url]
[url=我們應當怎樣做需求分析：業務流程分析（上）[/url]
[url=我們應當怎樣做需求分析：業務流程分析（下）[/url]
[url=我們應當怎樣做需求分析：用例說明[/url]
[url=我們應當怎樣做需求分析：查詢報表分析[/url]
[url=我們應當怎樣做需求分析：子用例與擴充套件用例[/url]
[url=我們應當怎樣做需求分析：行**和狀態圖[/url]
[url=我們應當怎樣做需求分析：業務領域分析[/url]
[url=我們應當怎樣做需求分析：原文分析法[/url]
[url=我們應當怎樣做需求分析：領域驅動設計[/url]
[url=我們應當怎樣做需求分析：非功能需求[/url]
[url=我們應當怎樣做需求確認：需求列表[/url]
[url=我們應當怎樣做需求確認：乙個需求列表的例項[/url]
[url=我們應當怎樣做需求確認：快速原型法[/url]
[url=我們應當怎樣做需求確認：需求規格說明書[/url]
[url=我們應當怎樣做需求確認：評審與簽字確認會[/url]
（續）
十二 我們應當怎樣做需求分析 用例說明
當我們進行業務流程分析時，只空對空而不落到紙面上是不可以的。過去，在面向過程的時代，我們繪製dfd圖 流程圖，以及編寫流程說明來描繪這一部分分析 而現在，在物件導向的時代，我們則是繪製行 狀態圖，以及編寫用例說明來完成這部分工作。在這部分工作中，編寫用例說明應當是最主要的工作，之後在一些關鍵部分輔之...
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...