需求工程概述ppt課件-資料下載頁
2024-09-20 20:25本頁面
【正文】 求規(guī)格說明是否 正確 和 完整地表達了用戶對軟件系統(tǒng)的需求。 2022/9/20 40 需求管 理過程的任務 有效地 管理軟件系統(tǒng)的需求規(guī)格說明 及其相應文檔，評估需求變更帶來的潛在影響及可能的成本費用， 跟蹤軟件需求的狀態(tài) ， 管理 需求規(guī)格說明的 版本 等。 2022/9/20 41 需求工程的內(nèi)容 需 求 工 程需 求 開 發(fā) 需 求 管 理需 求 獲 取需 求 建 模編 寫 規(guī) 格 說 明需 求 驗 證建 立 基 線變 更 控 制需 求 跟 蹤2022/9/20 42 需求工程面臨的困難 ? 需求獲取與需求分析的困難性 （ 1）有些需求可能用戶也不是很清楚； （ 2）需要用戶與開發(fā)人間進行充分的交流和協(xié)商； （ 3）需求間的沖突和矛盾的檢查以及解決； （ 4）需求是否完整和確定； （ 5）合適的需求建模的方法和技術。 2022/9/20 43 需求工程面臨的困難 ? 需求描述語言和規(guī)范化的困難性 （ 1）怎樣規(guī)范化用戶需求； （ 2）規(guī)范化哪些用戶需求； （ 3）非形式化和形式化描述語言的使用。 2022/9/20 44 需求工程面臨的困難 ? 需求驗證的困難性 （ 1）需求規(guī)格說明正確性的確認和驗證； （ 2）驗證的方法和技術； （ 3）如何進行自動驗證。 2022/9/20 45 需求工程面臨的困難 ? 需求管理的困難性 （ 1）需求規(guī)格說明書的質(zhì)量保證； （ 2）需求規(guī)格說明書的版本管理； （ 3）需求變更的控制。 2022/9/20 46 The Standish Group ? 美國專門從事跟蹤 IT項目成功或失敗的權威機構，它每年發(fā)布 CHAOS Report。報告中給出全美 IT項目相關調(diào)查數(shù)據(jù)結果。 ? ? 從歷年的 Standish Group報告分析看 ,導致項目失敗的最重要原因與需求有關 .Standish Group 的CHAOS 報告進一步證實了與成功項目最密切的因素是良好的需求管理 ,也就是項目的范圍管理 ,特別是管理好項目的變更 . 2022/9/20 47 歧義示例： 需求：系統(tǒng)只允許保留 5個有效的相關記錄和保障計劃，它必須包括最新的。 最新的相關記錄？ 最新的保障計劃？ 總數(shù) 5個？各 5個？ 修改為： ? 系統(tǒng)只允許 5個有效的相關記錄 ? 最新的相關記錄一定包含在上述相關記錄中 ? 每個保障計劃都被放在其相關記錄中 2022/9/20 48 不確定需求示例 需求：系統(tǒng) 1應該每隔 5分鐘向系統(tǒng) 2發(fā)送一次新記錄。 5分鐘內(nèi)沒有收到新記錄怎么辦？ 修改為： 如果自上次向系統(tǒng) 2發(fā)送消息以來， 5分鐘內(nèi)收到了新消息，則系統(tǒng) 1向系統(tǒng) 2發(fā)送新記錄。 如果在上述 5分鐘內(nèi)沒有收到了新消息，則系統(tǒng) 1什么都不做。 2022/9/20 49 完整性：應將所有要實現(xiàn)的需求都描述清楚。 需求的遺漏更多地由于用戶的原因，而后的修正卻給開發(fā)人員帶來極大的困難。（注重用戶的任務而不是系統(tǒng)的功能將有助于避免不完整性） 正確性：準確地描述系統(tǒng)必須提供的功能。由用戶確定，需要將用戶需求有效地映入到軟件需求。 可行性：每一項需求必須在已知系統(tǒng)和環(huán)境的限制范圍內(nèi)可以實施。（在獲取需求過程中始終有一位軟件開發(fā)小組的技術人員參與）。 必要性：每項需求都是真正來源于用戶的實際需要。都能回溯至某項客戶的輸入。 劃分優(yōu)先級：不能把所有需求看做同等重要，會在調(diào)度中喪失自由度。 無二義性：盡量把每項需求用簡潔明了的語言表達出來。（審查、測試用例、開發(fā)原型等消除歧義） 可驗證性：可以通過設計測試用例或其他方法如檢測或演示等進行驗證。 可跟蹤性：每條需求都可以從一個需求層次跟蹤到另一個需求層次。被唯一標識，以便在設計、實現(xiàn)、測試過程中進行跟蹤。有助于確保需求的實現(xiàn)和后期的系統(tǒng)維護。 確定性：明確在所有條件下系統(tǒng)應該做什么。
環(huán)評公示相關推薦
鄂ICP備17016276號-1