【正文】 xtlevel DFD，或 Context Diagram)：也稱頂層DFD圖 ，描述了系統(tǒng)與外部環(huán)境之間的數(shù)據(jù)輸入 /輸出關(guān)系； – 系統(tǒng)內(nèi)部 DFD圖 (Innerlevel DFD)： 描述系統(tǒng)內(nèi)部各功能模塊之間的數(shù)據(jù)流動(dòng)關(guān)系 ? 0層 DFD圖 ? 1層 DFD圖 ? … ? N層 DFD圖 2023/1/30 105 頂層 DFD ? 頂層 DFD圖 (關(guān)聯(lián)圖 ) – 通過系統(tǒng)和外部世界之間的聯(lián)系來描述系統(tǒng)的范圍 – 確定了通過某一接口與系統(tǒng)相連的外部實(shí)體，同時(shí)也確定了外部實(shí)體和系統(tǒng)之間的數(shù)據(jù)流 – 只包含一個(gè)加工，用以表示被開發(fā)的系統(tǒng)，然后考慮該系統(tǒng)有哪些輸入數(shù)據(jù)、輸出數(shù)據(jù)流 – 編號(hào)： 0 0系統(tǒng)外部實(shí)體 I1外部實(shí)體 I2外部實(shí)體 In…外部實(shí)體 O1外部實(shí)體 O2外部實(shí)體 Om…輸入信息 1輸入信息 2輸入信息 n輸出信息 1輸出信息 2輸出信息 n2023/1/30 106 示例：頂層 DFD 學(xué)生教師教務(wù)部課程安排注冊(cè)請(qǐng)求0課程注冊(cè)系統(tǒng)班級(jí)列表課程安排數(shù)據(jù)2023/1/30 107 0層 DFD ? 將頂層 DFD圖中的系統(tǒng)分解為若干個(gè)子系統(tǒng)，決定每個(gè)子系統(tǒng)間的數(shù)據(jù)接口和活動(dòng)關(guān)系，得到 0層 DFD圖； ? 編號(hào)： … 、 n 學(xué)生教師教務(wù)部課程安排注冊(cè)請(qǐng)求1 安排課表2 學(xué)生注冊(cè)3產(chǎn)生班級(jí)列表班級(jí)列表提供的課程學(xué)生信息庫 課程注冊(cè)信息課程安排數(shù)據(jù)2023/1/30 108 底層 DFD ? 針對(duì) 0層 DFD中的每一個(gè)子系統(tǒng)，對(duì)其繼續(xù)分解得到細(xì)化的加工，進(jìn)而逐漸向下構(gòu)造得到 1層 DFD、 2層 DFD、 … 、 n層 DFD， 一直到不能或不需再分解為止。 ? 描述手段 ① 一套分層的數(shù)據(jù)流圖 ② 一本詞典 ③ 其他補(bǔ)充材料 2023/1/30 97 數(shù)據(jù)流圖 (DFD) ? 數(shù)據(jù)流圖 (Data Flow Diagram, DFD)： 結(jié)構(gòu)化系統(tǒng)分析的基本工具 – 描繪數(shù)據(jù)在系統(tǒng)中各邏輯功能模塊之間的流動(dòng)和處理過程，是一種功能模型 – 主要刻畫“功能的輸入和輸出數(shù)據(jù)”、“數(shù)據(jù)的源頭和目的地” 2023/1/30 98 DFD的主要元素 銷售訂單 1 錄入訂單 銷售訂單 客戶 數(shù)據(jù)流 加工 數(shù)據(jù)存儲(chǔ) 外部實(shí)體 2023/1/30 99 DFD的主要元素 (1)：加工 ? 加工 (又稱數(shù)據(jù)處理， data processing)：對(duì)數(shù)據(jù)流進(jìn)行某些操作或變換。 ? 軟件需求的邏輯視圖給出軟件要達(dá)到的功能和要處理數(shù)據(jù)之間的關(guān)系 。 2023/1/30 92 需求分析的任務(wù)與原則 需求分析的原則 、 逐層分解問題 ? 分解問題是把問題以某種方式分解為幾個(gè)較易理解的部分 ， 并確定各部分間的接口 ，從而實(shí)現(xiàn)整體功能 。 7. 質(zhì)量功能調(diào)配 質(zhì)量功能調(diào)配是一種高級(jí)系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對(duì)客戶的重要性聯(lián)系起來。 2023/1/30 89 需求分析的任務(wù)與原則 3. 分析需求可行性 在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性。 需 求 獲 取 需 求 分 析 需 求 描 述 需 求 驗(yàn) 證 需 求 管 理需 求 開 發(fā) 過 程 需 求 管 理 過 程2023/1/30 87 需求分析的任務(wù)與原則 ? 需求分析的基本任務(wù)是分析與綜合已收集到的需求信息，通過分析找出需求信息內(nèi)在聯(lián)系和可能的矛盾，通過綜合找出解決問題的方法并建立系統(tǒng)的邏輯模型。 ? 協(xié)助建立一支高效團(tuán)隊(duì)，圍繞一個(gè)目的：項(xiàng)目的成功； ? 所有人員都暢所欲言； ? 促進(jìn)用戶與開發(fā)團(tuán)隊(duì)之間達(dá)成共識(shí)； ? 能夠揭露和解決那些妨礙項(xiàng)目成功的行政問題； ? 最終很快產(chǎn)生初步的系統(tǒng)定義。 2023/1/30 77 面對(duì)面訪談的優(yōu)缺點(diǎn)分析 ? 優(yōu)點(diǎn)： – 人們很愿意談?wù)撟约旱墓ぷ鳎⑶铱偸呛芟矚g接受訪談； ? 缺點(diǎn)： – 大多數(shù)人都采用專業(yè)術(shù)語和“行話”，而太多的專業(yè)術(shù)語讓需求工程師難以理解，往往造成很多誤解； – 有些需求對(duì)用戶來說太普通了，以至于他們不自覺地認(rèn)為這些需求太基本，不值得去提。 ? 通過提問題增強(qiáng)你對(duì)談話進(jìn)展和方向的控制 ? 問題不能過于寬泛 ? 最開始的問題不能太難 ? 不能在提問之前就已經(jīng)表示不贊同 ? 談話之前有意識(shí)的準(zhǔn)備一些備用問題 2023/1/30 70 訪談問題的分類 ? 上下文無關(guān)的問題 (contextfree questions)：充分理解用戶的問題，不涉及具體的解決方案 – 客戶是誰？ – 最終用戶是誰？ – 不同用戶的需求是否不同？ – 這種需求目前的解決方案是什么？ ? 解決方案相關(guān)的問題 (solutioncontext questions)：通過這類問題，探尋特定的解決方案并得到用戶認(rèn)可 – 你希望如何解決這個(gè)問題？ – 你覺得該問題這樣解決如何？ 2023/1/30 71 面談之前 ? 確立面談目的 ? 確定要包括的相關(guān)用戶 ? 確定參加會(huì)議的項(xiàng)目小組成員 ? 建立要討論的問題和要點(diǎn)列表 ? 復(fù)查有關(guān)文檔和資料 ? 確立時(shí)間和地點(diǎn) ? 通知所有參加者有關(guān)會(huì)議的目的、時(shí)間和地點(diǎn) 2023/1/30 72 面談之中 ? Step 1：事先準(zhǔn)備一系列上下文無關(guān)的問題，并將其記錄下來以便面談時(shí)參考； ? Step 2：面談前，了解一下要面談的客戶公司的背景資料，不要選擇自己能回答的問題而浪費(fèi)時(shí)間； ? Step 3：面談過程中，參考事先準(zhǔn)備的面談模板，以保證提出的問題是正確的。 需求管理的任務(wù)是管理軟件系統(tǒng)的需求規(guī)格說明和文檔，評(píng)估需求變更帶來的影響及成本費(fèi)用，跟蹤軟件需求的狀態(tài)，管理需求規(guī)格說明的版本等。 需 求 獲 取 需 求 分 析 需 求 描 述 需 求 驗(yàn) 證 需 求 管 理需 求 開 發(fā) 過 程 需 求 管 理 過 程2023/1/30 47 確定和 收集 與待開發(fā)的軟件系統(tǒng)相關(guān)的用戶需求信息。 2023/1/30 45 需求工程概念 需求工程的任務(wù)： 4．根據(jù)收集的需求信息和邏輯模型編寫需求規(guī)格說明及文檔。 ? 需求工程的目標(biāo)是獲取高質(zhì)量的軟件需求。 3. ―盡快”是不可驗(yàn)證的，應(yīng)該給出具體數(shù)量值。 Gerhard 那些化學(xué)專家都非常忙，沒有時(shí)間與你們?cè)敿?xì)討論各種細(xì)節(jié)，你不能讓你的手下的人說明要做的系統(tǒng)嗎？ Cynthia 如果我們只是憑空猜想用戶要求，結(jié)果不會(huì)令人滿意。全部要求是指軟件系統(tǒng)必須提供的功能和性能、約束條件和限制。 ? 系統(tǒng)應(yīng)該在 1分鐘內(nèi)從 1000000條記錄中檢索出一個(gè)銷售訂單。 – 通常表達(dá)為“如果 … ，那么 …‖ 的形式 – 通常是一些容易發(fā)生變化的功能； ? 例如： – 如果借書卡類型為“教師”，那么一次借閱的最大數(shù)量為 8本； – 如果訂單金額大于 10000元，那么該訂單的折扣為 10%； – 如果采購單金額在 10萬到 50萬之間，那么需要總經(jīng)理審批； 2023/1/30 29 7. 外部接口需求 ? 外部接口需求 (External Interface Requirement)： 描述系統(tǒng)與其所處的 外部環(huán)境之間如何進(jìn)行交互 ，包括： – 用戶接口需求 (UI) – 硬件接口需求 – 軟件接口需求 – 通信接口需求 ? 例如： – “從 某些設(shè)備 讀取信號(hào)” – “給 一些其它系統(tǒng) 發(fā)送消息” – “以 某種格式 讀取文件” – “能控制 一些硬件 ‖ – ―采用 某種類型的 用戶界面” 2023/1/30 30 關(guān)于需求的一些例子 ? 系統(tǒng)必須有能力支持 100個(gè)以上的并發(fā)用戶，每個(gè)用戶可以處理操作任務(wù)的任選組合，平均響應(yīng)時(shí)間應(yīng)該小于 1秒，最大響應(yīng)時(shí)間應(yīng)小于 5秒。 非功能需求的度量 非功能特性 度量指標(biāo) 速度 每秒處理的事務(wù) 用戶的響應(yīng)時(shí)間 屏幕的刷新速度 存儲(chǔ)空間 字節(jié)數(shù) RAM芯片數(shù) 可用性 培訓(xùn)時(shí)間 幫助頁面數(shù) 可靠性 平均失敗時(shí)間 系統(tǒng)無效的概率 失敗發(fā)生率 容錯(cuò)性 失敗后的重啟次數(shù) 事件引起失敗的比例 失敗時(shí)數(shù)據(jù)崩潰的可能性 2023/1/30 26 一個(gè)例子：拼寫檢查器 ? 業(yè)務(wù)需求： “用戶能有效地糾正文檔中的拼寫錯(cuò)誤” ； ? 用戶需求： “找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來供選擇替換拼錯(cuò)的詞”； ? 功能性需求： – 找到拼寫錯(cuò)誤的單詞并以高亮度提示 – 顯示提供替換詞的對(duì)話框 – 實(shí)現(xiàn)整個(gè)文檔范圍的替換 ? 非功能性需求： – 正確的找到至少 95%以上的錯(cuò)詞并 100%的加以正確替換 – 拼寫檢查的速度應(yīng)至少達(dá)到 5000詞 /秒。 ? 注意：非功能需求隱含了對(duì)可選設(shè)計(jì)方案的一些關(guān)鍵影響 – 體系結(jié)構(gòu)設(shè)計(jì) (., 體系結(jié)構(gòu)風(fēng)格選擇 ) – 算法設(shè)計(jì) (., 排序策略的選擇 ) 2023/1/30 24 非功能需求的度量 ? NFR：檢驗(yàn)起來非常困難，一般采用一些可度量的特性進(jìn)行描述。 – 學(xué)生希望能夠在學(xué)期開始之前查詢所有開設(shè)課程的詳細(xì)信息，并能夠通過校園網(wǎng)進(jìn)行選課。 2023/1/30 20 2. 用戶需求 (目標(biāo)需求 ) ? 用戶需求 (User Requirements)： 從用戶角度描述的 系統(tǒng)功能需求與非功能需求 ，通常只涉及系統(tǒng)的 外部行為 而不涉及內(nèi)部特性。 ? 軟件需求： 以一種清晰、簡(jiǎn)潔、一致且無二義性的方式，描述用戶對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望，是在開發(fā)過程中對(duì)系統(tǒng)的約束。 Maria 可是每個(gè)人只要愿意就可以隨時(shí)改變自己的名字啊。2023/1/30 1 第三章 需求工程 主講：任向民 2023/1/30 2 第三章 需求工程 2023/1/30 3 軟件需求定義 2023/1/30 4 軟件需求的分類 軟件需求的定義 2023/1/30 5 ? 軟件需求工程的目的是定義軟件所需要解決的問題 。 2023/1/30 8 但實(shí)際情況是什么樣子？ ? 調(diào)查報(bào)告的數(shù)字是這樣的 … ?Standish Group 2023 Succeeded Challenged Failed 用戶參與程度高： 16% 用戶高層的支持： 14% 對(duì)需求的清晰陳述： 12% 缺乏用戶參與： 13% 需求規(guī)格說明不完整： 12% 需求頻繁的發(fā)生變化： 12% 結(jié)論： 對(duì)用戶需求的管理水平 是決定軟件成敗的重要原因 2023/1/30 9 [案例分析 1] ―只有結(jié)婚后才可以修改姓名嗎？” ? Phil開發(fā)了一套人力資源軟件，有一天他接到了人力資源部 Maria打來的電話 … Maria 一個(gè)同事想把自己名字改為 Sparkle Starlight，但系統(tǒng)不允許，能幫忙嗎？ Phil 她嫁給了一個(gè)姓 Starlight的人嗎？ Maria 不，她并沒有結(jié)婚，她只是想改名字而已； Phil 系統(tǒng)只支持在改變婚姻狀況時(shí)才可以改名字。 2023/1/30 14 什么是“軟件需求” ? 軟件需求 (Software Requirements)： – 用戶解決問題以達(dá)到特定目標(biāo)所需的能力； – 系統(tǒng)或系統(tǒng)構(gòu)件要滿足的合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔所需具備的能力； ——IEEE, 1997 – 指用戶對(duì)軟件的功能與性能需求 ,就是用戶希望軟件能夠做什么事情 ,完成哪些功能，達(dá)到