【正文】 哪些性能等 。 2023/1/30 17 軟件需求的分類 軟件需求的分類 2023/1/30 18 不同層次的軟件需求 業(yè)務(wù)需求項(xiàng)目視圖與范圍文檔業(yè)務(wù)規(guī)則用例文檔功能需求軟件需求規(guī)格說明外部接口需求用戶需求功能性需求 非功能性需求約束條件非功能需求2023/1/30 19 1. 業(yè)務(wù)需求 ? 業(yè)務(wù)需求 (Business Requirements)： 客戶對于系統(tǒng)的 高層次目標(biāo)要求 (highlevel objectives) ，定義了項(xiàng)目的 遠(yuǎn)景和范疇 (vision and scope) – 業(yè)務(wù)：屬于哪類業(yè)務(wù)范疇？應(yīng)完成什么功能？為何目的？ – 客戶：軟件為誰服務(wù)？目標(biāo)客戶是誰？ – 特性：區(qū)別于其他競爭產(chǎn)品的特性是什么？ – 價(jià)值：價(jià)值體現(xiàn)在那些方面？ – 優(yōu)先級：功能特性的優(yōu)先級次序是什么？ ? [例 ]―圖書資料管理系統(tǒng)”的業(yè)務(wù)需求 – 該系統(tǒng)使用計(jì)算機(jī)實(shí)現(xiàn)圖書資料日常管理，提高工作效率和服務(wù)質(zhì)量； – 該系統(tǒng)可讓用戶在網(wǎng)絡(luò)上查詢與瀏覽電子資料，改變原有的借閱模式； – 由于版權(quán)的限制，某些電子資料只能瀏覽 /打印，但不能下載。 ? 用戶需求 – 教務(wù)管理員希望能夠增加、修改和刪除學(xué)校的課程目錄，并且設(shè)置各學(xué)期課程的開設(shè)信息。 ? [例 ] – 系統(tǒng)在 20秒內(nèi)響應(yīng)所有的請求； – 系統(tǒng)應(yīng)該每周 7天、每天 24小時(shí)都可使用； – 對一個(gè)沒有經(jīng)驗(yàn)的用戶而言，經(jīng)過 2小時(shí)培訓(xùn)即可使用系統(tǒng)所有功能。 2023/1/30 25 ? NFR：檢驗(yàn)起來非常困難，一般采用一些可度量的特性進(jìn)行描述。 2023/1/30 28 6. 業(yè)務(wù)規(guī)則 ? 業(yè)務(wù)規(guī)則 (Business Rule)： 對某些功能的可執(zhí)行性或 內(nèi)部執(zhí)行邏輯 的一些限定條件。 ? 系統(tǒng)應(yīng)該在 5分鐘內(nèi)計(jì)算出給定季度的總銷售稅。 2023/1/30 31 需求規(guī)格說明 2023/1/30 32 需求規(guī)格說明是指軟件所應(yīng)滿足的全部要求，并用文檔方式完整和精確描述。我需要一些分析人員與一些知道系統(tǒng)使用要求的化學(xué)專家進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。 改正：如果用戶試圖透支，系統(tǒng)將顯示錯(cuò)誤信息并拒絕取款操作。 考慮以下需求是否滿足“好需求”的標(biāo)準(zhǔn)，如不是，該如何修正？ 1. 在用戶每次存錢時(shí)系統(tǒng)將進(jìn)行信用檢查； 2. 如果用戶試圖透支，系統(tǒng)將采取適當(dāng)?shù)男袆?dòng)； 3. 系統(tǒng)將盡可能快的響應(yīng)所有有效的請求； 4. 系統(tǒng)允許立即使用所存資金； 5. 只有在手工驗(yàn)證所存資金后，系統(tǒng)才能允許使用它； 2023/1/30 40 需求規(guī)格說明 軟件需求規(guī)格說明的一般格式 ： 1．引言 2．任務(wù)概述 3．?dāng)?shù)據(jù)描述 4．功能要求 5．性能需求 6．運(yùn)行需求 7．其他要求（如可使用性、安全保密、可維護(hù)性、可移植性等） 8．附錄 2023/1/30 41 需求規(guī)格說明 需求規(guī)格說明的特性如下： 1．完整性 2. 正確性 3. 可行性 4. 必要性 5. 無歧義性 6. 可驗(yàn)證性 7. 劃分優(yōu)先級 2023/1/30 42 需求工程 2023/1/30 43 需求工程概念 ? 需求工程就是應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需求。 3．根據(jù)需求信息建立軟件系統(tǒng)的邏輯模型和需求模型，確定非功能需求和約束條件及限制。 2023/1/30 46 需求工程過程分為需求開發(fā)和需求管理兩階段。 2023/1/30 48 審查和驗(yàn)證軟件系統(tǒng)需求規(guī)格說明，進(jìn)而確定需求規(guī)格說明是否正確描述了用戶對軟件系統(tǒng)的需求。 2023/1/30 61 “看似簡單，實(shí)際卻很難 …‖ —— ―需求獲取？不就是問問題嗎？這有什么難的？” 2023/1/30 65 需求獲取技術(shù) ? 需求獲取的關(guān)鍵： – 溝通和交流 ? 所要避免的問題： – 交流障礙、溝通不全、意見沖突 ? 所要必備的條件： – 較高的技術(shù)水平、豐富的實(shí)踐經(jīng)驗(yàn)、較強(qiáng)的人際交往能力 ? 可能采取的手段： – 用戶訪談、現(xiàn)場考察、專家咨詢、會(huì)議討論、 … 2023/1/30 66 需求獲取技術(shù) ? 面對面訪談 (facetoface interviewing) ? 專題討論會(huì) (workshop) ? 現(xiàn)場觀察 (observing on the scene) ? 頭腦風(fēng)暴 (brain storming) ? 多種方法要復(fù)合在一起使用，效果更好 2023/1/30 67 面對面訪談 2023/1/30 68 面對面訪談 ? 需求獲取中最直接的方法：用戶面談 (interviewing) ? ―看起來很美”，但“做起來并不容易” ——需求分析者個(gè)人的偏見、事先的理解、以往的經(jīng)驗(yàn)積累是導(dǎo)致面談失敗的最重要原因 ——在面談時(shí)，忘掉一切以往所作的事情，通過問題啟發(fā)，傾聽對方的陳述 ——不要把自己放在“專家”的位置上 2023/1/30 69 如何提問？ ? “每個(gè)人都能提問題，但并不等于人人都會(huì)提問題 …‖ ? 封閉式問題： – 對錯(cuò)判斷或多項(xiàng)選擇題，回答只需要一兩個(gè)詞 ? 開放式問題： – 這種問題需要解釋和說明，同時(shí)向?qū)Ψ奖硎灸銓λ麄冋f的話很感興趣，還想了解更多的內(nèi)容。 2023/1/30 74 面談?dòng)涗浀氖纠?(1) ? 第一部分：建立客戶或用戶情況表 ? 第二部分：評估問題 – 詢問用戶對哪些類型的問題缺乏好的解決方案 – 它們是什么？ (不斷的問“還有嗎？” ) ? 第三部分：理解用戶環(huán)境 – 誰是用戶？他們的經(jīng)歷和經(jīng)驗(yàn)如何？用戶的預(yù)期如何？ ? 第四部分：扼要說明理解情況 – 你剛才告訴我： (用自己的話復(fù)述客戶描述的問題 ) – 這是否足以表達(dá)你現(xiàn)在的解決方案中存在的問題？ – 如果有，你還有什么問題？ 2023/1/30 75 面談?dòng)涗浀氖纠?(2) ? 第五部分：分析人員對客戶問題的輸入 – 對每個(gè)問題進(jìn)行以下提問： ? 這是一個(gè)實(shí)際的問題嗎？ ? 問題產(chǎn)生的原因是什么？ ? 現(xiàn)在如何解決的？ ? 希望如何解決？ ? 該問題的重要度如何？ ? 第六部分：評估自己的解決方案 – 總結(jié)自己建議的解決方案； – 對自己方案的優(yōu)先級排序； ? 第七部分：評估機(jī)會(huì) ? 第八部分：評估可靠性、性能及其他需要 2023/1/30 76 面談?dòng)涗浀氖纠?(3) ? 第九部分：其他需求 – 法律法規(guī)、環(huán)境、行業(yè)標(biāo)準(zhǔn)等； ? 第十部分：總結(jié)性提問 – 還有其他問題要問面談人嗎？ – 尚未解決的問題有哪些？ – 下次訪談的方式、地點(diǎn)、時(shí)間、參加人等； ? 第十一部分：分析人員的總結(jié) – 總結(jié)出客戶 /用戶確認(rèn)的三條優(yōu)先級最高的需求或問題。 ? 系統(tǒng)相關(guān)者在短暫而緊湊的時(shí)間段內(nèi)集中在一起，一般為1至 2天，與會(huì)者可以在應(yīng)用需求上達(dá)成共識、對操作過程盡快取得統(tǒng)一意見。 2023/1/30 85 需求分析的任務(wù)與原則 2023/1/30 86 需求工程過程 需求工程過程分為需求開發(fā)和需求管理兩階段。 2. 創(chuàng)建用戶接口原型 當(dāng)開發(fā)人員或用戶不能確定軟件需求時(shí)，開發(fā)一個(gè)用戶接口原型 (可能的局部實(shí)現(xiàn) )，這樣使得許多概念和可能發(fā)生的事更為直觀明了。 2023/1/30 90 需求分析的任務(wù)與原則 6. 創(chuàng)建數(shù)據(jù)字典 數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。 就是將一種形式的數(shù)據(jù)轉(zhuǎn)換成另一種形式的數(shù)據(jù) 。 2023/1/30 93 需求分析的任務(wù)與原則 需求分析的原則 ? 這對系統(tǒng)滿足處理需求所提出的邏輯限制條件和系統(tǒng)中其他成分提出的物理限制條件是必不可少的 。 ? 基本思想是按照由抽象到具體 、 逐層分解的方法 ， 確定軟件系統(tǒng)內(nèi)部的數(shù)據(jù)流 、 變換關(guān)系 ， 并用數(shù)據(jù)流圖表示 。 – 由于數(shù)據(jù)流是流動(dòng)中的數(shù)據(jù)，所以必須有流向 – 應(yīng)用名詞或名詞短語命名 – 可能是紙張上的數(shù)據(jù)、電子數(shù)據(jù)、通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)等 – 可能存在于： ? 外部實(shí)體與加工之間； ? 加工與加工之間； ? 加工與數(shù)據(jù)存儲之間 2023/1/30 103 DFD的簡單練習(xí) 文件1 加法 (+ )2 乘法 (*)3 加法 (+ )顧客abadc4 乘法 (*)a + ba*dc + a *d( a + b ) * ( c + a *d )? 背景：用戶輸入 a、 b、 c、 d四個(gè)值，系統(tǒng)計(jì)算(a+b)*(c+a*d)，并將結(jié)果輸出到一個(gè)文件中存儲。 外部實(shí)體 1數(shù)據(jù)流外部實(shí)體 2數(shù)據(jù)流數(shù)據(jù)存儲 10 系統(tǒng)2023/1/30 115 父圖與子圖的平衡 ? 下層 DFD中的輸入輸出數(shù)據(jù)流同上層 DFD中相應(yīng)加工的輸入輸出數(shù)據(jù)流必須一致，此即父圖與子圖的平衡。 – 根據(jù)留底的訂單進(jìn)行銷售統(tǒng)計(jì)，打印統(tǒng)計(jì)表給經(jīng)理。 (2) 可以反映出數(shù)據(jù)的流向和處理過程。 2023/1/30 126 數(shù)據(jù)流圖 6． 數(shù)據(jù)流圖的畫法 (1) 畫數(shù)據(jù)流圖的一般原則 畫數(shù)據(jù)流圖的基本步驟概括地說，就是自外向內(nèi)，自頂向下，逐層細(xì)化，完善求精。 2023/1/30 131 數(shù)據(jù)字典 (DD) ? DFD只是繪制了系統(tǒng)各功能之間的數(shù)據(jù)流動(dòng)和處理關(guān)系，還需進(jìn)一步考慮各數(shù)據(jù)的具體內(nèi)容。 – 分機(jī)號從 8201至 8299。 2023/1/30 139 示例：數(shù)據(jù)字典 (1) ? “電話號碼”的數(shù)據(jù)字典： – 電話號碼 =[分機(jī)號 |外線號碼 ] – 分機(jī)號 =8201..8299 – 外線號碼 =0+[市話號碼 |長途電話號碼 ] – 市話號碼 ={數(shù)字 } – 長途電話號碼 =區(qū)號 +市話號碼 – 區(qū)號 =[010|021..029|0300..0999] 2023/1/30 140 示例：數(shù)據(jù)字典 (2) 名字： 零件編號 別名： 編碼 描述： 唯一的標(biāo)識庫存清單中一個(gè)特定零件 定義： 零件編號 ={字符 }8 位置： 庫存清單 采購訂單 訂貨報(bào)表 名字： 采購訂單 別名： 采購單 描述： 由各部門采購人員定期向供應(yīng)商發(fā)出的單據(jù) 定義： 采購訂單 =供應(yīng)商 ID+供應(yīng)商名稱 +采購日期 +總金額 + {零件編號 +零件名稱 +數(shù)量 +價(jià)格 } 位置： 訂貨報(bào)表 2023/1/30 141 層次方框圖 Warnier圖 IPO圖 2023/1/30 142 層次方框圖 ? 層次方框圖用樹形結(jié)構(gòu)的一系列多層次的矩形框描述數(shù)據(jù)的層次結(jié)構(gòu) 。 2023/1/30 144 IPO圖 ? IPO圖是輸入 /處理 /輸出圖的簡稱 ,它是美國IBM公司提出的一種圖形工具 ,能夠方便地描繪輸入數(shù)據(jù) 、 處理數(shù)據(jù)和輸出數(shù)據(jù)的關(guān)系 。 2023/1/30 147 需求分析評審的主要內(nèi)容 : :所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。 2023/1/30 148 需求驗(yàn)證的方法 : 1. 驗(yàn)證需求的一致性 自然語言書寫靠人工技術(shù)審查驗(yàn)證軟件系統(tǒng)規(guī)格說明書的正確性 當(dāng)軟件需求規(guī)格說明書是用形式化的需求陳述語言書寫的時(shí)候，可以用軟件工具驗(yàn)證需求的一致性。 ? 需求管理的目標(biāo)如下： 1. 控制軟件需求，并建立軟件工程和管理使用的需求基線； 2. 使軟件計(jì)劃、產(chǎn)品和活動(dòng)與軟件需求保持一致。 正向跟蹤與逆向跟蹤 建立需求狀態(tài)是為了表示需求的各種不同情況 。 演講完畢，謝謝觀看！