【正文】 隨時將你們的進展情況告訴我。 ? 系統(tǒng)必須支持 100個 Windows工作站的并行訪問。 2023/1/30 27 5. 約束條件 ? 約束條件 (Constraints)： 系統(tǒng)設(shè)計和實現(xiàn)時必須滿足的 限制條件 ，對其進行權(quán)衡或調(diào)整是相當困難的，甚至是不可能的； ? 例如： – 系統(tǒng)必須用 C++或其他面向?qū)ο笳Z言編寫； – 系統(tǒng)用戶接口需要采用圖形化界面； – 任取 10秒，一個特定應(yīng)用所消耗的可用計算能力平均不超過 50%； – 系統(tǒng)開發(fā)過程和交付文檔需遵循 GB/T 85672023標準； – 通訊接口必須符合 ISO七層架構(gòu)。 – 學生希望在選課期間系統(tǒng)能夠 24小時使用，系統(tǒng)使用方便快捷。 ? 需求通常用于表達 “做什么” ，而不描述“ 如何做 ”。 ? 軟件需求是要把一個定義不足和模糊的問題轉(zhuǎn)換為一個定義良好而準確的問題，進而找到解決問題的方案。 Phil 如果你一開始就告訴我你想隨時改變某人的名字，那這些就都不會發(fā)生！ …… 2023/1/30 10 “錯誤的需求”的擴散效應(yīng) 問題 正確的需求 錯誤的需求 正確的設(shè)計 基于“錯誤的需求” 的設(shè)計 錯誤的設(shè)計 基于“錯誤的 設(shè)計”的編碼 正確的編碼 錯誤的編碼 基于“錯誤的需求” 的編碼 2023/1/30 11 “錯誤的需求”的修復代價 “構(gòu)建一個軟件系統(tǒng)最困難的部分是確定構(gòu)建什么 … 在出錯之后會嚴重影響隨后實現(xiàn)的系統(tǒng)，并且在以后的修補是如此的困難 …‖ 2023/1/30 13 根本原因是什么？ 需求的鴻溝 (期望差異 )： 開發(fā)者開發(fā)的與用戶所想得到 的軟件存在著巨大期望差異。 – 課程信息維護、選課管理、課程成績登記和查詢等業(yè)務(wù)全部由手工方式改為計算機應(yīng)用。在這樣的培訓之后，一個有經(jīng)驗的用戶每天的出錯平均數(shù)不應(yīng)超過 2次。 ? 系統(tǒng)必須有能力存儲平均操作連續(xù) 100天所產(chǎn)生的事務(wù)。 Gerhard 你什么意思？我不是剛告訴你我的需求了嗎？ Cynthia 你只說明了整個項目的概念與目標，這些高層次的業(yè)務(wù)需求并不能為我們提供足夠的詳細信息以確定究竟要開發(fā)什么樣的軟件，以及需要多長時間。 4. 與 5是矛盾的。 6．當需求變更時，對需求規(guī)格說明及需求變更實施進行管理。 2023/1/30 55 (5) 需求管理 ? 需求管理 (Requirement Management) – 定義需求基線 (迅速制定需求文檔的主體 ) – 評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它 – 以一種可控制的方式將需求變更融入到項目中 – 使當前的項目計劃與需求一致 – 估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾 (約定 ) – 讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤 – 在整個項目過程中跟蹤需求狀態(tài)及其變更情況 2023/1/30 56 需求管理 需求管理 變更控制 版本控制 需求跟蹤 需求狀態(tài)跟蹤 ? 建議變更 ? 分析影響 ? 做出決策 ? 交流 ? 合并 ? 測量需求穩(wěn)定性 ? 確定需求文檔 版本 ? 定義對其他需求 的連接鏈 ? 定義對其他系統(tǒng) 元素的連接鏈 ? 定義需求狀態(tài) ? 跟蹤需求狀態(tài) 2023/1/30 57 需求管理與需求開發(fā)的關(guān)系 2023/1/30 58 需求獲取方法 2023/1/30 59 需求獲取的基本步驟 了解 領(lǐng)域背景知識 客戶分類 (按角色 ) CxO 部門經(jīng)理 業(yè)務(wù)員 管理員 交流 需求紀要 問題？ 分類整理 功能需求 非功能需求 約束條件 業(yè)務(wù)規(guī)則 外部接口需求 建議解決方案 優(yōu)先級排序 沖突消解 簽字確認 業(yè)務(wù)需求 用戶需求 2023/1/30 60 需求獲取的基本步驟 ? 第 1步： 了解相關(guān)背景和領(lǐng)域 /行業(yè)的知識， 確定產(chǎn)品所期望的用戶類； ? 第 2步：與客戶企業(yè)或組織的高層人員進行 交流 ，了解實際用戶任務(wù)和目標 以及這些任務(wù)所支持的 業(yè)務(wù)需求 ； ? 第 3步：與客戶企業(yè)或組織的底層人員進行 交流 ，獲取 每個用戶類的 詳細的用戶需求； ? 第 4步： 整理需求紀要 ， 發(fā)現(xiàn)新問題 ，并重復 13步； ? 第 5步： 需求分類和組織， 以區(qū)別 功能需求、非功能需求、約束條件、業(yè)務(wù)規(guī)則、外部接口需求 、建議解決方法和附加信息； ? 第 6步： 優(yōu)先排序和沖突解決； ? 第 7步：得到最終需求清單，并與客戶做 最終簽字確認。這往往會造成某些需求被忽略； 2023/1/30 78 需求研討會 (Workshop) 2023/1/30 79 需求研討會 (Workshop) 2023/1/30 80 需求研討會 (Workshop) ? 通過讓所有相關(guān)人員一起參加某個單一會議來定義需求或設(shè)計系統(tǒng)，也稱聯(lián)合應(yīng)用設(shè)計會議 (Joint Application Design, JAD)。 2023/1/30 88 需求分析的任務(wù)與原則 1. 繪制系統(tǒng)關(guān)聯(lián)圖 關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。 2023/1/30 91 需求分析的任務(wù)與原則 需求分析的原則 1． 必須能夠表達和理解問題的數(shù)據(jù)域和功能域 對于計算機程序處理的數(shù)據(jù) ， 其數(shù)據(jù)域應(yīng)包括數(shù)據(jù)流 、 數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu) 。 2023/1/30 94 2023/1/30 95 ? 需求建模方法的共同特性 ： 1． 提供描述手段 2． 提供基本步驟 ? 建模方法主要包括結(jié)構(gòu)化的需求建模方法和面向?qū)ο蟮男枨蠼７椒? 2023/1/30 96 ? 基本特點是表達問題時盡可能使用圖形符號的形式 ， 設(shè)計數(shù)據(jù)流圖時只考慮系統(tǒng)必須完成的基本功能 ， 不必考濾如何具體實現(xiàn)這些功能 。 ? 編號： – 1層 DFD： 、 、 … 、 – 2層 DFD： 、 、 … 、 – … 2023/1/30 109 底層 DFD 學生教師教務(wù)部課程安排注冊請求1 安排課表2 學生注冊3產(chǎn)生班級列表班級列表提供的課程學生信息庫 課程注冊信息課程安排數(shù)據(jù)0層 DFD 教務(wù)部1 .1 選擇日期1 .2選擇教師提供的課程1 .3選擇教室課程可用教師可用教室1層 DFD 2023/1/30 110 數(shù)據(jù)流的分解 客戶1處理訂單2……訂單 訂單客戶1 .2處理標準訂單訂單 標準訂單1 .1處理長期訂單1 .3處理緊急訂單長期訂單標準訂單緊急訂單長期訂單緊急訂單2023/1/30 111 如何識別數(shù)據(jù)流 ? 通過識別“事件”來識別數(shù)據(jù)流，進而識別得到加工、數(shù)據(jù)存儲 ? 事件的分類： – 外部事件 (External events)：外部實體與系統(tǒng)進行交互 (顧客下訂單、供應(yīng)商的貨物到達 ) – 決策事件 (Decision events)：需要外部實體為系統(tǒng)某些業(yè)務(wù)做出決策 (是否接受訂單 ) – 時間性事件 (Temporal events)：由時間所觸發(fā)的周期性時間 (每月25號編制下月計劃、每天 17點盤點庫存 ) – 狀態(tài)事件 (State events)：由某些數(shù)據(jù)的變化所自動觸發(fā)的事件 (當庫存量下降到 100以下時，啟動采購流程 ) 2023/1/30 112 繪制 DFD的一些基本原則 外部實體 1數(shù)據(jù)流 2數(shù)據(jù)流 1外部實體 2數(shù)據(jù)流 4數(shù)據(jù)流 3數(shù)據(jù)存儲 1數(shù)據(jù)存儲 20 系統(tǒng)數(shù)據(jù)流1 加工 12加工 2? 把數(shù)據(jù)存儲放在 0層數(shù)據(jù)流圖或更低層子圖上，不要放在頂層的關(guān)聯(lián)圖上 ? 使用數(shù)據(jù)流圖時，不要試圖讓數(shù)據(jù)流圖反映處理的順序，忽略系統(tǒng)的運行時的時間特性 ? 加工通過數(shù)據(jù)存儲進行通訊，而盡量避免從一個過程直接流到另一過程 2023/1/30 113 繪制 DFD的一些基本原則 外部實體 1 外部實體 2 數(shù)據(jù)流 數(shù)據(jù)存儲 1 外部實體 1 數(shù)據(jù)流 數(shù)據(jù)存儲 1 外部實體 1 數(shù)據(jù)流 數(shù)據(jù)存儲 1 數(shù)據(jù)流 數(shù)據(jù)存儲 2 ? 數(shù)據(jù)不能直接由一個數(shù)據(jù)存儲直接流到另一個數(shù)據(jù)存儲 ? 數(shù)據(jù)不能直接從一個外部實體直接流到一個數(shù)據(jù)存儲 ? 數(shù)據(jù)不能直接從一個數(shù)據(jù)存儲直接流到一個外部實體 ? 數(shù)據(jù)不能直接在外部實體之間流動 2023/1/30 114 數(shù)據(jù)流 1加工數(shù)據(jù)流2加工繪制 DFD的一些基本原則 ? 數(shù)據(jù)流是單向的 ? 任何加工必須有輸入和輸出數(shù)據(jù)流 ? 對現(xiàn)有加工進行持續(xù)的分解和組合，直到所有加工之間達到較高的聚合度； ? 盡量將每一張 DFD上的所有元素數(shù)目控制在 712個。 2023/1/30 125 數(shù)據(jù)流圖 5．數(shù)據(jù)流圖的優(yōu)缺點 (1) 總體概念強，每一層都明確強調(diào)干什么，需要什么，給出什么。 5．數(shù)據(jù)字典的實現(xiàn) 目前實現(xiàn)數(shù)據(jù)字典有三種常見的途徑：全人工過程，全自動化過程（利用數(shù)據(jù)字典處理程序）和混合過程（用正文編輯程序、報告生成程序等已有的實用程序幫助人工過程）。 – 市話號碼是任意 7位或 8位長度的數(shù)字串。 需求驗證的任務(wù)就是要求各方人員從不同技術(shù)角度對需求規(guī)格說明文檔作出綜合性評價 。主要包括下述內(nèi)容 : 需求是否完整 、 一致 、 可理解 、 明確 、 可實現(xiàn) 、 可跟蹤 、 易修改 、 需求規(guī)格說明文檔是否完整等 2023/1/30 151 需求開發(fā)的管理 需求管理活動 2023/1/30 152 ? 需求管理的目的是在客戶和軟件項目組之間建立對需求的共同理解。 ? 本章主要介紹了需求分析的任務(wù)和步驟 、 需求分析方法和需求分析規(guī)格說明 。 2023/1/30 153 1. 需求必須分層次管理 2. 需求要分優(yōu)先級 3. 需求必須文檔化 4. 需求變更的影響要評估 5. 需求管理與需求工程的活動緊密整合 2023/1/30 154 需求開發(fā)的管理 (1)需求分析的進度管理與控制； (2)需求分析的質(zhì)量管理與控制； (3)需求分析階段的溝通管理。 :需求必須是完整的，規(guī)格說明書應(yīng)該包括用戶需要的每一個功能或性能。 樹形結(jié)構(gòu)的頂層是一個單獨的矩形框 ， 它代表完整的數(shù)據(jù)結(jié)構(gòu) ， 下面的各層矩形框代表這個數(shù)據(jù)的子集 ， 最底層的各個框代表組成這個數(shù)據(jù)的實際數(shù)據(jù)元素（ 不能再分割的元素 ） 。 ? 采用數(shù)據(jù)字典 (Data Dictionary)作為描述工具 ? 對于 DFD中出現(xiàn)的所有被命名的圖形元素 (數(shù)據(jù)流、數(shù)據(jù)項、數(shù)據(jù)存儲、加工 )在 DD中作為一個詞條加以定義，使得每一個圖形元素的名字都有一個確切的解釋。 (3) 由于自頂向下分析，容易及早發(fā)現(xiàn)并修正系統(tǒng)各部分的邏輯錯誤。 加工 加工 加工 a b c d e 加工 加工 加工 a a1 a2 b c 2023/1/30 116 父圖與子圖的平衡 ? 數(shù)據(jù)流本身可以分解，但其包含的數(shù)據(jù)內(nèi)容應(yīng)保持平衡 加工 加工 加工 a b c d e 加工 加工 加工 c c1 c2 d1 d2 d1+d2=d 2023/1/30 117 DFD實例：銷售系統(tǒng) ? 某企業(yè)銷售管理系統(tǒng)： – 接受顧客的訂單，檢驗訂單，若庫存有貨，進行供貨處理，即修改庫存，給倉庫開備貨單，并且