當我們利用使用案例圖界定了系統設計範圍(Boundary)後，
同時也找出主要參與者(Primary Actor)及其對系統的期望(Goal)。
參考下圖一。
圖一、ATM系統的使用案例-提款
圖一說明了系統必須對 "顧客" 提供 "提款" 的功能。從顧客的角度來看，系統被視為黑箱(Black-box)。系統是如何實現(Realize) "提款" 的功能，顧客並不需要知道，他只要系統能滿足及確保其利益即可。
從圖一，我們可以很明確地看出來參與者使用該系統的目的，不過，參與者為了達成該目的，會有一連串的操作系統過程，這些過程稱之為 "動作步驟"
。從使用案例圖並無法看出參與者與系統之間的互動過程。互動過程的描述，我們會以使用案例(Use Case)來記錄。
使用案例的內容，就在於描述參與者與系統間一段的互動過程，以達成參與者的某個目的。一般其內容的描述，我們是以文字來表達，畢竟，文字可說是最通用、簡單的溝通工具。
文字是最容易溝通、表達的工具，但，相對地，寫使用案例的敘述，要能寫得易讀流暢，不是一件簡單的事。
RA(Requirement Analyst)在寫使用案例時，最常見的一個問題，在於無法明確描述某個動作步驟到底是由誰來負責，是 "參與者"，還是 "系統" 所做的事呢？ 另外，何時需要描述到系統內部的動作，但又不能描述太多系統內部的細節(請記得，使用案例一直是將系統視為一個整體(whole)，是一個黑箱(Black-box)，原則上只專注在系統外觀上的行為描述)，這是個為難之處。
還有，若我想先將焦點專注於參與者與系統之間互動的描述，而且是針對正常的情節(Normal Scenario)，同時又能減少上述兩個問題的發生，我發現到，利用循序圖(Sequence Diagram)來表達參與者與系統之間的互動，是蠻理想的。
這還有個好處，在寫正式格式的使用案例之前，架構師(Architect)或 PM(Project Manager)可以快速檢驗 RA 寫使用案例的正確性。而且，參考該循序圖，也可以快速建構原型(Prototype)，可能是以表單元件(Form Component)、控制物件(Control Object)、功能測試碼等諸多實做方式，以簡單的程式碼來檢視系統所提供參與者的基本功能(人們往往喜歡眼見為憑，有程式碼的執行，會安心許多)。
循序圖，一般是被用來表達系統內部物件之間的互動合作。在這裡，是把 "系統" 視為一個整體(whole)，所以，只有一個物件："系統"。這也代表了，我們只描述到系統邊界的行為，至於系統內部是如何被實做，我們仍未涉及至細節的結構設計。
參考下列範例圖二，上方實線橢圓代表系統要做的 "事(do what)"；下方虛線橢圓代表系統要如何(how-to) "實現(Realize)" 橢圓的使用案例。
圖二、Use Case Realization 的語法表達
系統要如何實現該使用案例，必須知道參與者與系統之間的互動關係，利用循序圖所表達的範例下圖三。
圖三、利用循序圖描述參與者與系統的互動關係
從圖三，可以觀察幾點系統的特性：
- 系統擔負實現(Realize) “提款” Use Case 的責任。
- 從圖三每一條的動作步驟，代表了要傳送的訊息(Message, 以實線表達))以及回傳的資訊(以虛線表達)，箭頭表達了傳送的方向。所以可以很清晰明確的瞭解那個動作步驟是由誰負責的。例如，動作步驟 3 是由系統所負責的行為。
- 為確保及滿足關係人的利益，系統需描述出其系統私有動作。
- 證實用動作。例如，上圖動作3(保障)，系統證實輸入密碼無誤。
- 內部狀態變化。例如，上圖動作7(滿足),系統更新顧客餘額。
- 從圖三仍未能看出系統是如何實做 ”提款” UC(未描述系統內部的結構)。亦即，未來系統的實做是以2-tier、3-tier或物件導向等方式尚未決定。
- Actor 與系統的對話(Dialogue)過程期間(Session)，系統必須保存其對話過程的狀態(State)，亦即，從 Actor 的角度來看待系統時，系統為 “Stateful”。(但不代表系統內部所參與的物件均必須為 Stateful)。
- 再次強調，Use Case 與物件導向沒有直接關聯，但會是導入物件導向技術重要的需求捕捉關鍵技術。