有效的用例編寫規則

　　第一章 什么是高質量的用例

　　1.1 為什么要使用用例

　　用例提供了一種用于構建故事的半形式框架;

　　在每個用例和所有描述層次中，用例都描述了錯誤情況的系統需求;

　　雖然本質上是一種功能分解技術，但用例已經成為面向對象軟件開發的一個流行元素;

　　用例提供了可以在其上處理其他項目信息的骨架：

　　項目經理根據用例進行估計和發布進度;

　　數據及業務規則制定人員可以把自己的需求和所需用例聯系起來;

　　用戶界面設計人員可以進行設計，并將其與相關用例聯系起來;

　　測試人員可以根據用例中描述的成功和失敗情況構建測試場景(測試用例);

　　1.2 編寫用例容易出現的問題

　　用戶界面太多，用戶界面應屬于設計范疇，鼠標、按鍵等內容不應出現在用例中;

　　較低目標層次上的用例太多，無法展示系統將會給其最終用戶提供什么功能;

　　使用用例表示非行為信息，性能需求、業務規則等不要在用例中描述;

　　太冗長，最好在3~9步;

　　目標實現不完整，尤其是錯誤處理;

　　句子片斷，主、謂、賓盡量完整;

　　1.3 為什么使用用例模式語言

　　描述了用例的質量標志及其編寫過程，提供了能夠經受時間考驗的用例改進建議;在評審用例初稿和改進其質量的過程中，這個工具能起到很大作用。

　　1.4 什么是模式

　　模式是質量標志和策略;

　　1.5 使用模式語言時錯誤觀念

　　模式提供了一個關于其自身和模式內容的完整方法;只起補充作用

　　使用模式肯定會成功;

　　模式為老問題提供了新的解決方案;只是經常出現的問題的通用可靠方案

　　模式適用于所有情況;僅是處于某種上下文中的問題的解決方案

　　1.6 模式組織

　　1.7 用例的讀者和編寫者

　　有兩組不同的認閱讀和使用用例：(1)最終用戶或業務專家;(2)程序員。

　　用例編寫組必須包括：

　　至少一位具有編程背景的認，以獲得描述所要求的準確性和精度;

　　至少一位熟知業務規則的認;

　　至少一位熟知在實際中如何使用系統的認;

　　第二章 團隊

　　2.1 SmallWritingTeam

　　原因：

　　用例要求具有不同觀點和專業知識的人編寫;

　　將一大組人聚集在一起是困難的;

　　理論上，在用例上投入的人越多，就能越快的完成用例編寫工作;

　　大的團隊會變得低效;

　　大型編寫團隊可能會通過集體討論的形式開發用例，添加許多不必要的特性;

　　所以：

　　一個由2人或3人組成的團隊足夠小，容易交流和達成一致;

　　可以使用幾個SmallWritingTeam，但應當制定一位用例設計師，以保證所有用例與愿景一致。

　　最終目的是使過程保持在可管理狀態，大的團隊將在管理上投入更多的精力。

原文轉自：http://www.uml.org.cn/Test/200705175.asp