【正文】 0000條記錄中檢索出一個(gè)銷售訂單。 ? 系統(tǒng)必須支持 100個(gè) Windows工作站的并行訪問。 ? 系統(tǒng)可從各型號(hào)的 modem上讀取信號(hào)作為系統(tǒng)輸入。 2023/1/30 31 需求規(guī)格說明 2023/1/30 32 需求規(guī)格說明是指軟件所應(yīng)滿足的全部要求，并用文檔方式完整和精確描述。全部要求是指軟件系統(tǒng)必須提供的功能和性能、約束條件和限制。 2023/1/30 33 軟件需求的分類 好的需求 vs 壞的需求 2023/1/30 34 好的需求應(yīng)具備的特征 ? 完整性： 每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚 ? 正確性： 每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開發(fā)的功能； ? 可行性： 每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的 ? 必要性： 每一項(xiàng)需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來 ? 劃分優(yōu)先級(jí)： 給每項(xiàng)需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級(jí)以指明它在特定產(chǎn)品中所占的分量 ? 無二義性： 對(duì)所有需求說明的讀者都只能有一個(gè)明確統(tǒng)一的解釋 ? 可驗(yàn)證性： 檢查一下每項(xiàng)需求是否能通過設(shè)計(jì)測(cè)試用例或其它驗(yàn)證方法，如用演示、檢測(cè)等來確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn) 2023/1/30 35 產(chǎn)生不合格需求的原因 ? 無足夠用戶參與 ——―我不明白為什么要花那么多功夫收集需求” ——―與其與用戶討論浪費(fèi)時(shí)間，不如寫代碼有意思” ——―我已經(jīng)明白用戶需求了” ? 用戶需求的不斷增加 ——若不斷增加新需求，項(xiàng)目就越來越龐大以致超過其計(jì)劃及預(yù)算范圍 ——開發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù) 2023/1/30 36 產(chǎn)生不合格需求的原因 ? 模棱兩可的需求 ——諸多讀者對(duì)需求說明產(chǎn)生了不同的理解 ——單個(gè)讀者能用不止一個(gè)方式來解釋某個(gè)需求說明 ——后果：返工，重做一些你認(rèn)為已做好的事情 ? 不必要的特性 ——―畫蛇添足”，開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能 ——客戶可能要求一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本 2023/1/30 37 產(chǎn)生不合格需求的原因 ? 過于精簡(jiǎn)的規(guī)格說明 ——給開發(fā)人員帶來挫折，使他們?cè)诓徽_的假設(shè)前提和極其有限的指導(dǎo)下工作 ——給客戶帶來煩惱，他們無法得到他們所設(shè)想的產(chǎn)品 ? 忽略了用戶分類 ——軟件由不同的人使用其不同的特性 ——使用頻繁程度有所差異 ——使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同 ? 不準(zhǔn)確的計(jì)劃 ——對(duì)需求分析缺乏理解會(huì)導(dǎo)致過分樂觀的估計(jì) ——原因：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析 2023/1/30 38 [案例分析 2]―他們忙，沒有時(shí)間與你討論需求 …‖ ? Contoso公司的 CEO Gerhard約見軟件開發(fā)小組Cynthia，商討為公司開發(fā)新系統(tǒng)的事情 … Gerhard 我們需要建立一套化學(xué)制品跟蹤信息系統(tǒng)，可以記錄并查詢庫房或某個(gè)實(shí)驗(yàn)室中已有的化學(xué)藥品 … 你們小組能在五個(gè)月內(nèi)開發(fā)出該系統(tǒng)嗎？ Cynthia 我已經(jīng)明白這個(gè)項(xiàng)目的重要性了，但在我制定計(jì)劃前，我們必須收集一些系統(tǒng)的需求。 Gerhard 你什么意思？我不是剛告訴你我的需求了嗎？ Cynthia 你只說明了整個(gè)項(xiàng)目的概念與目標(biāo)，這些高層次的業(yè)務(wù)需求并不能為我們提供足夠的詳細(xì)信息以確定究竟要開發(fā)什么樣的軟件，以及需要多長(zhǎng)時(shí)間。我需要一些分析人員與一些知道系統(tǒng)使用要求的化學(xué)專家進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。 Gerhard 那些化學(xué)專家都非常忙，沒有時(shí)間與你們?cè)敿?xì)討論各種細(xì)節(jié)，你不能讓你的手下的人說明要做的系統(tǒng)嗎？ Cynthia 如果我們只是憑空猜想用戶要求，結(jié)果不會(huì)令人滿意。 Gerhard 行了，行了，我們沒有那么多時(shí)間，我來告訴你需求，請(qǐng)馬上開始開發(fā)系統(tǒng)，并隨時(shí)將你們的進(jìn)展情況告訴我。 …… 2023/1/30 39 好需求與壞需求 1. 在現(xiàn)實(shí)情況中，用戶存錢時(shí)并不需要信用檢查，因此這個(gè)需求描述是錯(cuò)誤的 2. ―適當(dāng)?shù)男袆?dòng)”對(duì)不同的人來說有不同的解釋，顯然是歧義的。 改正：如果用戶試圖透支，系統(tǒng)將顯示錯(cuò)誤信息并拒絕取款操作。 3. ―盡快”是不可驗(yàn)證的，應(yīng)該給出具體數(shù)量值。 改正：系統(tǒng)將在 20秒內(nèi)響應(yīng)所有有效的請(qǐng)求。 4. 與 5是矛盾的。 考慮以下需求是否滿足“好需求”的標(biāo)準(zhǔn)，如不是，該如何修正？ 1. 在用戶每次存錢時(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ī)格說明 軟件需求規(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)先級(jí) 2023/1/30 42 需求工程 2023/1/30 43 需求工程概念 ? 需求工程就是應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需求。 ? 需求工程的目標(biāo)是獲取高質(zhì)量的軟件需求。 ? 需求工程突出了工程化原則，強(qiáng)調(diào)以系統(tǒng)化、條理化和重復(fù)化的方法進(jìn)行軟件需求的相關(guān)活動(dòng)，從而增強(qiáng)了管理性和降低了需求開發(fā)的成本 2023/1/30 44 需求工程概念 需求工程的任務(wù)： 1．確定待開發(fā)的軟件系統(tǒng)的用戶，并獲取用戶的需求信息。 2．分析用戶的需求信息，并按需求類型分類，過濾掉非需求的信息。 3．根據(jù)需求信息建立軟件系統(tǒng)的邏輯模型和需求模型，確定非功能需求和約束條件及限制。 2023/1/30 45 需求工程概念 需求工程的任務(wù)： 4．根據(jù)收集的需求信息和邏輯模型編寫需求規(guī)格說明及文檔。 5．評(píng)審需求規(guī)格說明。 6．當(dāng)需求變更時(shí)，對(duì)需求規(guī)格說明及需求變更實(shí)施進(jìn)行管理。 2023/1/30 46 需求工程過程分為需求開發(fā)和需求管理兩階段。 需 求 獲 取 需 求 分 析 需 求 描 述 需 求 驗(yàn) 證 需 求 管 理需 求 開 發(fā) 過 程 需 求 管 理 過 程2023/1/30 47 確定和 收集 與待開發(fā)的軟件系統(tǒng)相關(guān)的用戶需求信息。 對(duì)獲得的用戶需求信息進(jìn)行分析和綜合，找出錯(cuò)誤和沖突及遺漏的地方，獲得用戶的準(zhǔn)確的需求，進(jìn)而建立軟件系統(tǒng)的邏輯模型或需求模型。 利用描述語言、標(biāo)準(zhǔn)格式書寫軟件系統(tǒng)的需求規(guī)格說明和文檔。 2023/1/30 48 審查和驗(yàn)證軟件系統(tǒng)需求規(guī)格說明，進(jìn)而確定需求規(guī)格說明是否正確描述了用戶對(duì)軟件系統(tǒng)的需求。 需求管理的任務(wù)是管理軟件系統(tǒng)的需求規(guī)格說明和文檔，評(píng)估需求變更帶來的影響及成本費(fèi)用，跟蹤軟件需求的狀態(tài)，管理需求規(guī)格說明的版本等。 2023/1/30 49 需求狀態(tài)跟蹤 需求工程的總體流程 需求獲取 需求分析 需求規(guī)格說明 (SRS) 需求驗(yàn)證 客戶 (client) 終端用戶 (user) 市場(chǎng)人員 維護(hù)人員 基線 (baseline) 需求管理 需求變更過程 需求變更 項(xiàng)目變更 需求開發(fā) 需求管理 2023/1/30 50 需求開發(fā)所包含的活動(dòng) ? 確定 產(chǎn)品所期望的 用戶類 ? 獲取每個(gè)用戶類的需求 ? 了解實(shí)際用戶 任務(wù)和目標(biāo) 以及這些任務(wù)所支持的 業(yè)務(wù)需求 ? 分析源于用戶的信息以區(qū)別 用戶需求、功能需求、非功能需求、約束條件 、建議解決方法和附加信息 ? 將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件構(gòu)件 ? 了解相關(guān)非功能屬性的重要性 ? 商討實(shí)施 優(yōu)先級(jí) 的劃分 ? 將所收集的用戶需求 編寫成規(guī)格說明和模型 ? 評(píng)審需求規(guī)格說明 ，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚 2023/1/30 51 (1) 需求獲取 ? 需求獲取 (Requirement Elicitation)： 通過與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及對(duì)任務(wù)進(jìn)行分析，從而開發(fā)、捕獲和修訂用戶的需求 – 對(duì)用戶進(jìn)行分類 – 聆聽每一類用戶的需求 – 分析和整理所獲取的需求 – 形成文檔化的描述 – 簽字確認(rèn) 2023/1/30 52 (2) 需求分析 ? 需求分析 (Requirement Analysis)：對(duì)收集到的需求進(jìn)行提煉、分析和審查，為最終用戶所看到的系統(tǒng)建立概念化的分析模型 – 定義系統(tǒng)的邊界 – 建立軟件原型 – 分析需求可行性 – 確定需求優(yōu)先級(jí) – 建立需求分析模型 – 創(chuàng)建數(shù)據(jù)字典 2023/1/30 53 (3) 形成需求規(guī)格說明 ? 需求規(guī)格說明 (Software Requirement Specification, SRS)： – 需求開發(fā)的結(jié)果 – 精確的、形式化的闡述一個(gè)軟件系統(tǒng)必須提供的功能、非功能、所要考慮的限制條件等 – 作為用戶和開發(fā)者之間的一個(gè)契約 – 是用戶、分析人員和設(shè)計(jì)人員之間進(jìn)行理解和交流的手段 2023/1/30 54 (4) 需求驗(yàn)證 ? 需求驗(yàn)證 (Requirement Verification)：以需求規(guī)格說明為輸入，通過評(píng)審、模擬或快速原型等途徑，分析需求規(guī)格的正確性和可行性，發(fā)現(xiàn)存在的錯(cuò)誤或缺陷并及時(shí)更改和補(bǔ)充。 2023/1/30 55 (5) 需求管理 ? 需求管理 (Requirement Management) – 定義需求基線 (迅速制定需求文檔的主體 ) – 評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它 – 以一種可控制的方式將需求變更融入到項(xiàng)目中 – 使當(dāng)前的項(xiàng)目計(jì)劃與需求一致 – 估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾 (約定 ) – 讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤 – 在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況 2023/1/30 56 需求管理 需求管理 變更控制 版本控制 需求跟蹤 需求狀態(tài)跟蹤 ? 建議變更 ? 分析影響 ? 做出決策 ? 交流 ? 合并 ? 測(cè)量需求穩(wěn)定性 ? 確定需求文檔 版本 ? 定義對(duì)其他需求 的連接鏈 ? 定義對(duì)其他系統(tǒng) 元素的連接鏈 ? 定義需求狀態(tài) ? 跟蹤需求狀態(tài) 2023/1/30 57 需求管理與需求開發(fā)的關(guān)系 2023/1/30 58 需求獲取方法 2023/1/30 59 需求獲取的基本步驟 了解 領(lǐng)域背景知識(shí) 客戶分類 (按角色 ) CxO 部門經(jīng)理 業(yè)務(wù)員 管理員 交流 需求紀(jì)要 問題？ 分類整理 功能需求 非功能需求 約束條件 業(yè)務(wù)規(guī)則 外部接口需求 建議解決方案 優(yōu)先級(jí)排序 沖突消解 簽字確認(rèn) 業(yè)務(wù)需求 用戶需求 2023/1/30 60 需求獲取的基本步驟 ? 第 1步： 了解相關(guān)背景和領(lǐng)域 /行業(yè)的知識(shí)， 確定產(chǎn)品所期望的用戶類； ? 第 2步：與客戶企業(yè)或組織的高層人員進(jìn)行 交流 ，了解實(shí)際用戶任務(wù)和目標(biāo) 以及這些任務(wù)所支持的 業(yè)務(wù)需求 ； ? 第 3步：與客戶企業(yè)或組織的底層人員進(jìn)行 交流 ，獲取 每個(gè)用戶類的 詳細(xì)的用戶需求； ? 第 4步： 整理需求紀(jì)要 ， 發(fā)現(xiàn)新問題