【正文】 37 需求表達 ?“分析程序應該能生成 HTML標記出錯的報告，這樣就可以使 HTML的初學者使用它來迅速排錯 ” ?在 HTML分析程序完全分析完一個文件后，該分析程序必須生成一個出錯報告，這個報告中包含了在分析文件中所發(fā)生錯誤的 HTML所在的行號以及文本內容，還包含了對每個錯誤的描述。 ?如果后臺任務中止執(zhí)行，那么后臺任務管理器必須顯示一個出錯信息。 35 需求表達 ?“產品必須在固定的時間間隔內提供狀態(tài)消息，并且每次時間間隔不得小于 60秒 ” ?后臺任務管理器應該在用戶界面的指定區(qū)域顯示狀態(tài)消息 ?在后臺任務進程啟動之后，消息必須每隔 60（ +_10）秒更新一次，并且保持連續(xù)的可見性。 ?避免使用比較性的詞匯，例如：提高，最大化，最小化和最佳化。 ? 分解到須考慮具體實現的代碼時即可仃止 28 分析過程 修正計劃 文檔： 《 需求規(guī)格說明書 》 不需分解 有補充 修正 無補充修正 分析追蹤 數據流圖 用戶復查 細 化 數據流圖 需要 分解 29 需求分析規(guī)格說明書 文檔編號 ： 版 本 號： 文檔名稱： 項目名稱： 項目負責人： 年 月 日 編寫： 核對： 審核： 批準： 開發(fā)單位： 30 需求分析規(guī)格說明書 ⑴ 系統(tǒng)規(guī)格說明： ? 系統(tǒng)概貌 ? 功能要求 ? 性能要求 ? 運行要求 ? 可能增加的要求 ? DFD ? IPO ⑵ 數據要求： ? DD ? Hierarchy 或 Warnier Diagram ⑶ 用戶系統(tǒng)描述 —— 初步用戶手冊：從用戶的觀點考慮系統(tǒng) ? 系統(tǒng)功能、性能 ? 使用與步驟 等 ⑷ 修正的開發(fā)計劃： ? 成本估計 ? 資源使用計劃 ? 進度計劃 31 需求分析規(guī)格說明書 ?從現實中分離功能，即描述要“ 做什么 ”而不是“ 怎樣實現 ” ?要求使用 面向處理 的規(guī)格說明語言（或稱系統(tǒng)定義語言） ?如果被開發(fā)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中 ?規(guī)格說明必須包括系統(tǒng)運行環(huán)境 ?規(guī)格說明必須是一個認識模型 ?規(guī)格說明必須是可操作的 ?規(guī)格說明必須容許不完備性并允許擴充 ?規(guī)格說明必須局部化和松散耦合 32 分析過程 ?節(jié)選自目前我國的一些實際系統(tǒng)中的功能性需求的說明方式：“根據詳細的系統(tǒng)調研和需求分析， ……系統(tǒng)的功能必須滿足以下需求： 1)編制計劃、計劃工程撥款管理， ……，工程批復管理，工程進度統(tǒng)計； 2)工程項目管理； 3)計劃撥款、征費收繳信息及其他收撥款信息查詢統(tǒng)計； 4)路產管理，違章建筑管理，工程材料管理， ……，超限運輸管理； 5)養(yǎng)征信息查詢管理，收費站信息管理； 6)文檔管理，會議管理，合同管理， ……，駕駛員外勤管理，常用管理； 7)養(yǎng)護信息管理，公路維護預警； 8)路況信息管理，交通量信息管理，科研項目信息管理； 33 需求表達 ?需求說明語句 ?保持語句和段落的簡短 ?采用主動語態(tài)的表達方式 ?編寫具有正確的語法和標點的完整句子 ?使用的術語應該和詞匯表中定義的一致 ?需求陳述應該具有一致的式樣，例如“系統(tǒng)必須 ……”，或者“用戶必須 ……”，并緊跟一個行為動作和可觀察的結果，例如“倉庫管理子系統(tǒng)必須現實一張在所請求的倉庫中有存貨的藥品名單。 22 需求分析的任務 2分析數據 ⑴建立概念模型 (conceptual models): ER Diagram ⑵ 形象描繪數據結構 : Data Hierarchy, Warnier Diagram, IPO ⑶ 數據結構規(guī)范化 (Normalization) 導出邏輯模型： DFD + DD + IPO 修正計劃：重估成本、進度等 23 需求分析的任務 “樣機 試用” C D G 開發(fā)原型系統(tǒng) (Prototyping) 24 分析過程 ?軟件系統(tǒng)本質上是信息處理系統(tǒng)，任何信息處理系統(tǒng)的基本功能都是把輸入數據轉變成需要的輸出信息 ?數據是分析的出發(fā)點，在可行性分析階段許多實際的數據元素被忽略了，需求分析階段將定義這些數據元素 ?結構化分析方法就是面向數據流自頂向下逐步求精進行需求分析的方法 25 分析過程 沿 DFD回溯 （ 1） DFD的輸出端是系統(tǒng)的最終目的 （ 2）向回確定每個數據元素的來源 （ 3）為了得到某個數據元素需要用到數據流圖中目前還沒有的數據元素，或者得出某個數據元素需要用的算法尚不清楚，可加細 DFD及 DD，并將相關算法記錄在 IPO圖 中。 ?在系統(tǒng)開發(fā)前，還需要進一步確定 18 需求分析的任務 可行性分析 DFD DD 功能具體化 需求規(guī)格說明 加細 DFD DD 算法描述IPO Final stage of Definition phase 仍然回答“ What”，而不是“ How”， 但更細致、精確（合同的擬定） 19 需求分析的任務 ?完整 ?準確 ?清晰 ?具體 20 需求分析的任務 21 需求分析的任務 確定要求 ⑴ 功能要求 (functional requirements):系統(tǒng)必須做什么？ ⑵ 性能要求 (performance requirements)： 做得怎樣？ 例： response time , memory , backup memory , security , …… ⑶ 運行要求 (operational requirements) ：運行環(huán)境、軟硬件配置等。 13 需求工程涉及人員 14 軟件需求 ?功能需求 ?性能需求 ?環(huán)境需求 ?可靠性需求 ?安全保密要求 ?用戶界面需求 ?資源使用需求 ?成本消耗需求 ?開發(fā)進度需求 ?預先估計以后系統(tǒng)可能達到的目標 15 需求分析與程序設計的不同 16 需求分析現狀 ?誤解 ?交流障礙 ?缺乏共同語言 ?“完整性”問題 ?需求永遠不會穩(wěn)定 ?用戶意見不統(tǒng)一 ?錯誤要求 ?認識混淆 17 需求分析的任務 ?可行性分析階段已經粗略了解了用戶的需求，甚至已經提出了一些可行的方案，但是，可行性研究的基本目的是 用較小的成本在較短的時間內確定是否存在可行的方案 。 ?如果沒有及時檢查出來這些錯誤，軟件費用會直線上升 (事實 1) 11 需求管理的困難性 12 需求工程 ?需求是什么 ?需求就是以一種清晰、簡潔、一致且無二義性的方式，對一個待開發(fā)系統(tǒng)中各個有意義方面的陳述的一個集合。 ?許多錯誤并沒有在早期被發(fā)現 (事實 2)。得出的研究數據表明：