有效的用例編寫規則

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

1.1 為什么要使用用例

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

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

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

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

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

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

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

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

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

用戶界面太多，用戶界面應屬于設計范疇，鼠標、按鍵等內容不應出現在用例中；
較低目標層次上的用例太多，無法展示系統將會給其最終用戶提供什么功能；
使用用例表示非行為信息，性能需求、業務規則等不要在用例中描述；
太冗長，最好在3~9步；
目標實現不完整，尤其是錯誤處理；
句子片斷，主、謂、賓盡量完整；

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

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

1.4 什么是模式

模式是質量標志和策略；

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

模式提供了一個關于其自身和模式內容的完整方法；只起補充作用
使用模式肯定會成功；
模式為老問題提供了新的解決方案；只是經常出現的問題的通用可靠方案
模式適用于所有情況；僅是處于某種上下文中的問題的解決方案

1.6 模式組織

1.7 用例的讀者和編寫者

有兩組不同的認閱讀和使用用例：（1）最終用戶或業務專家；（2）程序員。
用例編寫組必須包括：
至少一位具有編程背景的認，以獲得描述所要求的準確性和精度；
至少一位熟知業務規則的認；
至少一位熟知在實際中如何使用系統的認；

第二章 團隊

2.1 SmallWritingTeam

原因：

用例要求具有不同觀點和專業知識的人編寫；
將一大組人聚集在一起是困難的；
理論上，在用例上投入的人越多，就能越快的完成用例編寫工作；
大的團隊會變得低效；
大型編寫團隊可能會通過集體討論的形式開發用例，添加許多不必要的特性；

所以：

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

可以使用幾個SmallWritingTeam，但應當制定一位用例設計師，以保證所有用例與愿景一致。
最終目的是使過程保持在可管理狀態，大的團隊將在管理上投入更多的精力。

2.2 ParticipatingAudience

沒有涉眾提供的信息和反饋，就不能滿足他們的需要；盡可能使客戶和內部涉眾積極參與用例開發過程。

2.3 BalancedTeam

由一些個性相似、意見相同的個人組成的團隊開發用例，可能會得到一組缺乏創見、范圍狹窄的用例，這種用例不能滿足每個人的需要。

因此，為小組配備具有不同專長的人員，以維護開發過程中涉眾的利益，確保團隊中包括開發人員和最終用戶。
最大好處是使編寫人員在用例中使用常見的、可理解的術語。

第三章 過程

編寫好的用例是極其個性化的，每個人都有他自己的風格，每個組織都有根據自己的文化和業務需要做事情的方式，因此，沒有創建用例的通用過程。

3.1 BreadthBeforeDepth

原因：

需求收集是一個發現過程，用例編寫是一個迭代過程；
人們很早就開始編寫用例的細節；
人們浪費了精力或陷入了太多的細節，通常都會失去重點，無法描述所有可能的擴展條件；
從早期獲得概述是有益的；
最初編寫的細節越多，在了解系統后必須進行的改變也就越多；

所以：

通過首先開發用例的概述來保存精力，然后逐步增加細節，并行開發一組相關用例。

完成概述用例后，隨著對系統了解的增多，不斷提高用例精度，避免突然開發完所有用例或一次只開發一個用例的傾向。

3.2 SpiralDevelopment（螺旋式開發）

原因：

理解系統的行為可能會花掉大量時間，要求漸進式分析；
拖延是昂貴的。要盡快完成用例的編寫；
對需求進行分析后，需求很可能會發生變化；
需求成本的錯誤是昂貴的；

所以：

以一種迭代的，寬度優先的方式開發用例，每次迭代都會提高用例集的準確性和精度。

基本過程：

從簡單的東西開始，如一個參與者/用例列表；
簡要描述用力主場景，即高層用例，以包含用例的主要范圍；
擴展摘要的子集，并填充細節；
評審并調整；

3.3 MultipleForms

不同的項目需要不同程度的形式化，每個人對模板都有不同的偏好，要求每個人都使用相同的用例模板只會起到相反的作用。

原因：

每個人的個性、經驗和經受的鍛煉不同，每個開發組織都有其特有的人員、歷史和文化；
不同的項目有不同的需要；
不同的編寫團隊需要不同程度的規范和嚴格度；
在組織中使用公共的編寫形式有助于交流；
在同一個項目上使用不同的模板不是一個好主意；

因此：根據項目相關的風險性、項目特點，和所涉及到的人員選擇用例的編寫格式，并在該項目的開發過程中的組織內部使用。

3.4 TowTireReview（評審）

許多人都可能需要評審用例，這是一件昂貴耗時的事情。

原因：

對于驗證和確認編寫及內容來說，評審是必要的；
涉眾在用例上有一種既得利益；
使每個人參與編寫過程非常昂貴、麻煩并且緩慢；
如果僅由一個小的編寫組進行評審，就不會考慮所有涉眾的利益；
評審可能是昂貴的、乏味的、耗時的。

所以：

進行兩種類型的評審：第一種是由較小的內部小組進行的評審，可能要重復進行很多次；第二種是由整個團隊進行的評審，可能只進行一次。

3.5 QuittingTime

開發一個超出了涉眾和開發人員需要的用例模型不僅浪費資源，而且會拖延項目進度。

原因：

忽視重要需求的巨大恐懼使構建人員和涉眾延長了需求收集活動；
大多數人可以用一種合理的模糊性工作，即不言自明；
詳細講述謊言并不能使他們更為精確；

所以：

在用例完整并且符合參與者的需要后，停止開發用例；
用例模型完整性的檢驗：完整、可讀、邏輯上正確、對開發人員足夠詳細。
是否識別了所有的參與者和目標并將其編成了文檔？
客戶及其代表是否承認用例集是完整的，而且每個用例都是可讀的和正確的？
設計人員是否能夠實現這些用例？

3.6 WriterLicense

小的格式差別并不重要，解決了所有系統問題后，及時還存在一些格式問題，也可以停止編寫；

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