1.1
為什麼要使用用例
?用例提供了一種用於構建故事的半形式框架； ?
在每個用例和所有描述層次中，用例都描述了錯誤情況的系統需求； ?
雖然本質上是一種功能分解技術，但用例已經成為物件導向軟體開發的乙個流行元素； ?
用例提供了可以在其上處理其他專案資訊的骨架：
專案經理根據用例進行估計和發布進度；
資料及業務規則制定人員可以把自己的需求和所需用例聯絡起來；
使用者介面設計人員可以進行設計，並將其與相關用例聯絡起來；
測試人員可以根據用例中描述的成功和失敗情況構建測試場景（測試用例）；
1.2編寫用例容易出現的問題
?使用者介面太多，使用者介面應屬於設計範疇，滑鼠、按鍵等內容不應出現在用例中； ?
較低目標層次上的用例太多，無法展示系統將會給其終端使用者提供什麼功能； ?
使用用例表示非行為資訊，效能需求、業務規則等不要在用例中描述； ?
太冗長，最好在
3~9步； ?
目標實現不完整，尤其是錯誤處理； ?
句子片斷，主、謂、賓盡量完整；
1.3為什麼使用用例模式語言
描述了用例的質量標誌及其編寫過程，提供了能夠經受時間考驗的用例改進建議；在評審用例初稿和改進其質量的過程中，這個工具能起到很大作用。
1.4
什麼是模式
模式是質量標誌和策略；
1.5
使用模式語言時錯誤觀念
?模式提供了乙個關於其自身和模式內容的完整方法；只起補充作用
?使用模式肯定會成功； ?
模式為老問題提供了新的解決方案；只是經常出現的問題的通用可靠方案
?模式適用於所有情況；僅是處於某種上下文中的問題的解決方案
1.6
模式組織
模式分類
子類開發模式
團隊組織：判斷和改進用例團隊組織方式的質量的模式；
過程：判斷和改進團隊用來建立用例的方法質量的模式；
編輯：隨著潛在需求的變化和編寫人員知識的增加，判斷和改進單個用例的質量；
結構模式
用例集：判斷和改進用例集質量的模式；
用例：判斷和改進單個用力質量的模式；
場景和步驟：判斷和改進用力場景以及這些場景中的步驟質量的模式；
用例關係：判斷和改進集合中用例之間的結構關係質量的模式；
1.7
用例的讀者和編寫者
有兩組不同的認閱讀和使用用例：（
1）終端使用者或業務專家；（
2）程式設計師。
用例編寫組必須包括： ?
至少一位具有程式設計背景的認，以獲得描述所要求的準確性和精度； ?
至少一位熟知業務規則的認； ?
至少一位熟知在實際中如何使用系統的認；
有效用例模式學習筆記（二）
2.1 smallwritingteam 原因 用例要求具有不同觀點和專業知識的人編寫 將一大組人聚集在一起是困難的 理論上，在用例上投入的人越多，就能越快的完成用例編寫工作 大的團隊會變得低效 大型編寫團隊可能會通過集體討論的形式開發用例，新增許多不必要的特性 所以 乙個由2人或 3人組成的團隊足...
有效用例模式（四）
用例集模式是編寫一組良好用例的質量標誌。4.1 sharedclearvision 願景共識 缺乏乙個清晰的系統願景可能會導致優柔寡斷，涉眾之間不能達成一致意見，並可能很快就使專案癱瘓。原因 時間壓力可能會使人過早的開發系統，他們的工作建立在錯誤的基礎之上，使其步入正軌的代價可能會非常昂貴 構建人員...
《編寫有效用例》
1 完整正式的用例格式 1 單列文字 不是乙個 2 步驟編號 3 沒有條件語句 4 擴充套件部分的編號規則是數字和字母的組合 完整正式的用例模板 名字 用例名應該是乙個用主動語態動詞短語來表示的用例目標 使用語境 目標較長的描述，如果需要，還包括觸發事件 範圍 設計範圍，在設計時將系統作為乙個黑盒來...