物件導向系統分析與設計
系統開發生命週期
- 計劃階段
- 建立系統的==目的==和==實質利益==
- 可行性分析
- 技術面
- POC
- 經濟面
- 技術面
- 回答Why
- 分析階段
- 了解系統的需求是什麼(==What==), 先不管這些需求要如何達成(How)
- 以功能需求和非功能需求的描述為主, 而不會牽涉到實作的細節
- 回答What
- External Spec
- 設計階段
- 了解系統的需求如何被達成(How)
- 回答How
- Internal Spec
- 實作階段
- Coding and Unit Test
- 測試階段
- Functional Test
- Integration Test
- User Acceptance Test
- Performace Test
- Capacity Test
功能觀點
需求擷取與分析
領域分析
:::info 根據既有系統及其開發的歷史, 領域專家的知識, 背後的理論 辨別, 收集以及組織相關資訊的過程 :::
過程中會接觸到許多與計劃相關的參與人員, 例如:領域專家, 既有系統的使用者, 他們對==企業的各項活動以及業務流程==最熟悉, 他們會在分析階段扮演重要角色
需求擷取方式
- 既有的報表及表單
- 訪談
- 腦力激盪
需求分析
- 分類
- 功能性需求(Functional Requirement)
- 輸入
- 處理流程與步驟
- 輸出
- 非功能性需求(Non-Functional Requirement)
- 和系統的執行效率, 效能相關的需求, 且可測量(Measurable)
- 舉例
- Response Time
- Usability
- Reliability
- Performance
- Maintainability
- 功能性需求(Functional Requirement)
- 描述
- 從使用者的觀點出發, 定義出所要解決的問題
- 相關流程敘述需要明確地記錄
- 從使用者的觀點出發, 定義出所要解決的問題
- 事件
- 系統是與使用者互動的
- 對於功能的需求描述, 可以將它們歸納成事件
- 觸發器: 代表引發事件的資料
- 顧客下訂單的觸發器是訂單
- 產生月報表的觸發器是時間
- 思考方向
- 有什麼事情是必須由系統來自動化執行
- 想要從系統取得某些東西的外部或內部實體
- 需要被儲存的資料
- 由CRUD檢視系統可能發生的事件行為
- 是否有以資料為導向的事件
- 是否有以時間為導向的事件
- 詞彙表(Glossary)
- 與領域相關的資料與概念
- 思考方向
- 捕捉所有出現於需求描述的==名詞==
- 捕捉所有出現於事件表中的名詞以及所伴隨的資料項目
- 捕捉既有系統, 現行程序, 既有的報表及表單中的相關資訊
使用案例
敘述內容應紀錄 - 使用案例如何開始 - 使用案例如何結束 - 使用者如何與系統互動 - 互動過程中有什麼樣的訊息交換 - 互動行為的正常過程以及其他或是例外的過程 - ==情節==是指使用案例的某單一執行路徑
:::warning 不要在描述中談論設計細節或是特定的實作方法 :::
舉例: ==系統顯示產品目錄給使用者==, 這段描述並沒有提到如何顯示, 顯示在哪裡, 格式, 如何儲存產品目錄的資料...等
活動圖
- 塑模出系統層級的處理邏輯或是執行程序
- 幫助我們發現沒找到的例外路徑
- 專注在每一個活動並找尋有可能發生的狀況
-
檢驗使用案例描述的正確性
靜態觀點
分析概念的組成關係和結構關係