（一）軟體開發的相關人們（stakeholders）使用用例（use case）來探索需求。編寫有效的用例，形象具體，簡潔，清晰的表達需求。
（二）書中的四個圖表清晰形象：
1.figure1.1 the "hub-and-spoke" model of requirements，表達usecase和全部需求的關係。
2.figure2.2 striped trousers:scenarios succeed or fail，比喻scenarios中兩部份的成功和失敗。
3.figure5.1 use case levels. the use case set reveals a hierarchy of goals --- the ever-unfolding story，用例的三個級別：summary goals,user goals,subfunctions 及其關係的形象表述。
3.figure5.2 ask ''why'' to shift levels, 三個級別向上why和向下how。
（三）乙個usecase 結構模板
primary actor
scope
level
preconditons
trigger
main success scenario
extensions
variations
1、用例的前置條件（precondition）宣告了啟動該用例之前系統必須滿足的條件。通常，前置條件是指該條件已經通過其他用例的執行進行了設定。
最簡單的例子，在論壇裡發貼子用例的前置條件是使用者登入。
往往層次高的用例中前後兩個沒有可選路徑的步驟，降低一級層次後，兩個步驟獨立為兩個用例，那麼前乙個用例就是後乙個用例的前置條件。如在「病人看病」用例裡，第一步驟是「**」，第二步驟是「去診室見醫生就診」，那麼「在去診室就診」用例裡，「**」
就是其前置條件
2、在編寫前置條件時通常易犯的乙個錯誤是，把經常是正確的但不是必須的條件寫入前置條件。
例如，醫院急診病人就診可以不預先**，那麼「**」就不是「急診病人就診」的前置條件。
3、最小保證是系統向專案相關人員作出的最低承諾，尤其是在主執行者的目標不能被滿足的情況下。在目標遭遇失敗的情況下，專案相關人員認可他們的利益得到了保護，這時最小保證是否成功/失敗的測試標準。
4、成功保證（success guarantee）說明了用例成功結束後專案相關人員的哪些利益得到了滿足，用例可以通過執行主場景獲得成功，也可以通過執行可選路徑獲得成功。成功保證通常作為最小保證的新增內容：最小保證被滿足以後，並且一些附加條件為真；附加條件中至少包括用例標題中宣告的目標。
5、專案相關人員認可他們的利益得到了滿足，這是成功是否成功/失敗的測試標準。找到成功保證的最好方法是問這樣乙個問題：「在用例結束時，什麼事會使專案相關人員感到不高興？」這個問題通常很容易回答，然後寫出答案的反面回答。
6、觸發事件（trigger）指明了啟動用例的條件。
《編寫有效用例》閱讀筆記三
基於資料庫操作的小用力稱為crud用例，每個小用例都表達了單獨需求，在處理這種用例是會有兩種不同的方法，可以將其分離或者先使用單個管理實體用例對其處理。在提取系統用例時或有許多用例大致相同，對此可能會建立一種通用搜尋機。用例每個目標步驟的命名類似於程式語言中的子過程呼叫，而且用例是有人而不是計算機使...
《編寫有效用例》閱讀筆記一
這個學期的好幾門課程都會用到uml用例圖的相關知識，可見用例的重要性。用例圖作為軟體開發需求分析階段的主要表現形式，有很多值得去學習和研究的內容。這本書通過對具體的一些用例的分析，介紹了一些編寫有效用例的方法和技巧。這本書分為 用例體部分 經常討論的主題 對忙於編寫用例的人的提示 幾個部分，單從名稱...
編寫有效用例 閱讀筆記05
編寫了那麼多的用例，那用例到底是幹嘛的？用例為管理者指明應提交給使用者的系統功能。用例的標題指明主執行者的需求，同時系統也必須支援這些需求，而用例描述則說明了系統需要什麼功能以及將提供什麼服務。在一開始接觸用例的時候，uml課程中提及過用例的優先順序以及用例版本號等其他細節，對於這些資訊的彙總可以稱...