粗略瀏覽整本書，我對它第一印象並不是很好，不然也不會遲遲未看下去。然而，耐著性子學習，卻發現我們所學習的軟體工程的相關課程，萬變不離其宗，整個系統是一致的。換句話說，乙個系統做下來，並不是單單一門課就可以解決的事，其間蘊含了所有學習的或還未學習的內容。
用例這個概念曾在學習uml中有提及，當時用例的概念僅僅止步於「用客戶或使用者的語言和詞彙來描述的系統的乙個完整功能」。緊接著，學習的重點便是用例圖和其他圖的繪製。在uml中強調的是使用圖繪的方式來描述用例之間的「關聯關係」、「泛化關係」、「包含關係」、擴充套件關係」等。而此教材是一方面是從文字和圖符來教我們如何寫用例，另一方面教我們如何寫乙份具有可讀性的用例。同樣的，軟體需求分析課程和這個也差不多，側重點不同，卻說的是同樣的內容，
於我而言，我一般都不太關係具體的概念知識，比起那些冗雜難懂的定義，我更傾向於了解這個東西究竟是幹什麼的、有什麼用。
用例詳細的描述了系統被使用時的行為細節，使得使用者明白新系統到底是怎麼樣的。舉個例子來說：(非正式版本)請求者發起請求，並把這個請求從給他的批准者。然後批准者首先檢查預算中是否還有資金，然後核實貨物的**，接著完成提交請求，並將請求傳送給買者……這一系列的活動，至到最後請求者得到相應的響應。這個完整的過程就可以稱之為乙個用例。
同時，用例描述了整個系統，並被冠以系統之名，並被整理成乙個列表。這個列表申明了這個系統可以做什麼，系統的範圍是什麼，建立系統的目的是什麼。其次，用例某種程度上十分詳盡的描述了異常情況的處理過程，讓開發人員發現需求方或自己之前並沒有考慮到的種種意外情況。對於這些意外情況的提前發現，能讓程式設計師在編寫**以前就想好相應的解決方案，這時，諮詢業務專家就是十分及時的，否則，程式設計師會十分想當然的編寫**，而不努力尋求更理想的解決辦法。
用例這個東西，聽起來很簡單，但是真正寫起來卻很困難，不考慮寫的是否有效，不考慮寫的怎麼樣，就光考慮所有的情況有時就能逼瘋我們這些初學者，這時候就需要乙個系統使用敘述來熱身並且需要合理安排自己的精力來做這些事。
範圍這個概念在其他課程上，被聽到的更多是「邊界」、「系統邊界」這些術語。概念上來說，範圍一詞來描述專案開發人員負責的設計工作的邊界，以便於應由其他人負責的設計工作或已經完成的設計工作相區別。此處從功能範圍、設計範圍、最外層用例幾個方面來講述什麼是範圍，範圍究竟是怎麼樣的。通過一些舉例來告訴我們哪些是在範圍內的，哪些屬於臨界點的，哪些不是範圍內的。說實話，看著書上的例子我還能辨別什麼事範圍內的，但是一脫離課本，看乙個新的系統，我還不確定自己所想是否正確，並且不會同比較通俗的語句來講述，這個部分，暫且留著，以後再解決。
《編寫有效用例》閱讀筆記01
編寫有效用例 是美國alistaircockburn的著作 全書分為三部分 1.用例體部分2.在需求分析過程中經常遇到的問題3.對忙於編寫用例的人的提示 今天我主要閱讀了第一部分。在作者的引導下思考了以下問題 1 什麼是用例？例用於表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是...
《編寫有效用例》閱讀筆記三
基於資料庫操作的小用力稱為crud用例，每個小用例都表達了單獨需求，在處理這種用例是會有兩種不同的方法，可以將其分離或者先使用單個管理實體用例對其處理。在提取系統用例時或有許多用例大致相同，對此可能會建立一種通用搜尋機。用例每個目標步驟的命名類似於程式語言中的子過程呼叫，而且用例是有人而不是計算機使...
《編寫有效用例》閱讀筆記一
這個學期的好幾門課程都會用到uml用例圖的相關知識，可見用例的重要性。用例圖作為軟體開發需求分析階段的主要表現形式，有很多值得去學習和研究的內容。這本書通過對具體的一些用例的分析，介紹了一些編寫有效用例的方法和技巧。這本書分為 用例體部分 經常討論的主題 對忙於編寫用例的人的提示 幾個部分，單從名稱...