盡管這些用例的概念自從二十多年前就已經生成，實際上許多軟件從業者從沒使用過它們或者甚至從來沒有了解過他們。業務轉型方法論越來越普遍，這很大程度上取決于過程規則，其實正在改變這個狀況。普遍的工具比如 IBM Rational RequisitePro®(用來支持 RUP) 結合用例的生成作為需求定義過程的一部分。UML 的引入為軟件描述設定了標準，已經進一步促進了用例的采用。
用例主要強調涉眾需要這個系統交付什么，而不是描述如何實現最終的結果。用例采用“黑盒”接近這個系統。 2 它應該陳述將要發生什么行為，但是并不陷入關于行為如何被實現的具體細節中。將一個用例看作是來自參與者觀點導向的結果。只要結果被實現，這個參與者實際上并不真正在意這個行為是怎樣執行的。因此，一個用例必須代表支持對參與者有重要價值的結果。
UML 將一個用例定義為“一個系統執行的一系列行為的描述，包括變量，它將生成特殊參與者所得值的可觀測結果�！� 3 當決定一個用例的構成時，這個“價值”的概念十分重要。如果您不想識別這個將由參與者識別的具體值，那么這個行為可能對一個用例來說就不是一個很好的候選。 4
一個用例可以是圖形的，也可以是文本的，但理論上兩者都是用例。 5 用例可以創建為只讀文本的格式，但是最初都儲存在像 Microsoft Word 這樣的工具中。長期以來，在用例圖中以圖形的格式表示就變得越來越普遍。使用 UML 和支持 RUP 的工具來構建用例模型是最為常見的方法。這樣的工具支持文本描述和支持圖的多樣性，從而更好地圖解化此系統是如何被使用的。
用例圖經常被分組來顯示涉眾們的需求集合（請看圖 1中的例子）。在這個圖中，任何一個直接與系統聯系的單位通常都被看作是一個“參與者”。一個參與者可以是一個人或者代表一個或者多個人的角色。它還可以是另一個計算機系統。一個參與者通常由一個“人性圖標”代表，即使當這個參與者是另一個計算機系統時也是這樣。每個用例都由一個橢圓形代表，用描述這個用例將要執行什么樣的行為的說明型陳述進行標注。這個陳述作為這個用例的名稱。它應該簡潔，但是描述的行為應該被執行。還可以繪制溝通連線來顯示參與者與用例之間的關系。
圖 1：用例圖
文章來源于領測軟件測試網 http://www.k11sc111.com/
