【正文】 確定產(chǎn)品所期望的用戶(hù)類(lèi)； ? 第 2步：與客戶(hù)企業(yè)或組織的高層人員進(jìn)行 交流 ，了解實(shí)際用戶(hù)任務(wù)和目標(biāo) 以及這些任務(wù)所支持的 業(yè)務(wù)需求 ； ? 第 3步：與客戶(hù)企業(yè)或組織的底層人員進(jìn)行 交流 ，獲取 每個(gè)用戶(hù)類(lèi)的 詳細(xì)的用戶(hù)需求； ? 第 4步： 整理需求紀(jì)要 ， 發(fā)現(xiàn)新問(wèn)題 ，并重復(fù) 13步； ? 第 5步： 需求分類(lèi)和組織， 以區(qū)別 功能需求、非功能需求、約束條件、業(yè)務(wù)規(guī)則、外部接口需求 、建議解決方法和附加信息； ? 第 6步： 優(yōu)先排序和沖突解決； ? 第 7步：得到最終需求清單，并與客戶(hù)做 最終簽字確認(rèn)。 4. 與 5是矛盾的。 ? 系統(tǒng)必須有能力存儲(chǔ)平均操作連續(xù) 100天所產(chǎn)生的事務(wù)。 – 課程信息維護(hù)、選課管理、課程成績(jī)登記和查詢(xún)等業(yè)務(wù)全部由手工方式改為計(jì)算機(jī)應(yīng)用。 ? 軟件需求是要把一個(gè)定義不足和模糊的問(wèn)題轉(zhuǎn)換為一個(gè)定義良好而準(zhǔn)確的問(wèn)題，進(jìn)而找到解決問(wèn)題的方案。 – 學(xué)生希望在選課期間系統(tǒng)能夠 24小時(shí)使用，系統(tǒng)使用方便快捷。 ? 系統(tǒng)必須支持 100個(gè) Windows工作站的并行訪問(wèn)。 ? 需求工程突出了工程化原則，強(qiáng)調(diào)以系統(tǒng)化、條理化和重復(fù)化的方法進(jìn)行軟件需求的相關(guān)活動(dòng)，從而增強(qiáng)了管理性和降低了需求開(kāi)發(fā)的成本 2023/1/30 44 需求工程概念 需求工程的任務(wù)： 1．確定待開(kāi)發(fā)的軟件系統(tǒng)的用戶(hù)，并獲取用戶(hù)的需求信息。將答案記錄到紙面上，并指出和記錄下未回答條目和未解決問(wèn)題； ? Step 4：面談之后，分析總結(jié)面談?dòng)涗洝? 4. 確定需求的優(yōu)先級(jí) 應(yīng)用分析方法來(lái)確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級(jí)。 – 收集、排序、選擇、聚集、分析等 – 加工要有名字，通常是動(dòng)詞短語(yǔ)，簡(jiǎn)明地描述完成什么事情 – 在分層的數(shù)據(jù)流圖中，加工還應(yīng)編號(hào) – 三種類(lèi)型：計(jì)算機(jī)自動(dòng)加工、手工加工、人機(jī)協(xié)作的加工 1 錄入訂單 2 審核訂單 2023/1/30 100 DFD的主要元素 (2)：數(shù)據(jù)存儲(chǔ) ? 數(shù)據(jù)存儲(chǔ) (data storage，也稱(chēng)文件 )：需要在外存儲(chǔ)器上保存的數(shù)據(jù)，它可以是數(shù)據(jù)庫(kù)文件或任何形式的數(shù)據(jù)組織。 (4) 容易與計(jì)算機(jī)處理相對(duì)照。 ? 系統(tǒng)分析員從對(duì)頂層信息的分類(lèi)開(kāi)始 ， 沿圖中每條路徑反復(fù)細(xì)化 ， 直到確定了數(shù)據(jù)結(jié)構(gòu)的全部細(xì)節(jié)為止 。 2023/1/30 155 需求開(kāi)發(fā)的管理 (1)需求來(lái)源 (2)需求形式化 (3)需求跟蹤矩陣 (1)編寫(xiě)測(cè)試計(jì)劃與測(cè)試用例； (2)編寫(xiě)系統(tǒng)驗(yàn)收標(biāo)準(zhǔn)； (3)通過(guò)需求評(píng)審； (4)需求評(píng)審的誤區(qū)。 3. 驗(yàn)證需求的完整性和有效性 快速原型法 原型系統(tǒng)所顯示的是系統(tǒng)的主要功能而不是性能，因此可以適當(dāng)降低對(duì)接口、可靠性等的要求，還可以節(jié)省文檔等方面的工作，從而可大大降低原型系統(tǒng)的開(kāi)發(fā)成本 2023/1/30 150 需求評(píng)審 需求評(píng)審就是技術(shù)評(píng)審，是由非軟件開(kāi)發(fā)人員對(duì)軟件系統(tǒng)進(jìn)行檢查，進(jìn)而發(fā)現(xiàn)系統(tǒng)存在的問(wèn)題。 – 長(zhǎng)途電話(huà)號(hào)碼由區(qū)號(hào)和市話(huà)號(hào)碼組成，其中區(qū)號(hào)可以為 0021~02 0300~0999中的任意一個(gè)數(shù)字串。 2．?dāng)?shù)據(jù)流圖的特性 （ 1）抽象性 （ 2）概括性（ 3）層次性 3. 數(shù)據(jù)流圖基本符號(hào) （ 1）源點(diǎn)（ 2）加工（ 3）數(shù)據(jù)流 （ 4）數(shù)據(jù)存儲(chǔ)文件 4．?dāng)?shù)據(jù)流圖的用途 作為交流信息的工具。 ? 軟件需求的物理視圖給出處理功能和數(shù)據(jù)結(jié)構(gòu)的實(shí)際表示形式 。 ? 具體地說(shuō)，需求分析是提煉、分析和審查已收集到的需求信息，找出真正的和具體的需求，并確保所有相關(guān)人員都理解其含義。 2023/1/30 49 需求狀態(tài)跟蹤 需求工程的總體流程 需求獲取 需求分析 需求規(guī)格說(shuō)明 (SRS) 需求驗(yàn)證 客戶(hù) (client) 終端用戶(hù) (user) 市場(chǎng)人員 維護(hù)人員 基線(xiàn) (baseline) 需求管理 需求變更過(guò)程 需求變更 項(xiàng)目變更 需求開(kāi)發(fā) 需求管理 2023/1/30 50 需求開(kāi)發(fā)所包含的活動(dòng) ? 確定 產(chǎn)品所期望的 用戶(hù)類(lèi) ? 獲取每個(gè)用戶(hù)類(lèi)的需求 ? 了解實(shí)際用戶(hù) 任務(wù)和目標(biāo) 以及這些任務(wù)所支持的 業(yè)務(wù)需求 ? 分析源于用戶(hù)的信息以區(qū)別 用戶(hù)需求、功能需求、非功能需求、約束條件 、建議解決方法和附加信息 ? 將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件構(gòu)件 ? 了解相關(guān)非功能屬性的重要性 ? 商討實(shí)施 優(yōu)先級(jí) 的劃分 ? 將所收集的用戶(hù)需求 編寫(xiě)成規(guī)格說(shuō)明和模型 ? 評(píng)審需求規(guī)格說(shuō)明 ，確保對(duì)用戶(hù)需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開(kāi)發(fā)小組接受說(shuō)明之前將問(wèn)題都弄清楚 2023/1/30 51 (1) 需求獲取 ? 需求獲取 (Requirement Elicitation)： 通過(guò)與用戶(hù)的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及對(duì)任務(wù)進(jìn)行分析，從而開(kāi)發(fā)、捕獲和修訂用戶(hù)的需求 – 對(duì)用戶(hù)進(jìn)行分類(lèi) – 聆聽(tīng)每一類(lèi)用戶(hù)的需求 – 分析和整理所獲取的需求 – 形成文檔化的描述 – 簽字確認(rèn) 2023/1/30 52 (2) 需求分析 ? 需求分析 (Requirement Analysis)：對(duì)收集到的需求進(jìn)行提煉、分析和審查，為最終用戶(hù)所看到的系統(tǒng)建立概念化的分析模型 – 定義系統(tǒng)的邊界 – 建立軟件原型 – 分析需求可行性 – 確定需求優(yōu)先級(jí) – 建立需求分析模型 – 創(chuàng)建數(shù)據(jù)字典 2023/1/30 53 (3) 形成需求規(guī)格說(shuō)明 ? 需求規(guī)格說(shuō)明 (Software Requirement Specification, SRS)： – 需求開(kāi)發(fā)的結(jié)果 – 精確的、形式化的闡述一個(gè)軟件系統(tǒng)必須提供的功能、非功能、所要考慮的限制條件等 – 作為用戶(hù)和開(kāi)發(fā)者之間的一個(gè)契約 – 是用戶(hù)、分析人員和設(shè)計(jì)人員之間進(jìn)行理解和交流的手段 2023/1/30 54 (4) 需求驗(yàn)證 ? 需求驗(yàn)證 (Requirement Verification)：以需求規(guī)格說(shuō)明為輸入，通過(guò)評(píng)審、模擬或快速原型等途徑，分析需求規(guī)格的正確性和可行性，發(fā)現(xiàn)存在的錯(cuò)誤或缺陷并及時(shí)更改和補(bǔ)充。 改正：系統(tǒng)將在 20秒內(nèi)響應(yīng)所有有效的請(qǐng)求。 ? 必須在對(duì)話(huà)窗口的中間顯示錯(cuò)誤警告，使用紅色的、 14點(diǎn)加粗 Arial字體。 ? [例 ]用戶(hù)可以通過(guò) Inter隨時(shí)查詢(xún)圖書(shū)信息和個(gè)人借閱情況，并可以快速查找和瀏覽需要的電子資料； – [功能需求 ]用戶(hù)通過(guò) Inter查詢(xún)圖書(shū)信息； – [功能需求 ]用戶(hù)通過(guò) Inter瀏覽個(gè)人借閱情況； – [功能需求 ]用戶(hù)通過(guò) Inter查找和瀏覽電子資料； – [非功能需求 ]隨時(shí)、快速 2023/1/30 21 業(yè)務(wù)需求與用戶(hù)需求的對(duì)比 ? 針對(duì) Course Registration System ? 業(yè)務(wù)需求 – 由于實(shí)行學(xué)分制管理，學(xué)校領(lǐng)導(dǎo)希望用計(jì)算機(jī)管理學(xué)生選課。 2023/1/30 6 主要困難 ： 1. 軟件開(kāi)發(fā)人員與用戶(hù)雙方固有的矛盾 2. 需求具有易變性和難以表述性 3. 需求錯(cuò)誤的高頻性和修復(fù)的高成本性 2023/1/30 7 軟件開(kāi)發(fā)的目標(biāo)是什么？ ? 開(kāi)發(fā)高質(zhì)量的軟件； ? 在預(yù)定的時(shí)間和預(yù)算約束下完成； ? 軟件要能夠滿(mǎn)足顧客的需求。 2023/1/30 22 3. 功能需求 ? 功能需求 (Functional Requirements, FR)： 系統(tǒng)應(yīng)該提供的 功能或服務(wù) ，通常涉及用戶(hù)或外部系統(tǒng)與該系統(tǒng)之間的交互，不考慮系統(tǒng)內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)； ? [例 ] – 用戶(hù)可從圖書(shū)資料庫(kù)中查詢(xún)或者選擇其中一個(gè)子集； – 系統(tǒng)可提供適當(dāng)?shù)臑g覽器供用戶(hù)閱讀館藏文獻(xiàn)； – 用戶(hù)每次借閱圖書(shū)應(yīng)對(duì)應(yīng)一個(gè)唯一的標(biāo)識(shí)號(hào)，它被記錄到用戶(hù)的賬戶(hù)上； 2023/1/30 23 4. 非功能需求 ? 非功能需求 (NonFunctional Requirements, NFR)： 從各個(gè)角度對(duì)系統(tǒng)的約束和限制，反映了客戶(hù)對(duì)軟件系統(tǒng) 質(zhì)量和性能(quality and performance)的額外要求，如響應(yīng)時(shí)間、數(shù)據(jù)精度、可靠性等。 ? 系統(tǒng)可從各型號(hào)的 modem上讀取信號(hào)作為系統(tǒng)輸入。 2．分析用戶(hù)的需求信息，并按需求類(lèi)型分類(lèi)，過(guò)濾掉非需求的信息。 2023/1/30 73 面談之后 ? 復(fù)查筆記的準(zhǔn)確性、完整性和可理解性 ? 把所收集的信息轉(zhuǎn)化為適當(dāng)?shù)哪Ｐ秃臀臋n ? 確定需要進(jìn)一步澄清的問(wèn)題域 ? 向參加會(huì)議的每一個(gè)人發(fā)出此次面談的 minutes(會(huì)議紀(jì)要 )。 5. 為需求建立模型 需求的圖形分析模型是軟件需求規(guī)格說(shuō)明的補(bǔ)充說(shuō)明。 – 以名詞命名 銷(xiāo)售訂單 銷(xiāo)售訂單 銷(xiāo)售訂單 顧客庫(kù)存信息庫(kù)顧客信用庫(kù)發(fā)票付款當(dāng)前庫(kù)存1 銷(xiāo)售產(chǎn)品更新后的庫(kù)存顧客信息當(dāng)前信用度2023/1/30 101 DFD的主要元素 (3)：外部實(shí)體 ? 外部實(shí)體 (external entity)：本系統(tǒng)外部環(huán)境中的實(shí)體 (包括人員、組織或其他軟件系統(tǒng) ) – 也稱(chēng)為“數(shù)據(jù)源點(diǎn) /數(shù)據(jù)終點(diǎn)”，表示產(chǎn)生數(shù)據(jù)的源頭或消費(fèi)數(shù)據(jù)的終點(diǎn) – 以名詞短語(yǔ)命名 – 不能直接訪問(wèn)數(shù)據(jù)存儲(chǔ) 客戶(hù) 學(xué)生 庫(kù)存系統(tǒng) 旅行社 2023/1/30 102 DFD的主要元素 (4)：數(shù)據(jù)流 銷(xiāo)售訂單 客戶(hù)1錄入訂單銷(xiāo)售訂單2審核訂單訂單 訂單訂單? 數(shù)據(jù)流 (data flow)：數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑 – 由一組成分固定的數(shù)據(jù)組成。 (5) 不直觀 (6）人工繪制太麻煩，工作量較大。 2023/1/30 143 Warnier圖 用 Warnier圖可以表明信息的邏輯組織 ， 它不僅可以指出一類(lèi)信息或一個(gè)信息量是重復(fù)出現(xiàn)的 ， 也可以表示特定信息在某一類(lèi)信息中是有條件出現(xiàn)的 。 2023/1/30 156 需求管理活動(dòng) 變更管理過(guò)程分為變更描述 、 變更分析和變更實(shí)現(xiàn)三個(gè)階段 需求文檔的版本控制可以保證得到的是最新的需求文檔版本和記錄需求的歷吏版本 。 2023/1/30 149 需求驗(yàn)證的方法 : 2. 驗(yàn)證需求的現(xiàn)實(shí)性 為了驗(yàn)證需求的現(xiàn)實(shí)性，分析員應(yīng)該參照以往開(kāi)發(fā)類(lèi)似系統(tǒng)的經(jīng)驗(yàn)，分析用現(xiàn)有的軟、硬件技術(shù)實(shí)現(xiàn)目標(biāo)系統(tǒng)的可能性。 – 外線(xiàn)號(hào)碼需先撥 0，然后加撥市話(huà)號(hào)碼或長(zhǎng)途電話(huà)號(hào)碼。 ? 繪制上述系統(tǒng)的頂層、 0層、 1層 DFD圖 2023/1/30 118 銷(xiāo)售系統(tǒng)頂層 DFD 顧客訂單經(jīng)理采購(gòu)部門(mén)倉(cāng)庫(kù)缺貨通知單到貨通知單0 銷(xiāo)售管理系統(tǒng)備貨單銷(xiāo)售統(tǒng)計(jì)表2023/1/30 119 銷(xiāo)售系統(tǒng) 0層 DFD 可供貨訂單顧客1 處理訂單訂單2 處理供貨5統(tǒng)計(jì)銷(xiāo)售數(shù)據(jù)3統(tǒng)計(jì)缺貨缺貨記錄可供貨訂單倉(cāng)庫(kù)備貨單庫(kù)存記錄 訂單記錄采購(gòu)部門(mén)缺貨通知單 到貨通知單經(jīng)理統(tǒng)計(jì)表4處理到貨單2023/1/30 120 銷(xiāo)售系統(tǒng) 1層 DFD 合格訂單1 .1 檢查訂單訂單缺貨記錄庫(kù)存記錄1 .2 檢查庫(kù)存1 .3 確定可供貨性庫(kù)存單訂貨單可供貨訂單2 .1 根據(jù)訂單修改庫(kù)存可供貨訂單 備貨單庫(kù)存記錄 訂單記錄2 .2 開(kāi)備貨單已登記訂單2023/1/30 121 銷(xiāo)售系統(tǒng) 1層 DFD 缺貨記錄3 .1匯總?cè)必浛偭? .2打印缺貨通知單缺貨量 缺貨通知單缺貨記錄庫(kù)存記錄到貨通知單 4 .1根據(jù)到貨單修改庫(kù)存4 .2處理缺貨訂單4 .3修改缺貨記錄訂單到貨單可供貨訂單2023/1/30 122 銷(xiāo)售系統(tǒng) 1層 DFD 訂單記錄統(tǒng)計(jì)表5 .2按區(qū)域統(tǒng)計(jì)5 .3按顧客統(tǒng)計(jì)