從參與者的角度并以主動語態編寫用例。

　　應該以主動語態：“學生表明參加研習班意向”，而不是被動語態“研習班意向被學生表明”來編寫用例。而且，應該從參與者的角度來編寫用例。畢竟，用例的目的是理解用戶如何對系統進行操作。

　　編寫方案文本，而非功能需求。

　　用例描述的是對參與者來說有價值的一系列行動，而不是特性集。例如，“招收研習班的學生”用例描述的是學生如何與系統交互來參加研習班。它沒有描述用戶界面看上去是什么樣子，或者它是如何工作的。有一些其它的模型來描述這些重要的信息，例如用戶界面模型和增補規范。面向對象分析非常復雜，因此需要對它使用幾種模型，并且應該適當地應用每一種模型。

　　用例只記載行為需求。

　　用例既不是類規范，也不是數據規范。這是應該由概念性模型捕捉的一種信息，在對象世界中，它是通過 UML類模型建模的。您往往會引用概念性模型中描述的類，例如，“參加研習班”用例包括了“研習班”和“學生”等概念，它們都將由概念性模型描述。

　　不要忘記用戶界面。

　　系統用例經常引用主用戶界面 (UI)元素，這些元素常常稱為“邊界”或“用戶界面”項，例如 HTML頁面和報表。用例有時也引用一些次要的 UI元素，例如按鈕或數據輸入字段，但這種級別的細節并不太常見。

　　創建用例模板。

　　用例包含了相當數量的信息，這些信息可以輕易地以常見格式記載。您應該考慮開發自己的模板(請參閱技巧“ 記載用例”)。

　　始終如一地組織用例圖。

　　一般的做法是垂直地繪制繼承 (inheritance) 和擴展 (extend)關聯，在父/基本用例下面繪制繼承/擴展用例。同樣，通常水平繪制包含(include) 關聯。請注意，這些是簡單的經驗法則 —只要始終遵循這些法則，產生的圖將很容易理解。

　　不要忘記系統對參與者行動的響應。

　　用例既應該描述參與者是如何與系統交互的，也應該描述系統如何響應這些交互。例如，在“參加研習班”用例中，如果系統在學生表明他們希望參加研習班時沒有做出響應，學生就會很沮喪地離開。

原文轉自：http://www.anti-gravitydesign.com