一.系統邊界和參與者
參與者actor定義:在系統之外,透過系統邊界和系統進行有意義的互動的任何事物
透露出參與者的特徵:
1.不屬於系統
2.通過系統邊界直接和系統互動->參與者的確定決定了系統邊界的確定
3.進行有意義的互動
4.任何事物
其中第二點的"直接"要注意:如果乙個顧客通過售票員買機票,那麼對於售票系統來說,售票員是參與者而顧客不是.
由此又產生了業務建模和系統建模的區別:對於售票系統來說,當業務建模的時候,我們描述的是顧客來訂票,可能還有票務中心的主任來詢問售票情況等等事件.但是系統建模的時候,他們都不是我們的物件,我們描述為售票員要售票和提供售票情況的事件的描述,因此這兩者在建模的不同階段是不一樣的.
在有些自動系統中,時間往往是觸發系統工作的外部事物,因此參與者是時間,不可忽略.
識別參與者方法:面對乙個系統時,你應該問這些問題:
誰使用系統?
誰改變系統資料?
誰從系統獲取資訊?
誰需要系統的支援來完成日常工作?
誰負責管理並維護系統正常執行?
系統要應付那些硬裝置?
系統要和其他的系統互動嗎?
誰對系統產生的結果感興趣?
時間,氣候等外部條件呢?
當你回答完這些問題之後,你的答案基本上就涵蓋了參與者的候選人.
識別參與者的重要性:
1.根據參與者識別系統用例:因此為了完整系統的功能,你識別的系統參與者寧多勿少.
2.測試部署階段你可能會通過識別者的角度去了解系統的完整性.
3.用例文件編寫階段,參與者不是很重要,但是你應該考慮參與者的泛化關係,避免出現用例的重複功能.
二.識別事件
羅列清楚系統事件,是正確建立系統用例的必要條件.
系統事件分為兩類:系統外部事件和系統內部事件
外部事件就是外部參與者對系統互動的具體工作,內部事件就是系統內部觸發的工作,通常由時間觸發.
識別事件的方法:頭腦風暴法-主語+謂語+賓語,描述系統可能發生的事情,盡可能全面,同樣是寧多勿少的原則,不過你可以根據事件的重要程度進行乙個排序,這能加深你對系統的認識.
通常把識別出來的事件列成乙個**:稱為3a表
actor action aim
參與者 作甚麼 業務目的
... ... ...
三.識別用例
用例定義:用例是一組用例例項
用例例項定義:系統執行的一系列動作,用以產生參與者可觀測到的結果值
用例要點:
1.位於系統 --必須由系統執行
2.目標導向 --用例執行必須有所目的
3.止於邊界 --可以觀測到結果,並且是在邊界和外部有所互動的
4.使用者觀點 --參與者觀測
5.粒度 --是一組有共同目標或者可以類聚的目標的例項們組成
識別用例是從業務建模開始的,也就是說我們描述用例是從使用者的角度即使用者觀點出發的識別行為,描述用例是用純粹的業務語言,而不是技術語言.比如描述為清繳稅款,而不是j2ee架構.因此,使用者的命名也是從使用者的角度出發,描述使用者要做的一件通過系統完成有目的,有結果的行為.
用例的粒度不宜過細,過細的分解會導致用例描述的錯誤:
1.把互動的步驟成為乙個用例,而不是把一類一系列步驟作為乙個用例.例如,使用者登陸是乙個用例,錯誤的做法是把請求輸入使用者名稱也作為乙個用例.
2.把必要的處理過程中的一些系統內部活動稱作用例:驗證使用者,連線資料庫,傳送sql請求等稱作乙個用例,其實都是使用者登陸這一次互動的步驟而已.
3.把識別用例的工作當成是關聯式資料庫分析的工作:稱作四輪馬車的錯誤,即crud(create read update delete).例如管理使用者是乙個用例,但是可能變成了增加使用者,查詢使用者,修改使用者,刪除使用者的"系統就是資料的增刪改查"的認識論錯誤.
識別用例的乙個關鍵性原則就是:站在使用者的角度分析使用者的目的,而不是站在系統的角度,更不是站在資料的角度.
通過建立的系統事件可以很順利的畫出用例圖,但是應該記住"用例的本質是文字",所以我們最終要將用例圖轉化成用例文件.可以用下面的例子格式書寫用例文件:
用例編號:
用例名:
用例描述:
參與者:
前置條件:開始該用例時的所必需的系統和環境狀態
後置條件:結束該用例時的所具備的系統和環境狀態
基本路徑:
1…..××××
2……××××
3…..××××
擴充套件點:
2a.××××
2a1….×××××
補充說明:
前置條件和後置條件可以反應用例間的相互依賴關係.還可以防止漏掉某些用例
用例之間的關係:擴充套件extends,包含include,泛化
UML大戰需求分析 讀書筆記
char2 1 系統上線後，如果使用者從來不提問題或需求，只能證明這套系統沒人用。真實的理想狀態是客戶一直在提問題，專案組解決，不斷重複 2 專案組一開始對需求的理解為0，客戶初始對需求有理解，使用後會有需求變更，這是正常的，說明使用者再次理解了需求 專案組需要在很短時間內理解需求，具備超強的業務學...
《構建之法》需求分析 讀書筆記
後悔沒有早點讀完這章，回想團隊專案剛開始時做的需求分析，深深感到我們實在太天真 太理想。畢竟沒有理論指導，按習慣做調研是容易碰釘子的，不過現在專案還未正式啟動，亡羊補牢，為時未晚。我們踩中了哪些坑？未能充分引導使用者表達需求 我們採用了問卷調查的方式，但沒有做進一步的深入調研。問卷調查有其好處 簡單...
讀書筆記 探索需求
如果你根本不知道自己在討論什 麼，那麼對其 強求精確是毫無意 義的 john von neumann 本書的意圖 也許就是使讀者能夠 知道 軟體的需求。隨著開發語言和開發工具的不斷發展，單純的軟體編寫正在變得越來越容易，隨之而來的是，人們希望用軟體來處理更加複雜的事務，這樣需求的複雜性在日益增加，已...