用例集模式是編寫一組良好用例的質量標誌。
4.1 sharedclearvision
（願景共識）
缺乏乙個清晰的系統願景可能會導致優柔寡斷，涉眾之間不能達成一致意見，並可能很快就使專案癱瘓。
原因：時間壓力可能會使人過早的開發系統，他們的工作建立在錯誤的基礎之上，使其步入正軌的代價可能會非常昂貴；
構建人員有一種擴充套件系統範圍的自然傾向；
涉眾之間有一些相互衝突的願景；
專案目標不清晰；
開發人員之間缺乏交流；
所以：準備乙份清晰描述系統目標的陳述，確保其支援組織的使命，並將其直接分發給參與專案的每個人。
願景陳述應該包括：
?系統目標； ?
系統將解決的問題； ?
系統不會解決的問題； ?
涉眾是誰； ?
系統將如何使涉眾受益；
4.2 visibleboundary
（可見的邊界）
如果不知道系統的邊界，系統的範圍就會以一種不可控制的方式增長。
原因：對於系統邊界，不同的人有有不同的觀點；
定義糟糕的邊界會導致範圍的蠕變，開發人員喜歡新增某些不會給系統帶來好處的特性；
有些人認為定義邊界時不必要的；
所以：通過列舉與系統互動的人員與裝置，在系統與其環境之間建立乙個可見的邊界；
開發的早期階段，由於系統的願景並不清晰，系統邊界可能是模糊的，先確定乙個系統邊界，變成文件，然後隨著開發的深入，對其進行spiraldevelopment。
上下文圖：
系統 終結器
終結器終結器
終結器4.3 clearcastofcharacters
（清晰識別角色）
如果僅分析系統的使用者，而忽視他們在系統中所扮演的角色，就可能會遺漏重要的系統的行為或引入冗餘的行為。
原因：系統必須滿足其使用者的需要並保護其涉眾的利益，這樣的系統才是有用的；
把服務和某些使用者綁在一起可能會使系統變得非常死板；
主體專家的狹窄焦點或視野可能會使我們漏掉使用者要求的服務；
將焦點放在使用者身上可能會使我們糾纏於實現細節，而不是提供對使用者所需要的服務的理解；
時間壓力和權宜之計鼓勵我們僅對使用者進行分析；
所以：識別系統必須與之互動的參與者，以及每個參與者和系統互動時所扮演的角色，並清晰描述每個參與者。
4.4 uservaluedtransactions
如果系統不能為其使用者提供有價值的服務，不支援系統願景所規定的目的和目標，那麼系統就是不完善的。
原因：乙個編寫良好的用例應該清晰準確的描述系統提供的基本功能，該資訊能夠使客戶在構建系統前察看它，以確定系統是否提供了他們認為有價值的服務； 識別
低層的事務
相對來說是容易的，但識別
有價值的服務
就難了；
在乙個足夠高的級別編寫用例，可以保證用例相對穩定；在太高
的級別上編寫用例，對系統開發人員毫無用處；在太低
的級別上編寫用例；難以從高的層次上理解系統；
所以：識別系統為參與者提供以滿足其業務目的的有價值的服務；
避免基於表單的用例集；
4.5 everunfoldingstory
描述系統的行為所需的步驟已經超出了所有讀者的記憶和興趣範圍。
原因：不同的涉眾從不同的角度看待系統；
每個用例都有可能有許多讀者和很多使用方式，它們需要不同的詳細級別；
在多個層次編寫用例會讓人感到混亂；
編寫人員需要遵循乙個原則來對需求進行組織；
所以：將一組用例組織為分層故事的形式，可以將其展開獲得更多的細節，也可以將其摺疊起來隱藏細節，顯示更多的上下文；
三個級別用例：
l概要級：需要用多個使用者目標會話來完成；
l使用者目標級：滿足了主參與者當前的特定價值目標，一般由乙個主參與者在乙個位置執行；
l子功能級：滿足了使用者目標級用例或另乙個子功能的部分目標；
有效用例模式學習筆記
1.1 為什麼要使用用例 用例提供了一種用於構建故事的半形式框架 在每個用例和所有描述層次中，用例都描述了錯誤情況的系統需求 雖然本質上是一種功能分解技術，但用例已經成為物件導向軟體開發的乙個流行元素 用例提供了可以在其上處理其他專案資訊的骨架 專案經理根據用例進行估計和發布進度 資料及業務規則制定...
有效用例模式學習筆記（二）
2.1 smallwritingteam 原因 用例要求具有不同觀點和專業知識的人編寫 將一大組人聚集在一起是困難的 理論上，在用例上投入的人越多，就能越快的完成用例編寫工作 大的團隊會變得低效 大型編寫團隊可能會通過集體討論的形式開發用例，新增許多不必要的特性 所以 乙個由2人或 3人組成的團隊足...
《編寫有效用例》
1 完整正式的用例格式 1 單列文字 不是乙個 2 步驟編號 3 沒有條件語句 4 擴充套件部分的編號規則是數字和字母的組合 完整正式的用例模板 名字 用例名應該是乙個用主動語態動詞短語來表示的用例目標 使用語境 目標較長的描述，如果需要，還包括觸發事件 範圍 設計範圍，在設計時將系統作為乙個黑盒來...