上次談到了用例中的三大概念元素：範圍、主執行者和層次，在最近的閱讀中對這三個概念有了更深入的理解，所以今天的閱讀筆記厚重準備就這三個概念進行更加詳細的說明。
用例的範圍就是專案開發人員負責設計工作的邊界，是用來確定設計工作是否完成的重要判斷依據。我們首先來說一下確定用例範圍的重要性。用例是用與專案相關人員之間的交流的，而不能確定專案的邊界對於乙個專案的開發是有著十分嚴重的破壞性的，甚至就直接決定了這個專案的失敗。比如如果在確定用例時沒有及時發現一些隱藏的利益相關者，導致在軟體設計時沒有考慮到這些人的利益，那麼在軟體設計開發完成之後，這些人發現他們沒有得到軟體給予的任何幫助，就會立即做出反饋，要求更改開發人員更改系統。可是在專案進行到這個階段，系統的架構已經確定，再新增功能模組可能會造成很大的成本，甚至需要推翻重新來過，就造成了很大的經濟損失。另外還有一種情況就是把範圍確定的太大了，有一些只需要與別的系統建立介面連線的功能模組也被考慮進來，這就徒然增加了系統開發的工作量，在開發完成之後這個功能還不一定被使用者所使用，因為他們已經有了相應的系統。由此延伸到軟體需求分析過程中對系統邊界的分析和確定，一方面是為了確定系統設計的範圍，一方面也是為了防止客戶無止境的變更需求，擴寬系統邊界。在實際工作中可以採用一些小的手段來確定用例的邊界，比如系統功能的內外列表，執行者的任務級目標列表，還有用例簡述等等。
專案相關人員是指用例的所有參與者，主執行者是指任何能夠有行為的人。在軟體需求分析的過程中一定要把系統中設計到的專案相關人員考慮全面，尤其是專案中的利益相關者，這樣才能夠全面的分析系統的需求，盡可能的讓系統能夠為專案設計到的所有人提供服務。如果在需求分析的時候沒有及時發現那些隱藏的利益相關者，就很容易出現上文中提到的用例範圍確定太窄的情況，從而導致了專案的失敗。在分析專案相關人員的時候要盡量多找一些主執行者，通過對他們的行為分析來引導我們把注意力集中到使用系統的人的身上。同時在這個基礎上還能夠建立乙個執行者到目標列表的結構框架，讓我們可以利用這個框架來分解工作功能和劃分優先順序。
實際上在建立乙個用例的時候，任何一次互動過程都可以分解成更低層次的目標，所以在編寫用例的時候層次是非常困擾我們的乙個問題。實際上，我們可以將用例層次概括為三個方面，使用者目標、概要層次以及子功能。使用者目標是主執行者努力使工作得以完成的目標，是專案開發人員和系統使用者都最感興趣的目標層次。這個層次是軟體需求分析過程中最重要的乙個層次，是最需要我們花精力去了解分析的。而概要目標層次則在更高一層次上包含了更多的使用者目標，概要層次描述了使用者目標執行的語境，顯示了相關目標的生命週期，還要為低層次的目標建立目錄表。子功能層次則是在實現使用者目標的基礎上有些可能會被用到的目標層次。只有在迫不得已的情況下才能用得到。在層次分析上最重要的就是找出正確的目標層，還要對其進行分析，在合適的場景下還可以對層次進行公升降。
以上是我在閱讀了《編寫有效用例》前五章之後，對用例中的三大概念元素：範圍、主執行者和層次的理解。
《編寫有效用例》閱讀筆記02
在做需求分析過程中，通常要找到系統直接或間接的使用者，從這些使用者身上找到系統所要實現的機能，如果系統可以完全滿足這些使用者的利益需求，這個系統就可以算做是乙個成功的系統 執行者是指任何具有行為的事物，某種情況下的專案相關人員也是執行者。1.系統的專案相關人員 stakeholder 2.用例的主執...
《編寫有效用例》閱讀筆記三
基於資料庫操作的小用力稱為crud用例，每個小用例都表達了單獨需求，在處理這種用例是會有兩種不同的方法，可以將其分離或者先使用單個管理實體用例對其處理。在提取系統用例時或有許多用例大致相同，對此可能會建立一種通用搜尋機。用例每個目標步驟的命名類似於程式語言中的子過程呼叫，而且用例是有人而不是計算機使...
《編寫有效用例》閱讀筆記一
這個學期的好幾門課程都會用到uml用例圖的相關知識，可見用例的重要性。用例圖作為軟體開發需求分析階段的主要表現形式，有很多值得去學習和研究的內容。這本書通過對具體的一些用例的分析，介紹了一些編寫有效用例的方法和技巧。這本書分為 用例體部分 經常討論的主題 對忙於編寫用例的人的提示 幾個部分，單從名稱...