03軟件需求工程(編輯修改稿)
2025-03-06 14:19 本頁面
【文章內容簡介】 法的補充。 最有力的 需求獲取技術。有利 于 培養(yǎng)高效團隊。 4. 觀察用戶的工作流程 適用于用戶無法準確表達需求的情況。 5. 原型化方法 6. 基于用例的方法 是從多個用戶中收集需求信息的有效方式 ，一般問卷設計形式： 1）多項選擇問題 ； 2）評分問題 ； 3）排序問題 。 27 需求獲取技術 重要而直接，簡單的 需求獲取技術。 2. 問卷法調查法 是對面談法的補充。 最有力的 需求獲取技術。有利 于 培養(yǎng)高效團隊。 4. 觀察用戶的工作流程 適用于用戶無法準確表達需求的情況。 5. 原型化方法 6. 基于用例的方法 由開發(fā)方和用戶方共同召開 ,操作步驟： ① 開發(fā)方根據(jù)雙方制定的 《 需求調研計劃 》 召開相關需求主題溝通會； ② 會后開發(fā)方整理出 《 需求調研記錄 》 提交給用戶方確認； ③ 如果此主題還有未明確的問題則再次溝通 ,否則開始下一主題； ④ 所有需求都溝通清楚后，開發(fā)方根據(jù)歷次 《 需求調研記錄 》 整理出 《 用戶需求說明書 》 ，提交給用戶方確認簽字。 28 需求獲取技術 重要而直接，簡單的 需求獲取技術。 2. 問卷法調查法 是對面談法的補充。 最有力的 需求獲取技術。有利 于 培養(yǎng)高效團隊。 4. 觀察用戶的工作流程 適用于用戶無法準確表達需求的情況。 5. 文獻考古 還有知識工程方法等如：場記分析法、卡片分類法、分類表格技術和基于模型的知識獲取等。 29 需求分析階段 主要對收集到的需求進行提煉、分析和認真審查，對模型或原型進行 分析， 進行 需求建模 。確保所有參加人員取得一致共識。找出錯誤、遺漏和不足， 建立完整的分析模型 。 (二 )、需求分析、協(xié)商與建模 30 確定系統(tǒng)的綜合要求 系統(tǒng)功能要求 — 這是最主要的需求 ， 確定系統(tǒng)必須完成的所有功能 。 系統(tǒng)性能要求 — 應就具體系統(tǒng)而定 ， 例如可靠性 、 聯(lián)機系統(tǒng)的響應時 間 、 存儲容量 、 安全性能等 。 系統(tǒng)運行要求 — 主要是對系統(tǒng)運行時的環(huán)境要求 ， 如系統(tǒng)軟件 、 數(shù)據(jù) 庫管理系統(tǒng) 、 外存和數(shù)據(jù)通信接口等 。 將來可能提出的要求 — 對將來可能提出的擴充及修改作預準備 。 分析系統(tǒng)的數(shù)據(jù)要求 軟件系統(tǒng)本質上是信息處理系統(tǒng)，因此，必須考慮： 數(shù)據(jù) （需要哪些數(shù)據(jù)、數(shù)據(jù)間聯(lián)系、數(shù)據(jù)性質、結構） 數(shù)據(jù)處理 （處理的類型、處理的邏輯功能） 導出系統(tǒng)的邏輯模型。 修正系統(tǒng)的開發(fā)計劃 — 通過需求對系統(tǒng)的成本及進度有了更精確的估算 ，可進一步修改開發(fā)計劃 。 需求分析、協(xié)商與建模的具體任務 31 當前 系統(tǒng) 目標 系統(tǒng) 物理 模型 邏輯 模型 邏輯 模型 物理 模型 模型化 抽象化 具體化 實例化 怎 么 做 做 什 么 當前 系統(tǒng) 目標 系統(tǒng) 需 求 定 義 需求分析的一般步驟 32 1．必須能夠表示和理解問題的 信息域 2．必須能夠定義軟件將完成的功能 3．必須能夠表示軟件的行為 (作為外部事件的結果 ) 4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細節(jié) 5．分析過程應該從要素信息移向細節(jié)信息 需求分析操作原則 33 信息域 ? 信息域：包括 信息內容、信息流、 以及 信息結構 。 – 信息內容 表示了單個數(shù)據(jù)和控制對象，目標軟件所有處理的信息集合由它們構成。 – 信息流 表示了數(shù)據(jù)和控制在系統(tǒng)中流動時的變化方式，輸入對象被變換為中間信息 (數(shù)據(jù)和 /或控制 )，然后進一步被變換為輸出 – 信息結構 表示了各種數(shù)據(jù)和控制項的內部組織 ? 數(shù)據(jù)或控制項將被組織為 n維表還是樹形結構？ ? 在結構的語境內，什么信息是和其他信息相關的？ ? 信息包含在單個結構中，還是使用不同的結構？ ? 在某信息結構中的信息如何和在另一個結構中的信息相關？ 34 需求工程的指導性原則 ? 除了上面提到的 操作性分析原則 ， Davis提出了一組針對需求工程的 指導性原則 ： ? 在開始建立分析模型前，先充分理解問題。 ? 開發(fā)原型，使得用戶能夠了解如何進行人機交互。 ? 記錄每個需求的起源及原因。 ? 使用多個需求視圖。建立數(shù)據(jù)、功能和行為模型，為軟件工程師提供三種不同的視圖。 ? 給需求賦予優(yōu)先級。 ? 努力刪除歧義性。 35 常用的需求分析方法： ? 功能分解方法 ? 面向數(shù)據(jù)流的結構化分析方法 (SA) ? 面向數(shù)據(jù)結構的分析方法 ? 信息建模法 ? 面向對象的分析方法 (OOA) 36 功能分解方法 將系統(tǒng)看作若干功能模塊的集合 ， 每個功能又可以分解為子功能 ,子功能還可繼續(xù)分解 ,分解的結果即是系統(tǒng)的雛形 。 存在問題 1. 需要人工完成 2. 無法對描述的
環(huán)評公示相關推薦
鄂ICP備17016276號-1