OOAD_05第5章需求工程.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ※ 5-3-1 需求描述-標準語法的需求描述 現在，我們可以將之前線上訂購系統的需求改寫成標準語法來描述，如下所示： 1. 線上訂購系統會提供客戶加入會員。 2. 線上訂購系統會提供會員登入系統。 3. 線上訂購系統會提供客戶瀏覽商品目錄。 4. 線上訂購系統會提供客戶瀏覽商品明細。 5. 線上訂購系統會提供客戶新增訂購商品。 6. 線上訂購系統會提供客戶刪除訂購商品。 7. 線上訂購系統會提供客戶更改訂購商品數量。 8. 線上訂購系統會提供會員下訂單。 …….. ※ 5-3-2 需求分類-功能性需求(說明) 功能性需求是在描述系統應該做什麼和期望做什麼（What），它是一段系統功能或服務的描述，和當特殊資料輸入時，系統需要如何反應，或發生特殊情況時，系統所做的行為。 對於一些特殊案例，功能性需求還可能需要明確描述系統不能執行哪些功能。 ※ 5-3-2 需求分類-功能性需求(範例) 當我們進行需求擷取活動時，回答內容出現「系統必須…」、「系統應該…」或「系統可以…」等句型時，就表示句子中隱含功能性需求的服務或功能，英文是must、shall或should。例如：ATM自動提款機的功能性需求，如下所示： 1. ATM自動提款機系統會檢查金融卡是否是一張有效卡片。 2. ATM自動提款機系統會驗證客戶輸入的密碼是否正確。 3. ATM自動提款機系統會提供客戶提款。 4. ATM自動提款機系統會提供客戶存款。 5. ATM自動提款機系統會提供客戶查詢帳戶餘額。 6. ATM自動提款機系統會提供客戶轉帳。 ※ 5-3-2 需求分類-非功能性需求(說明) 非功能性需求 說明 效能（Performance） 系統可以滿足客戶的最低執行效能，通常會包含多個項目來進行評斷，例如：每秒處理的交易量和反應時間（Response Time）等，反應時間是指必須在一定時間內得到回應 使用性（Usability） 系統是否容易使用，即使用者可以正常上線的訓練時間 可靠性（Reliability） 系統是否可以持續可用，反過來，就是允許系統失效的平均時間或頻率，例如：一個月不可超過一次系統失效 操作性（Operational） 系統可以連續操作的天數，例如：連續一個月或365天 維護性（Maintainability） 系統維護的相關事項，確保可以應付未來的需求，例如：下一個版本需要的修正 保密性（Security） 關於保密和敏感資訊的處理，例如：不同權限的帳戶管理和加密 財務考量（Financial） 專案成本考量的預算上限，通常不會列在需求規格文件，而是在合約書或開發計劃 合法性（Legal） 系統環境操作的合法性，簡單的說，我們是否可以合法使用此系統 ※ 5-3-2 需求分類-非功能性需求(範例) 一般來說，我們談到的需求都是指功能性需求，但是，非功能性需求一樣十分重要，如果沒有滿足非功能性需求，意味著整個系統都可能無法使用。例如：ATM自動提款機的非功能性需求，如下所示： 1. ATM自動提款機系統會使用128位元的加密方式進行連線。 2. ATM自動提款機系統會在4秒之內完成金融卡的驗證。 3. ATM自動提款機系統會在3秒之內完成密碼的驗證。 4. ATM自動提款機系統會在20秒內完成轉帳。 ※ 5-3-3 需求屬性-說明 需求屬性是需求的描述資料（Meta-Data），每一個需求都需要使用一組屬性來記錄需求的額外資訊，例如：完成日期和優先等級等 基本上，需求屬性的語法是由屬性名稱和值組成，例如：名為【優先等級】的屬性，其值為MoSCoW規則M。 ※ 5-3-3 需求屬性-MoSCoW規則的優先等級 需求屬性最常使用的是需求的優先等級（Priority），我們常常使用MoSCoW規則來指定需求的優先等級，如下表所示： MoSCoW規則 說明 屬性值 必須有（Must-haves） 一定必須要有的需求 M 應該有（Should-haves） 需求很重要，但刪除也不會影響專案的開發 S 可能有（Could-haves） 可選擇是否開發的需求 C 期望有（Want-haves） 等到系統開發較成熟後，再考量是否開發的需求 W ※ 5-3-3 需求屬性-Rational統一流程定義的需求屬性 需求屬性 說明 狀態（State） 需求的狀態，其屬性值如下所示： 建議：需求只是建議，未經討論和同意 允許：需求允許開發 拒絕：需求拒絕開發 完成：需求已經開發完成 效益（Benefit） 需求的重要性，其屬性值如下所示： 嚴重的：有嚴重問題的需求，需