我個人一向主張寫 Use Case 的敘述之前，先畫使用案例圖(Use Case Diagram) 。原因在於我們可以從鳥瞰的視野綜觀系統的全貌：

1. 可以利用套件(Package)界定系統的設計範圍(Boundary)。
2. 避免過早涉及至細節(Detail)。

先說明，什麼是鳥瞰？

• 從高處俯視低處。
• 對事實情況作概略的觀察。

利用使用案例圖，可以協助我們從 "鳥瞰" 的視野來看系統的外觀，避免從系統的內部來看 Use Case (這是許多 Developer 常犯的毛病)。
同時，因為鳥瞰，所以，比較容易能看出系統的全貌、界定系統的範圍、區分系統的內與外(這很重要，如此才能知道什麼該作，什麼不需作)。還有，也比較容易看出使用案例的所表達的層次(level)，如企業層級(Business level)、使用者目標層級(User-goal level)等。

寫使用案例若不知道系統的設計範圍，我很難相信 RA(Requirement Analyst)能寫得好 Use Case。
理由為何？若未能確定系統邊界，那麼，你如何能將系統視為一個黑箱(Black box)？你又如何能確認誰是使用系統的主要參與者(Primary Actor)？

而 Developer 常常以為很清楚系統範圍，但事實上系統範圍的界定在團隊成員之間往往會有見解上的落差。
例如，觀察下圖一，顧客至錄影帶店租片，很直覺地，我們發現有個 Use Case：租片 。

圖一、使用案例圖(沒有以Package界定範圍)

沒有畫出系統邊界，一般是常見於單一系統的開發，且系統的範圍很明確。但我們觀察圖一，試著問問團隊內部的開發成員們，她們所認知的系統是界定在那個範圍呢？
可能會以為，不就是要開發一個影片租借系統嗎？

我們來反思，顧客會直接去 "使用" 軟體應用系統嗎？不然吧，直接使用系統的實際參與者(Actor)是錄影帶店的櫃臺人員。

所以，若把圖一的系統範圍界定於 "影片租借系統"，Actor 是 "顧客"，Use Case 是 "租片"，其實是大有問題的。

實際上，圖一的使用案例圖是屬於 "企業層級(Business level)" 的 Use Case，偏向於描述企業的流程，而非操作系統功能面的 "使用者目標(User-goal level)" 層級的 Use Case。
系統界定的範圍一般以企業為單位，如下圖二。

圖二、 企業層級的使用案例圖

圖二是以百X達為系統的範圍，內部包括了 "內部的工作者(internal worker)"，如店長、櫃臺人員；同時也可能包括了如影片租借、會計、人事等軟體應用系統。
所以，是不是百X達所有的內部的系統均是由同一個開發團隊來開發的？還只是負責開發其中單一個子系統呢？

很有可能，只是承包 "影片租借系統" 的開發。那麼，顯然，主要參與者就不是顧客了，而是實際操作系統的櫃臺人員；使用系統的 "Goal" 也不是 "租片"，而是成為 "處理租片" 的 Use Case 了。如下圖三。

圖三、 影片租借系統的使用案例圖

我們可以發現，因為系統的範圍很明確的界定在 "影片租借系統"，所以，當系統若是接受是以信用卡刷卡的方式付款，那麼，系統就需要連到外部銀行的系統，此時，銀行的外部系統就成為 "影片租借系統" 的 "Supporting Actor" 了。

圖三所表達的使用案例圖，其層次是偏於 "使用者目標等級"。亦即，當 RA 要寫 Use Case 敘述時，所訪談的 Actor，大部分是直接操作系統的使用者(Operator)，如櫃臺人員。而圖二企業層級的使用案例圖，所訪談的主要對象不是主要的參與者：顧客，反而是制訂企業案例流程的利益關係人(Stakeholder)了。

企業層級的使用案例圖，著重於描述企業內部的流程；非著重於描述系統的行為。通常會以白箱式(White-box)的作法打開企業內部，以瞭解內部 internal worker的互動情形。

而使用者目標等級的使用案例圖，是經常最被討論的層次。系統範圍經常是指軟體應用系統，為滿足主要參與者(Primary Actor)來使用系統的目的。而通常是使用者在某一段時間(3~30分鐘)操作系統後所完成的目標。
在此一層次，我們會以”黑箱(black-box)”的方式來描述使用案例，瞭解參與者與系統之間的互動(或稱之為對話)關係。

利用使用案例圖，協助我們確定及界定了系統的廣度(系統範圍)與深度(系統層次)，可以讓我們看到 "誰(Actor)"來使用系統，以及系統要作的"事(系統行為或稱之為系統責任)。然後再進一步去瞭解 Use Case 的敘述，紀錄 參與者 與 系統 之間的操作對話的互動過程。
再更進一步，才去設計系統內部是如何 "實現(Realize)" Use Case。

由整體、全貌的觀照，找出及界定系統的範圍，然後將焦點擺在橢圓的 Use Case， 釐清參與者的目的(Goal)。再來才是寫出正確易讀的 Use Case 敘述，瞭解參與者與系統之間對話的過程。
由簡入繁，逐步增加使用案例的精確度(precision)。不要一開始就陷入繁雜的細節，如此才不至於將過多的精神擺在錯誤的設計及描述上。

使用案例圖， 就是協助你由簡入繁、減少不必要的謬誤發生。