使用案例(Use Case)是一種需求捕捉(Requirement capture)及記錄的技術。
使用案例係利用純文字的紀錄，以敘述性的方式來描述參與者(Actor)使用系統的操作互動過程，最後，系統能滿足參與者使用系統的目的。
在利用文字來記錄使用案例的敘述(Description)之前，我們可能會先利用使用案例圖(Use Case Diagram)來突顯參與者使用系統的目的。利用圖形的表達，以鳥瞰的觀點可以快速的一窺全貌。界定系統的範圍(System Boundary)、找出系統的主要(Primary)及支援(Support)參與者，以及系統所需擔負的責任(亦即，稱之為使用案例)。
使用案例圖是有利於團隊的溝通，這也是人與生俱來的本能：利用圖形的表達往往勝過以文字來溝通的方式。
團隊有了初步對系統整體外觀的瞭解及共識，再由如需求分析師(RA, Requirement Analyst)將橢圓形的使用案例打開，以正確易讀的格式來描述參與者與系統之間對話的過程。
由簡入繁，逐步增加使用案例的精確度(precision)，不要一開始就陷入繁雜的細節，如此才不至於將過多的精神擺在錯誤的設計及描述上。使用案例圖，可以協助由簡入繁、減少不必要的謬誤發生。 參考下圖1。
圖一、使用案例圖範例
從圖中的觀察，很明顯的可以看出，系統的設計範圍為 “網路訂購系統”，使用這個系統的其中一個主要參與者為 “顧客(Customer)”，該參與者使用系統的目的為 “訂購商品(Place Order)”。
“訂購商品” 是系統的使用案例，參與者為 “顧客”。確定了參與者的目的後，再來會以文字敘述的方式來紀錄該目的的細節，也就是紀錄參與者為了達成該目的，而與系統的操作互動過程的情形。這稱為使用案例敘述(Use Case Description)。
一個簡單的 “訂購商品” 使用案例敘述如下表。
| Use Case Name | 訂購商品 |
| Brief Description | 顧客瀏覽欲購買商品資訊，然後把想購買的商品放進購物車(shopping cart)內。當顧客完成商品選購並選擇結帳。系統列出結帳程序，提供顧客選擇付款方式、填寫寄送資訊、選擇出貨方式等。系統確認無誤後，即完成此次訂購商品的交易。 |
| Basic Course of Events |
|
使用案例是由軟體巨擘 Jacobson 於 1992 年率先發表的，對於近代物件導向的技術具有相當大的衝擊。並且由 Booch、Jacobson、Rumbaugh所謂的O-O 三巨頭所聯合制訂並已交由 OMG 審議的 UML(Unified Modeling Language) 規格中，已納為主要的標準規格之重要一環。
這裡列出幾位軟體巨擘們對使用案例的定義。
- “使用案例是一種敘事性的文件，用以描述某個參與者(actor)使用系統完成某個事件的流程順序” [Jacobson92]。
- “使用案例就是一組情節(scenarios)，它們跟系統常見的使用目的互相關連” [Fowler97]。
- “A use case is a sequence of actions that an actor(usually a person, but perhaps an external entity, such as another system) performs within a system to achieve a particular goal” [Rosenberg99]。
“使用案例是一個參與者(actor) (通常是使用者，但或許可以為一個外部的實體, 例如另一個外部系統)，在與內部系統的互動中，來達成一個特定目標的一系列行動”。 - “The Unified Modeling Language User Guide” 一書中，則給予 Use Case 的定義：
“A use case describes a set of sequence, in which each sequence represents the interaction of the things outside the system(its actors) with the system itself(and its key abstractions)”。
“使用案例描述了一連串的循序，每一個循序表達了外部於系統的事物(參與者)與系統本身(及它的關鍵抽象)之間的互動”。
從以上的論述中，可以得到與使用案例相關的特點：
- 使用案例係用自然語言(例如以英文或中文來敘事)來描述的一份敘述性文件，一般而言，使用案例不牽涉以圖形或程式語言的語法(如 java)來描述。
- 使用案例所描述的的情節(Scenario)正是參與者(actor)期望能從與系統的互動溝通當中，來完成(得到)他們的目的(Goal)。
例如 “購買商品(Buy Items)” 正是消費者消費的目的：
”消費者拿購買的貨品結帳，出納員紀錄購買貨品並收取貨款。一旦完成，消費者帶著貨品離開。” - 一個使用案例可以有一個正常的情節，以及多個例外(exception)的情節。正常的情節描述的是參與者與系統的正常互動過程 ; 而在與系統的互動過程中，如果考慮到例外狀況的發生，視狀況的複雜度，可以描述在正常情節內的 ”替代方案內(Alternative Paths)” 或可以對複雜的例外狀況以另一個情節來描述它。
- 系統會提供一連串的功能(function)來與參與者互動，但參與者並不需要知道系統內部作什麼事，或如何作，系統只要把結果傳回給參與者即可。所以，對參與者而言，系統是一個黑箱(Black-box)。
- 使用案例的描述是強調系統應該作什麼(what to do)，而不是如何作(how to do)。所以，對於實作的細節，不應該描述在使用案例的敘述內。
- 參與者(actor)是直接來操作系統的，在使用案例圖中，雖然參與者(actor)被表示成 ”棒形人偶” 的圖示，可是參與者不見得一定就是由人所擔任的角色。參與者也有可能是一個外部的系統，它可能需要從這個系統中得到一些資訊。
Hi Powell:
我一直提醒與強調，UC 不是需求的全部，而是一個很關鍵的需求捕捉技術。
有些假設點，也要能釐清。例如，面對是 Operator 時，我也會如貴公司專案的方式，利用畫面來輔助溝通；而面對如 Stakeholder，利用 UC 又是不同的表達意涵與目的，相對，對於團隊內部的溝通，UC 又有另外的表達目的。
不是”用”得不好，就覺得 UC 不好 “用”；也不是 “用得” 很好，就想要利用某種 UC 用在 “Everywhere”。
這些都會有問題的。
多多開拓自己的視野，多多懂得從各種角度思考，不要被侷限在現況，而沒看到更廣的視界。
其實，我才剛開始接觸UML…所以對於Use Case有一些些初學者的想法。總覺得用『文字』去『詳細』敘述使用者要『作』什麼似乎不是那麼貼切現實的狀況。
我們專案目前的做法是把使用者操作的畫面+牽涉到的資料格式型態+按下某些按鈕所預期出現的畫面作成使用者需求文件。我也嘗試過使用Use Case式的文字描述，但是當我拿給PG或是User看的時候，發現還是用操作畫面比較好『溝通』….當然，如果有文字敘述更好…但是，那是在有充裕時間的前提下…。
還是非常感謝您詳細生動的說明，對於剛學UML的我，有很大的幫助。