上课第六课.ppt

確認需求 每項需求有界限且明確嗎？ 每項需求都有屬性嗎？即每項需求都標示著資源(source)(通常是指定的個體)？ 任何需求與其他的需求間相衝突嗎？ 每個需求在技術環境上將系統或產品收容(house)是可達成的嗎？ 一旦實作後，每個需求都是可測試的嗎？ 確認需求 需求模型適當地反映所建構系統的資訊、功能和行為嗎？ 需求模型已經使用漸進地揭露更詳細的系統資訊的方式「分割」嗎？ 需求模式已經被使用來簡化需求模型嗎？所有的模式已經過適當的確認？所有的模式與顧客的需求一致嗎？ 「安全家」定義的三個行動者 「安全家」的基本需求定義三個行動者： 屋主(使用者) 組態管理者(或許與屋主同一人，但扮演不同的角色) 感測器(系統附屬裝置)和監控子系統(監控「安全家」居家安全功能的中樞站) 行動者範例_屋主(使用者) 屋主使用警報控制面板或PC的一些不同的方法與居家安全功能互動： 輸入一個密碼以允許其他的互動。 詢問安全區域的狀態。 詢問感測器的狀態。 緊急情況時按下驚慌(panic)按鈕。 啟動/解除安全系統。 系統啟動使用案例 考慮屋主使用控制面板的情形，基本的系統啟動使用案例如下： 屋主觀察「安全家」控制面板(圖7.2)以決定系統是否準備好而可以輸入。 如果系統尚未準備就緒，液晶顯示器上將顯示尚未就緒(not ready)的訊息，屋主必須要確實關好窗戶/門，以便消除尚未就緒的訊息。(尚未就緒的訊息意謂感測器為開啟；即某個門或窗戶是開啟的。) 屋主使用鍵盤鍵入四位數字的密碼。 密碼與系統所儲存的有效密碼比較。如果密碼不正確，控制面板會嗶一聲並重置(reset)以進行另一次的輸入。 如果密碼是正確的，控制面板等待進一步的行動。 系統啟動使用案例 屋主選擇並鍵入在家(stay)或外出(away)(見到圖7.2)以啟動系統。 在家則僅啟動周邊的感測器。(內部移動偵測感測器被解除)，外出則啟動所有的感測器。 當啟動產生時，屋主可以觀察到一個紅色的警示燈。 基本的使用案例呈現一個描述行動者與系統間互動的高層high-level故事。 圖 7.2 安全家控制面板 描述使用案例的樣版 Cockburn建議以下的樣版作為詳細描述使用案例： 使用案例： 啟動監控(InitiateMonitoring) 主要行動者： 屋主 目的： 當屋主離開房子或留在房內時設定系統以監控感測器。 先決條件： 系統已規劃密碼，且確認不同的感測器。觸發： 屋主決定「設定」系統，即啟動警報功能。 描述使用案例的樣版 情境： 屋主：觀察控制面板。 屋主：輸入密碼。 屋主：選擇「在家」或「外出」。 屋主：觀察指示安全家已經啟動的紅色警示燈。 例外： 控制面板尚未備妥(not ready)：屋主檢查所有的感測器以確定那個是開啟的；將它們關上。 密碼不正確(控制面板嗶一聲)：屋主重新鍵入正確的密碼。 密碼無法辨識：監控與回應子系統必須要連繫重規劃的密碼。 選擇在家：控制面板嗶嗶兩聲且在家的燈亮起；啟動周邊的感測器。 選擇外出：控制面板嗶三聲且外出的燈亮起；啟動所有的感測器。 描述使用案例的樣版 優先次序： 必要的，必須要實作。 何時有效： 第一次增量。 使用頻率： 每天許多次。 行動者的通道： 經由控制面板介面。 描述使用案例的樣版 次要行動者： 支援技術人員、感測器。 次要行動者的通道： 支援技術人員： 電話線。 感測器： 有線與無線介面。 描述使用案例的樣版 開放議題： 是否應該有個不必使用密碼或使用縮寫密碼啟動系統的方法嗎？ 控制面板應該顯示額外的文字訊息嗎？ 從第一個字開始，屋主需要花費多少時間鍵入密碼？ 是否有方法可在實際啟動前移除系統？ 圖7.3 安全家居家安全功能使用案例圖 7.6 建構分析模型 分析模型的意圖是為以電腦為基礎的系統提供必要的資訊、功能和行為領域的描述。 當軟體工程師學習更多有關所要建造的系統，和利益共享者瞭解更多關於他們真正所需要的時後，模型會動態地改變。 因為這個原因，分析模型只是在任何一定時間內需求的快照(snapshot)。我們期待它改變。 當分析模型演進時，某些元件會變得相對地穩定，為接下來的設計任務提供一個穩固的基礎。 其他的模型元件可能會更具揮發性(volatile)，指出顧客仍然不完全瞭解系統的需求。 7.6.1 分析模型的元素 有許多不同的方法注視以電腦為基礎的系統的需求。 某些軟體人主張最好選擇一種表示模式(例如使用案例)，並運用它以排除其他所有的模式。 其他的從業人員相信使用一些不同模式的表示法描述分析模型是值得的。 不同表示法模式強迫軟體團隊從不同的觀點考慮需求 – 有較高機率找出疏忽、不一致性和不明確性的一種步驟。 分析模型的特定元素 共通的分析模型特定元素： 以情境為基礎的元素 系統是從使用者的觀點使用以情