【正文】 將訂單留底；若庫(kù)存量不足，將缺貨訂單登入缺貨記錄。 ? 描述手段 ① 一套分層的數(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)和處理過(guò)程，是一種功能模型 – 主要刻畫(huà)“功能的輸入和輸出數(shù)據(jù)”、“數(shù)據(jù)的源頭和目的地” 2023/1/30 98 DFD的主要元素 銷(xiāo)售訂單 1 錄入訂單 銷(xiāo)售訂單 客戶 數(shù)據(jù)流 加工 數(shù)據(jù)存儲(chǔ) 外部實(shí)體 2023/1/30 99 DFD的主要元素 (1)：加工 ? 加工 (又稱(chēng)數(shù)據(jù)處理， data processing)：對(duì)數(shù)據(jù)流進(jìn)行某些操作或變換。 2023/1/30 92 需求分析的任務(wù)與原則 需求分析的原則 、 逐層分解問(wèn)題 ? 分解問(wèn)題是把問(wèn)題以某種方式分解為幾個(gè)較易理解的部分 ， 并確定各部分間的接口 ，從而實(shí)現(xiàn)整體功能 。 2023/1/30 89 需求分析的任務(wù)與原則 3. 分析需求可行性 在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性。 ? 協(xié)助建立一支高效團(tuán)隊(duì)，圍繞一個(gè)目的：項(xiàng)目的成功； ? 所有人員都暢所欲言； ? 促進(jìn)用戶與開(kāi)發(fā)團(tuán)隊(duì)之間達(dá)成共識(shí)； ? 能夠揭露和解決那些妨礙項(xiàng)目成功的行政問(wèn)題； ? 最終很快產(chǎn)生初步的系統(tǒng)定義。 ? 通過(guò)提問(wèn)題增強(qiáng)你對(duì)談話進(jìn)展和方向的控制 ? 問(wèn)題不能過(guò)于寬泛 ? 最開(kāi)始的問(wèn)題不能太難 ? 不能在提問(wèn)之前就已經(jīng)表示不贊同 ? 談話之前有意識(shí)的準(zhǔn)備一些備用問(wèn)題 2023/1/30 70 訪談問(wèn)題的分類(lèi) ? 上下文無(wú)關(guān)的問(wèn)題 (contextfree questions)：充分理解用戶的問(wèn)題，不涉及具體的解決方案 – 客戶是誰(shuí)？ – 最終用戶是誰(shuí)？ – 不同用戶的需求是否不同？ – 這種需求目前的解決方案是什么？ ? 解決方案相關(guān)的問(wèn)題 (solutioncontext questions)：通過(guò)這類(lèi)問(wèn)題，探尋特定的解決方案并得到用戶認(rèn)可 – 你希望如何解決這個(gè)問(wèn)題？ – 你覺(jué)得該問(wèn)題這樣解決如何？ 2023/1/30 71 面談之前 ? 確立面談目的 ? 確定要包括的相關(guān)用戶 ? 確定參加會(huì)議的項(xiàng)目小組成員 ? 建立要討論的問(wèn)題和要點(diǎn)列表 ? 復(fù)查有關(guān)文檔和資料 ? 確立時(shí)間和地點(diǎn) ? 通知所有參加者有關(guān)會(huì)議的目的、時(shí)間和地點(diǎn) 2023/1/30 72 面談之中 ? Step 1：事先準(zhǔn)備一系列上下文無(wú)關(guān)的問(wèn)題，并將其記錄下來(lái)以便面談時(shí)參考； ? Step 2：面談前，了解一下要面談的客戶公司的背景資料，不要選擇自己能回答的問(wèn)題而浪費(fèi)時(shí)間； ? Step 3：面談過(guò)程中，參考事先準(zhǔn)備的面談模板，以保證提出的問(wèn)題是正確的。 需 求 獲 取 需 求 分 析 需 求 描 述 需 求 驗(yàn) 證 需 求 管 理需 求 開(kāi) 發(fā) 過(guò) 程 需 求 管 理 過(guò) 程2023/1/30 47 確定和 收集 與待開(kāi)發(fā)的軟件系統(tǒng)相關(guān)的用戶需求信息。 ? 需求工程的目標(biāo)是獲取高質(zhì)量的軟件需求。 Gerhard 那些化學(xué)專(zhuān)家都非常忙，沒(méi)有時(shí)間與你們?cè)敿?xì)討論各種細(xì)節(jié)，你不能讓你的手下的人說(shuō)明要做的系統(tǒng)嗎？ Cynthia 如果我們只是憑空猜想用戶要求，結(jié)果不會(huì)令人滿意。 ? 系統(tǒng)應(yīng)該在 1分鐘內(nèi)從 1000000條記錄中檢索出一個(gè)銷(xiāo)售訂單。 非功能需求的度量 非功能特性 度量指標(biāo) 速度 每秒處理的事務(wù) 用戶的響應(yīng)時(shí)間 屏幕的刷新速度 存儲(chǔ)空間 字節(jié)數(shù) RAM芯片數(shù) 可用性 培訓(xùn)時(shí)間 幫助頁(yè)面數(shù) 可靠性 平均失敗時(shí)間 系統(tǒng)無(wú)效的概率 失敗發(fā)生率 容錯(cuò)性 失敗后的重啟次數(shù) 事件引起失敗的比例 失敗時(shí)數(shù)據(jù)崩潰的可能性 2023/1/30 26 一個(gè)例子：拼寫(xiě)檢查器 ? 業(yè)務(wù)需求： “用戶能有效地糾正文檔中的拼寫(xiě)錯(cuò)誤” ； ? 用戶需求： “找出文檔中的拼寫(xiě)錯(cuò)誤并通過(guò)一個(gè)提供的替換項(xiàng)列表來(lái)供選擇替換拼錯(cuò)的詞”； ? 功能性需求： – 找到拼寫(xiě)錯(cuò)誤的單詞并以高亮度提示 – 顯示提供替換詞的對(duì)話框 – 實(shí)現(xiàn)整個(gè)文檔范圍的替換 ? 非功能性需求： – 正確的找到至少 95%以上的錯(cuò)詞并 100%的加以正確替換 – 拼寫(xiě)檢查的速度應(yīng)至少達(dá)到 5000詞 /秒。 – 學(xué)生希望能夠在學(xué)期開(kāi)始之前查詢所有開(kāi)設(shè)課程的詳細(xì)信息，并能夠通過(guò)校園網(wǎng)進(jìn)行選課。 ? 軟件需求： 以一種清晰、簡(jiǎn)潔、一致且無(wú)二義性的方式，描述用戶對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望，是在開(kāi)發(fā)過(guò)程中對(duì)系統(tǒng)的約束。2023/1/30 1 第三章 需求工程 主講：任向民 2023/1/30 2 第三章 需求工程 2023/1/30 3 軟件需求定義 2023/1/30 4 軟件需求的分類(lèi) 軟件需求的定義 2023/1/30 5 ? 軟件需求工程的目的是定義軟件所需要解決的問(wèn)題 。 2023/1/30 14 什么是“軟件需求” ? 軟件需求 (Software Requirements)： – 用戶解決問(wèn)題以達(dá)到特定目標(biāo)所需的能力； – 系統(tǒng)或系統(tǒng)構(gòu)件要滿足的合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔所需具備的能力； ——IEEE, 1997 – 指用戶對(duì)軟件的功能與性能需求 ,就是用戶希望軟件能夠做什么事情 ,完成哪些功能，達(dá)到哪些性能等 。 ? 用戶需求 – 教務(wù)管理員希望能夠增加、修改和刪除學(xué)校的課程目錄，并且設(shè)置各學(xué)期課程的開(kāi)設(shè)信息。 2023/1/30 25 ? NFR：檢驗(yàn)起來(lái)非常困難，一般采用一些可度量的特性進(jìn)行描述。 ? 系統(tǒng)應(yīng)該在 5分鐘內(nèi)計(jì)算出給定季度的總銷(xiāo)售稅。我需要一些分析人員與一些知道系統(tǒng)使用要求的化學(xué)專(zhuān)家進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。 考慮以下需求是否滿足“好需求”的標(biāo)準(zhǔn)，如不是，該如何修正？ 1. 在用戶每次存錢(qián)時(shí)系統(tǒng)將進(jìn)行信用檢查； 2. 如果用戶試圖透支，系統(tǒng)將采取適當(dāng)?shù)男袆?dòng)； 3. 系統(tǒng)將盡可能快的響應(yīng)所有有效的請(qǐng)求； 4. 系統(tǒng)允許立即使用所存資金； 5. 只有在手工驗(yàn)證所存資金后，系統(tǒng)才能允許使用它； 2023/1/30 40 需求規(guī)格說(shuō)明 軟件需求規(guī)格說(shuō)明的一般格式 ： 1．引言 2．任務(wù)概述 3．?dāng)?shù)據(jù)描述 4．功能要求 5．性能需求 6．運(yùn)行需求 7．其他要求（如可使用性、安全保密、可維護(hù)性、可移植性等） 8．附錄 2023/1/30 41 需求規(guī)格說(shuō)明 需求規(guī)格說(shuō)明的特性如下： 1．完整性 2. 正確性 3. 可行性 4. 必要性 5. 無(wú)歧義性 6. 可驗(yàn)證性 7. 劃分優(yōu)先級(jí) 2023/1/30 42 需求工程 2023/1/30 43 需求工程概念 ? 需求工程就是應(yīng)用工程化的方法、技術(shù)和規(guī)格來(lái)開(kāi)發(fā)和管理軟件的需求。 2023/1/30 46 需求工程過(guò)程分為需求開(kāi)發(fā)和需求管理兩階段。 2023/1/30 61 “看似簡(jiǎn)單，實(shí)際卻很難 …‖ —— ―需求獲取？不就是問(wèn)問(wèn)題嗎？這有什么難的？” 2023/1/30 65 需求獲取技術(shù) ? 需求獲取的關(guān)鍵： – 溝通和交流 ? 所要避免的問(wèn)題： – 交流障礙、溝通不全、意見(jiàn)沖突 ? 所要必備的條件： – 較高的技術(shù)水平、豐富的實(shí)踐經(jīng)驗(yàn)、較強(qiáng)的人際交往能力 ? 可能采取的手段： – 用戶訪談、現(xiàn)場(chǎng)考察、專(zhuān)家咨詢、會(huì)議討論、 … 2023/1/30 66 需求獲取技術(shù) ? 面對(duì)面訪談 (facetoface interviewing) ? 專(zhuān)題討論會(huì) (workshop) ? 現(xiàn)場(chǎng)觀察 (observing on the scene) ? 頭腦風(fēng)暴 (brain storming) ? 多種方法要復(fù)合在一起使用，效果更好 2023/1/30 67 面對(duì)面訪談 2023/1/30 68 面對(duì)面訪談 ? 需求獲取中最直接的方法：用戶面談 (interviewing) ? ―看起來(lái)很美”，但“做起來(lái)并不容易” ——需求分析者個(gè)人的偏見(jiàn)、事先的理解、以往的經(jīng)驗(yàn)積累是導(dǎo)致面談失敗的最重要原因 ——在面談時(shí)，忘掉一切以往所作的事情，通過(guò)問(wèn)題啟發(fā)，傾聽(tīng)對(duì)方的陳述 ——不要把自己放在“專(zhuān)家”的位置上 2023/1/30 69 如何提問(wèn)？ ? “每個(gè)人都能提問(wèn)題，但并不等于人人都會(huì)提問(wèn)題 …‖ ? 封閉式問(wèn)題： – 對(duì)錯(cuò)判斷或多項(xiàng)選擇題，回答只需要一兩個(gè)詞 ? 開(kāi)放式問(wèn)題： – 這種問(wèn)題需要解釋和說(shuō)明，同時(shí)向?qū)Ψ奖硎灸銓?duì)他們說(shuō)的話很感興趣，還想了解更多的內(nèi)容。 ? 系統(tǒng)相關(guān)者在短暫而緊湊的時(shí)間段內(nèi)集中在一起，一般為1至 2天，與會(huì)者可以在應(yīng)用需求上達(dá)成共識(shí)、對(duì)操作過(guò)程盡快取得統(tǒng)一意見(jiàn)。 2. 創(chuàng)建用戶接口原型 當(dāng)開(kāi)發(fā)人員或用戶不能確定軟件需求時(shí)，開(kāi)發(fā)一個(gè)用戶接口原型 (可能的局部實(shí)現(xiàn) )，這樣使得許多概念和可能發(fā)生的事更為直觀明了。 就是將一種形式的數(shù)據(jù)轉(zhuǎn)換成另一種形式的數(shù)據(jù) 。 ? 基本思想是按照由抽象到具體 、 逐層分解的方法 ， 確定軟件系統(tǒng)內(nèi)部的數(shù)據(jù)流 、 變換關(guān)系 ， 并用數(shù)據(jù)流圖表示 。 外部實(shí)體 1數(shù)據(jù)流外部實(shí)體 2數(shù)據(jù)流數(shù)據(jù)存儲(chǔ) 10 系統(tǒng)2023/1/30 115 父圖與子圖的平衡 ? 下層 DFD中的輸入輸出數(shù)據(jù)流同上層 DFD中相應(yīng)加工的輸入輸出數(shù)據(jù)流必須一致，此即父圖與子圖的平衡。 (2) 可以反映出數(shù)據(jù)的流向和處理過(guò)程。 2023/1/30 131 數(shù)據(jù)字典 (DD) ? DFD只是繪制了系統(tǒng)各功能之間的數(shù)據(jù)流動(dòng)和處理關(guān)系，還需進(jìn)一步考慮各數(shù)據(jù)的具體內(nèi)容。 2023/1/30 139 示例：數(shù)據(jù)字典 (1) ? “電話號(hào)碼”的數(shù)據(jù)字典： – 電話號(hào)碼 =[分機(jī)號(hào) |外線號(hào)碼 ] – 分機(jī)號(hào) =8201..8299 – 外線號(hào)碼 =0+[市話號(hào)碼 |長(zhǎng)途電話號(hào)碼 ] – 市話號(hào)碼 ={數(shù)字 } – 長(zhǎng)途電話號(hào)碼 =區(qū)號(hào) +市話號(hào)碼 – 區(qū)號(hào) =[010|021..029|0300..0999] 2023/1/30 140 示例：數(shù)據(jù)字典 (2) 名字： 零件編號(hào) 別名： 編碼 描述： 唯一的標(biāo)識(shí)庫(kù)存清單中一個(gè)特定零件 定義： 零件編號(hào) ={字符 }8 位置： 庫(kù)存清單 采購(gòu)訂單 訂貨報(bào)表 名字： 采購(gòu)訂單 別名： 采購(gòu)單 描述： 由各部門(mén)采購(gòu)人員定期向供應(yīng)商發(fā)出的單據(jù) 定義： 采購(gòu)訂單 =供應(yīng)商 ID+供應(yīng)商名稱(chēng) +采購(gòu)日期 +總金額 + {零件編號(hào) +零件名稱(chēng) +數(shù)量 +價(jià)格 } 位置： 訂貨報(bào)表 2023/1/30 141 層次方框圖 Warnier圖 IPO圖 2023/1/30 142 層次方框圖 ? 層次方框圖用樹(shù)形結(jié)構(gòu)的一系列多層次的矩形框描述數(shù)據(jù)的層次結(jié)構(gòu) 。 2023/1/30 147 需求分析評(píng)審的主要內(nèi)容 : :所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。 ? 需求管理的目標(biāo)如下： 1. 控制軟件需求，并建立軟件工程和管理使用的需求基線； 2. 使軟件計(jì)劃、產(chǎn)品和活動(dòng)與軟件需求保持一致。 演講完畢，謝謝觀看！