看看System Use Case的例子，“從數據庫中查詢低庫存的”它太小了，容易跟需求的實現細節混淆。對比一下，作為System Use Case，“倉庫管理”就太大了，它不能實現作為沒有大的分支的行為的單一線索的原則，并且從系統的觀點來說，它很難說明成功的目標，但它可以做為一個好的Business Use Case，對于配件部門來說，它可以定義“倉庫管理”這一成功的目標（可能是根據庫存調整、配件驗收、成本操作等）。
這些Business Use Case的好處是它們能用于區分其它的Use Cases，就如：“倉庫管理”可用于組織這些用于實際管理倉庫的Use Cases。
Use Cases的正式定義
Use Case：特殊行為者（Actor）的價值的量化結果的提交
正如前面所說的，Actors可以是人也可以是正在設計的系統與之交互的外部系統，一個Use Case要求有一個量化的結果，從單個線索的需要提交。做為量化結果的組成，目標要么成功要么失敗，沒有其它的情況。
達到主要Actor的目標定義為成功，結果沒有迎合主要Actor的目標定義為失敗，不同的情節顯示了成功或失敗的途徑。
Use Cases的說明
Use Cases的好處是一些情節能用不同程度的正規化的文字說明。每個情節涉及Use Cases中單一的途徑，細節是條件組。
不正規的文本描述也能使用，不過當條件較多和可能失敗的情況下它們很難跟隨下去。開始試圖理解需求時，不正規的敘述風格也是非常有用的，然而隨著Use Cases的進展，使用更加正規的機制去說明Use Cases才是有用的。
下面是客戶對Use Case“下定單”的粗略概略：
“確定客戶，找出需要的并且倉庫里還有的物品并檢查客戶信用額是否夠用”
結構化敘述的格式已經被證明是非常有效的。這個格式所做的事是描述每一個情節的行為者：目標語句對的順序。在這個順序中，每一個行為者：目標的語句對都假設前一個的目標是成功的，右面是一個簡單的范例：
Use Cases認為我們正在設計的系統是一個單一的黑盒，根本沒有任何內部結構被記錄下來，并且它被認為是一個情節產生的目的及對應單一的行為者（Actor）。這些Use Cases沒有表示任何關于系統內部的東東，只是表示系統將達到什么樣的目標及由什么（人或其它系統）操作和負責。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
