第一章 什麼是高質量的用例
1.1 為什麼要使用用例
用例提供了一種用於構建故事的半形式框架；
在每個用例和所有描述層次中，用例都描述了錯誤情況的系統需求；
雖然本質上是一種功能分解技術，但用例已經成為物件導向軟體開發的乙個流行元素；
用例提供了可以在其上處理其他專案資訊的骨架：
專案經理根據用例進行估計和發布進度；
資料及業務規則制定人員可以把自己的需求和所需用例聯絡起來；
使用者介面設計人員可以進行設計，並將其與相關用例聯絡起來；
測試人員可以根據用例中描述的成功和失敗情況構建測試場景（測試用例）；
1.2 編寫用例容易出現的問題
使用者介面太多，使用者介面應屬於設計範疇，滑鼠、按鍵等內容不應出現在用例中；
較低目標層次上的用例太多，無法展示系統將會給其終端使用者提供什麼功能；
使用用例表示非行為資訊，效能需求、業務規則等不要在用例中描述；
太冗長，最好在3~9步；
目標實現不完整，尤其是錯誤處理；
句子片斷，主、謂、賓盡量完整；
1.3 為什麼使用用例模式語言
描述了用例的質量標誌及其編寫過程，提供了能夠經受時間考驗的用例改進建議；在評審用例初稿和改進其質量的過程中，這個工具能起到很大作用。
1.4 什麼是模式
模式是質量標誌和策略；
1.5 使用模式語言時錯誤觀念
模式提供了乙個關於其自身和模式內容的完整方法；只起補充作用
使用模式肯定會成功；
模式為老問題提供了新的解決方案；只是經常出現的問題的通用可靠方案
模式適用於所有情況；僅是處於某種上下文中的問題的解決方案
1.6 模式組織
模式分類 子類
開發模式
團隊組織 ：判斷和改進用例團隊組織方式的質量的模式；
過程 ：判斷和改進團隊用來建立用例的方法質量的模式；
編輯 ：隨著潛在需求的變化和編寫人員知識的增加，判斷和改進單個用例的質量；
結構模式
用例集 ：判斷和改進用例集質量的模式；
用例 ：判斷和改進單個用力質量的模式；
場景和步驟 ：判斷和改進用力場景以及這些場景中的步驟質量的模式；
用例關係 ：判斷和改進集合中用例之間的結構關係質量的模式；
1.7 用例的讀者和編寫者
有兩組不同的認閱讀和使用用例：（1）終端使用者或業務專家；（2）程式設計師。
用例編寫組必須包括：
至少一位具有程式設計背景的認，以獲得描述所要求的準確性和精度；
至少一位熟知業務規則的認；
至少一位熟知在實際中如何使用系統的認；
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
小的格式差別並不重要，解決了所有系統問題後，及時還存在一些格式問題，也可以停止編寫；
《編寫有效用例》
1 完整正式的用例格式 1 單列文字 不是乙個 2 步驟編號 3 沒有條件語句 4 擴充套件部分的編號規則是數字和字母的組合 完整正式的用例模板 名字 用例名應該是乙個用主動語態動詞短語來表示的用例目標 使用語境 目標較長的描述，如果需要，還包括觸發事件 範圍 設計範圍，在設計時將系統作為乙個黑盒來...
編寫有效的業務用例 讀書筆記06
第十一章 用例格式 1 完整正式的用例格式 1 單列文字 不是乙個 2 步驟編號 3 沒有條件語句 4 擴充套件部分的編號規則是數字和字母的組合 完整正式的用例模板 名字 用例名應該是乙個用主動語態動詞短語來表示的用例目標 使用語境 目標較長的描述，如果需要，還包括觸發事件 範圍 設計範圍，在設計時...
編寫有效的業務用例 讀書筆記03
第五章 三個命名的目標層次 1 使用者目標 藍色，海平面 user goal 它是主執行者努力使工作得以完成的目標，或是使用者使用系統的目標。它相當於業務過程工程中的 基本業務過程 2 概要層次目標 白色，雲朵，風箏，summary level goal 包含多個使用者目標。在描述系統時，他們有如下...