【正文】 求通常用于表達(dá) “做什么” ，而不描述“ 如何做 ”。 2023/1/30 17 軟件需求的分類 軟件需求的分類 2023/1/30 18 不同層次的軟件需求 業(yè)務(wù)需求項(xiàng)目視圖與范圍文檔業(yè)務(wù)規(guī)則用例文檔功能需求軟件需求規(guī)格說(shuō)明外部接口需求用戶需求功能性需求 非功能性需求約束條件非功能需求2023/1/30 19 1. 業(yè)務(wù)需求 ? 業(yè)務(wù)需求 (Business Requirements)： 客戶對(duì)于系統(tǒng)的 高層次目標(biāo)要求 (highlevel objectives) ，定義了項(xiàng)目的 遠(yuǎn)景和范疇 (vision and scope) – 業(yè)務(wù)：屬于哪類業(yè)務(wù)范疇？應(yīng)完成什么功能？為何目的？ – 客戶：軟件為誰(shuí)服務(wù)？目標(biāo)客戶是誰(shuí)？ – 特性：區(qū)別于其他競(jìng)爭(zhēng)產(chǎn)品的特性是什么？ – 價(jià)值：價(jià)值體現(xiàn)在那些方面？ – 優(yōu)先級(jí)：功能特性的優(yōu)先級(jí)次序是什么？ ? [例 ]―圖書(shū)資料管理系統(tǒng)”的業(yè)務(wù)需求 – 該系統(tǒng)使用計(jì)算機(jī)實(shí)現(xiàn)圖書(shū)資料日常管理，提高工作效率和服務(wù)質(zhì)量； – 該系統(tǒng)可讓用戶在網(wǎng)絡(luò)上查詢與瀏覽電子資料，改變?cè)械慕栝喣Ｊ剑? – 由于版權(quán)的限制，某些電子資料只能瀏覽 /打印，但不能下載。 ? [例 ]用戶可以通過(guò) Inter隨時(shí)查詢圖書(shū)信息和個(gè)人借閱情況，并可以快速查找和瀏覽需要的電子資料； – [功能需求 ]用戶通過(guò) Inter查詢圖書(shū)信息； – [功能需求 ]用戶通過(guò) Inter瀏覽個(gè)人借閱情況； – [功能需求 ]用戶通過(guò) Inter查找和瀏覽電子資料； – [非功能需求 ]隨時(shí)、快速 2023/1/30 21 業(yè)務(wù)需求與用戶需求的對(duì)比 ? 針對(duì) Course Registration System ? 業(yè)務(wù)需求 – 由于實(shí)行學(xué)分制管理，學(xué)校領(lǐng)導(dǎo)希望用計(jì)算機(jī)管理學(xué)生選課。 ? 用戶需求 – 教務(wù)管理員希望能夠增加、修改和刪除學(xué)校的課程目錄，并且設(shè)置各學(xué)期課程的開(kāi)設(shè)信息。 – 學(xué)生希望在選課期間系統(tǒng)能夠 24小時(shí)使用，系統(tǒng)使用方便快捷。 ? [例 ] – 系統(tǒng)在 20秒內(nèi)響應(yīng)所有的請(qǐng)求； – 系統(tǒng)應(yīng)該每周 7天、每天 24小時(shí)都可使用； – 對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶而言，經(jīng)過(guò) 2小時(shí)培訓(xùn)即可使用系統(tǒng)所有功能。 ? 例如： – 即使對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶，系統(tǒng)也應(yīng)該很容易使用，且是用戶錯(cuò)誤降到最少； ? 修改為： – 對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶來(lái)說(shuō)，經(jīng)過(guò) 2個(gè)小時(shí)的培訓(xùn)就應(yīng)該使用系統(tǒng)的全部功能。 2023/1/30 25 ? NFR：檢驗(yàn)起來(lái)非常困難，一般采用一些可度量的特性進(jìn)行描述。 2023/1/30 27 5. 約束條件 ? 約束條件 (Constraints)： 系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)時(shí)必須滿足的 限制條件 ，對(duì)其進(jìn)行權(quán)衡或調(diào)整是相當(dāng)困難的，甚至是不可能的； ? 例如： – 系統(tǒng)必須用 C++或其他面向?qū)ο笳Z(yǔ)言編寫(xiě)； – 系統(tǒng)用戶接口需要采用圖形化界面； – 任取 10秒，一個(gè)特定應(yīng)用所消耗的可用計(jì)算能力平均不超過(guò) 50%； – 系統(tǒng)開(kāi)發(fā)過(guò)程和交付文檔需遵循 GB/T 85672023標(biāo)準(zhǔn)； – 通訊接口必須符合 ISO七層架構(gòu)。 2023/1/30 28 6. 業(yè)務(wù)規(guī)則 ? 業(yè)務(wù)規(guī)則 (Business Rule)： 對(duì)某些功能的可執(zhí)行性或 內(nèi)部執(zhí)行邏輯 的一些限定條件。 ? 必須在對(duì)話窗口的中間顯示錯(cuò)誤警告，使用紅色的、 14點(diǎn)加粗 Arial字體。 ? 系統(tǒng)應(yīng)該在 5分鐘內(nèi)計(jì)算出給定季度的總銷售稅。 ? 系統(tǒng)必須支持 100個(gè) Windows工作站的并行訪問(wèn)。 2023/1/30 31 需求規(guī)格說(shuō)明 2023/1/30 32 需求規(guī)格說(shuō)明是指軟件所應(yīng)滿足的全部要求，并用文檔方式完整和精確描述。 2023/1/30 33 軟件需求的分類 好的需求 vs 壞的需求 2023/1/30 34 好的需求應(yīng)具備的特征 ? 完整性： 每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚 ? 正確性： 每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開(kāi)發(fā)的功能； ? 可行性： 每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的 ? 必要性： 每一項(xiàng)需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來(lái) ? 劃分優(yōu)先級(jí)： 給每項(xiàng)需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級(jí)以指明它在特定產(chǎn)品中所占的分量 ? 無(wú)二義性： 對(duì)所有需求說(shuō)明的讀者都只能有一個(gè)明確統(tǒng)一的解釋 ? 可驗(yàn)證性： 檢查一下每項(xiàng)需求是否能通過(guò)設(shè)計(jì)測(cè)試用例或其它驗(yàn)證方法，如用演示、檢測(cè)等來(lái)確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn) 2023/1/30 35 產(chǎn)生不合格需求的原因 ? 無(wú)足夠用戶參與 ——―我不明白為什么要花那么多功夫收集需求” ——―與其與用戶討論浪費(fèi)時(shí)間，不如寫(xiě)代碼有意思” ——―我已經(jīng)明白用戶需求了” ? 用戶需求的不斷增加 ——若不斷增加新需求，項(xiàng)目就越來(lái)越龐大以致超過(guò)其計(jì)劃及預(yù)算范圍 ——開(kāi)發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù) 2023/1/30 36 產(chǎn)生不合格需求的原因 ? 模棱兩可的需求 ——諸多讀者對(duì)需求說(shuō)明產(chǎn)生了不同的理解 ——單個(gè)讀者能用不止一個(gè)方式來(lái)解釋某個(gè)需求說(shuō)明 ——后果：返工，重做一些你認(rèn)為已做好的事情 ? 不必要的特性 ——―畫(huà)蛇添足”，開(kāi)發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說(shuō)明中并未涉及的新功能 ——客戶可能要求一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本 2023/1/30 37 產(chǎn)生不合格需求的原因 ? 過(guò)于精簡(jiǎn)的規(guī)格說(shuō)明 ——給開(kāi)發(fā)人員帶來(lái)挫折，使他們?cè)诓徽_的假設(shè)前提和極其有限的指導(dǎo)下工作 ——給客戶帶來(lái)煩惱，他們無(wú)法得到他們所設(shè)想的產(chǎn)品 ? 忽略了用戶分類 ——軟件由不同的人使用其不同的特性 ——使用頻繁程度有所差異 ——使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同 ? 不準(zhǔn)確的計(jì)劃 ——對(duì)需求分析缺乏理解會(huì)導(dǎo)致過(guò)分樂(lè)觀的估計(jì) ——原因：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說(shuō)明和不完善的需求分析 2023/1/30 38 [案例分析 2]―他們忙，沒(méi)有時(shí)間與你討論需求 …‖ ? Contoso公司的 CEO Gerhard約見(jiàn)軟件開(kāi)發(fā)小組Cynthia，商討為公司開(kāi)發(fā)新系統(tǒng)的事情 … Gerhard 我們需要建立一套化學(xué)制品跟蹤信息系統(tǒng)，可以記錄并查詢庫(kù)房或某個(gè)實(shí)驗(yàn)室中已有的化學(xué)藥品 … 你們小組能在五個(gè)月內(nèi)開(kāi)發(fā)出該系統(tǒng)嗎？ Cynthia 我已經(jīng)明白這個(gè)項(xiàng)目的重要性了，但在我制定計(jì)劃前，我們必須收集一些系統(tǒng)的需求。我需要一些分析人員與一些知道系統(tǒng)使用要求的化學(xué)專家進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。 Gerhard 行了，行了，我們沒(méi)有那么多時(shí)間，我來(lái)告訴你需求，請(qǐng)馬上開(kāi)始開(kāi)發(fā)系統(tǒng)，并隨時(shí)將你們的進(jìn)展情況告訴我。 改正：如果用戶試圖透支，系統(tǒng)將顯示錯(cuò)誤信息并拒絕取款操作。 改正：系統(tǒng)將在 20秒內(nèi)響應(yīng)所有有效的請(qǐng)求。 考慮以下需求是否滿足“好需求”的標(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ā)和管理軟件的需求。 ? 需求工程突出了工程化原則，強(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)的用戶，并獲取用戶的需求信息。 3．根據(jù)需求信息建立軟件系統(tǒng)的邏輯模型和需求模型，確定非功能需求和約束條件及限制。 5．評(píng)審需求規(guī)格說(shuō)明。 2023/1/30 46 需求工程過(guò)程分為需求開(kāi)發(fā)和需求管理兩階段。 對(duì)獲得的用戶需求信息進(jìn)行分析和綜合，找出錯(cuò)誤和沖突及遺漏的地方，獲得用戶的準(zhǔn)確的需求，進(jìn)而建立軟件系統(tǒng)的邏輯模型或需求模型。 2023/1/30 48 審查和驗(yàn)證軟件系統(tǒng)需求規(guī)格說(shuō)明，進(jìn)而確定需求規(guī)格說(shuō)明是否正確描述了用戶對(duì)軟件系統(tǒng)的需求。 2023/1/30 49 需求狀態(tài)跟蹤 需求工程的總體流程 需求獲取 需求分析 需求規(guī)格說(shuō)明 (SRS) 需求驗(yàn)證 客戶 (client) 終端用戶 (user) 市場(chǎng)人員 維護(hù)人員 基線 (baseline) 需求管理 需求變更過(guò)程 需求變更 項(xiàng)目變更 需求開(kāi)發(fā) 需求管理 2023/1/30 50 需求開(kāi)發(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í) 的劃分 ? 將所收集的用戶需求 編寫(xiě)成規(guī)格說(shuō)明和模型 ? 評(píng)審需求規(guī)格說(shuō)明 ，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開(kāi)發(fā)小組接受說(shuō)明之前將問(wèn)題都弄清楚 2023/1/30 51 (1) 需求獲取 ? 需求獲取 (Requirement Elicitation)： 通過(guò)與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及對(duì)任務(wù)進(jìn)行分析，從而開(kāi)發(fā)、捕獲和修訂用戶的需求 – 對(duì)用戶進(jìn)行分類 – 聆聽(tīng)每一類用戶的需求 – 分析和整理所獲取的需求 – 形成文檔化的描述 – 簽字確認(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ī)格說(shuō)明 ? 需求規(guī)格說(shuō)明 (Software Requirement Specification, SRS)： – 需求開(kāi)發(fā)的結(jié)果 – 精確的、形式化的闡述一個(gè)軟件系統(tǒng)必須提供的功能、非功能、所要考慮的限制條件等 – 作為用戶和開(kāi)發(fā)者之間的一個(gè)契約 – 是用戶、分析人員和設(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ǔ)充。 2023/1/30 61 “看似簡(jiǎn)單，實(shí)際卻很難 …‖ —— ―需求獲??？不就是問(wèn)問(wèn)題嗎？這有什么難的？” 2023/1/30 65 需求獲取技術(shù) ? 需求獲取的關(guān)鍵： – 溝通和交流 ? 所要避免的問(wèn)題： – 交流障礙、溝通不全、意見(jiàn)沖突 ? 所要必備的條件： – 較高的技術(shù)水平、豐富的實(shí)踐