1、第二章：軟件項目需求管理，2.3需求管理，2.1需求工程，2.4案例故事分析，2.2需求開發(fā)，2.5總結(jié)，2.1需求工程，2.1軟件需求概念2.1.2軟件需求層次2.1.3軟件需求質(zhì)量評估2.1.4需求工程開發(fā)歷史2.1.5需求工程研究內(nèi)容簡單軟件需求是決定系統(tǒng)需要做什么。嚴(yán)格來說，軟件需求是系統(tǒng)或軟件必須達到的目標(biāo)和能力。2.1.1軟件需求概念，定義：需求管理，項目計劃，系統(tǒng)測試過程，項目跟蹤和控制過程，變更控制過程，系統(tǒng)構(gòu)建，用戶文檔過程，基礎(chǔ)，產(chǎn)品可以追溯到，供參考，并驗證為實現(xiàn)。作為基線，進行變更，跟蹤狀態(tài)，作為輸入，在基線確定之前縮小范圍，縮小請求范圍，以及軟件需求在軟件項目中的作用

2、(如圖2.1所示)，2.1.1軟件需求概念， 圖2.1軟件需求與其他軟件過程的關(guān)系，2.1.2軟件需求層次，原始問題描述，用戶需求，系統(tǒng)需求，軟件設(shè)計描述和軟件需求的四個抽象層次軟件需求的抽象層次如圖2.2所示：軟件需求的抽象層次如圖2.2所示，軟件需求的層次如圖2.1.2所示，原始問題：描述是對需要解決的問題的描述。 用戶需求以自然語言和圖表的形式給出，包括系統(tǒng)需要提供的服務(wù)和系統(tǒng)的操作限制。系統(tǒng)要求以詳細的術(shù)語給出。因此，系統(tǒng)需求文檔也稱為功能描述軟件設(shè)計：功能描述是在系統(tǒng)需求的基礎(chǔ)上增加更詳細的內(nèi)容而形成的，是詳細軟件設(shè)計和實現(xiàn)的基礎(chǔ)，是軟件設(shè)計活動的概要描述。2.1.2軟件需求層次、原

3、始問題描述和用戶需求的抽象層次相對較高，這有助于我們在更高的抽象層次上進行溝通。為了便于用戶和軟件開發(fā)人員之間的理解和交流，系統(tǒng)需求和軟件設(shè)計描述是具體的，可以根據(jù)它們進行編碼。通常，用戶需求和系統(tǒng)需求經(jīng)常被提及，2.1.2軟件需求層次，用戶需求用戶需求從用戶的角度描述系統(tǒng)需求，這樣沒有專業(yè)技術(shù)背景的用戶可以理解它，只能描述系統(tǒng)的外部行為。盡量避免涉及系統(tǒng)內(nèi)部的設(shè)計特征，這樣用戶需求就不能用任何實現(xiàn)模型來描述，而只能用自然語言、圖表、圖形等來描述。2.1.2軟件需求層次，使用自然語言可能會有以下問題：描述困難，需求混亂，所以在編寫需求文檔時應(yīng)該遵循一些簡單的原則：標(biāo)準(zhǔn)格式，一致的語言，特殊的文

4、本，盡量避免使用技術(shù)術(shù)語。2.1.2軟件需求層次、系統(tǒng)需求和系統(tǒng)需求是比用戶需求更詳細、更專業(yè)的需求描述，是系統(tǒng)實現(xiàn)的基礎(chǔ)，是完整、一致的系統(tǒng)需求描述，是軟件設(shè)計的起點。系統(tǒng)需求描述通常采用結(jié)構(gòu)化語言和過程設(shè)計語言PDL。2.1.2軟件需求級別，系統(tǒng)需求描述語言3360，表2.1系統(tǒng)需求描述語言，2.1.2軟件需求級別，系統(tǒng)需求的分類，功能需求和非功能需求領(lǐng)域需求，2.1.2軟件需求級別，(1)功能需求功能需求描述系統(tǒng)應(yīng)該提供的功能和服務(wù)，包括系統(tǒng)應(yīng)該提供的服務(wù)，并且系統(tǒng)的功能需求在特定條件下的輸入響應(yīng)和系統(tǒng)行為方面幾乎不可能是全面和一致的。第二，用戶和開發(fā)人員站在不同的立場上，這導(dǎo)致他們對需

5、求的理解有偏差，甚至矛盾。為了保證軟件項目的成功，無論在哪個階段，只要發(fā)現(xiàn)問題，需求文檔都必須進行修改。2.1.2軟件需求層次。(2)非功能性需求非功能性需求是指那些不直接相關(guān)的需求根據(jù)非功能性需求的來源，可以分為三類：產(chǎn)品需求、制度需求和外部需求；產(chǎn)品需求描述產(chǎn)品的行為；機構(gòu)要求描述了用戶和開發(fā)人員工作的機構(gòu)的政策和法規(guī)；外部要求的范圍相對較廣，包括系統(tǒng)的所有外部因素和開發(fā)過程。2.1.2軟件需求級別，表2.2非功能性需求的類別，2.1.2軟件需求級別，(3)領(lǐng)域需求領(lǐng)域需求的來源不是系統(tǒng)的用戶，而是系統(tǒng)應(yīng)用的領(lǐng)域，反映了該領(lǐng)域的特點。領(lǐng)域需求可以是功能性需求或非功能性需求，這決定了需要領(lǐng)域

6、知識。2.1.2軟件需求層次，2.1.3軟件需求質(zhì)量評估，一個好的需求集應(yīng)該滿足用戶解決問題所需的功能和服務(wù)，并盡量避免軟件設(shè)計和軟件實現(xiàn)的細節(jié)。軟件需求質(zhì)量度量：的九個要素是正確和明確的，完整性一致性是根據(jù)重要性和穩(wěn)定性、可驗證性、可修改性、可追溯性和可理解性來分級的，導(dǎo)致人們逐漸認識到需求分析活動不再局限于軟件開發(fā)的初始階段，而是貫穿于需求工程是一個包括創(chuàng)建和維護需求文檔的所有必要活動的過程，是一個將用戶的非正式軟件需求轉(zhuǎn)化為正式需求規(guī)范的過程。需求規(guī)格說明是軟件設(shè)計、實現(xiàn)、測試和維護的主要依據(jù)。2.1.4需求工程的發(fā)展過程，發(fā)展需求工程的發(fā)展趨勢是客觀化、形式化和自動化，并將向縱深和全面

7、發(fā)展。()需求工程的對象化主要是指需求模型及其構(gòu)建方法的對象化，面向?qū)ο蟮男枨竽Ｐ秃托枨蠖x語言是其研究的關(guān)鍵。2.1.4需求工程的發(fā)展歷史，()有三種正式方法：正式方法、非正式方法和半正式方法。形式化方法：它是一種用嚴(yán)格的數(shù)學(xué)基礎(chǔ)描述系統(tǒng)特性的方法，準(zhǔn)確、明確，有助于驗證有效性和完整性。非正式方法：使用自然語言容易理解和使用，沒有任何限制，但它本身是模糊的，很難保證正確性和可維護性，也很難由計算機系統(tǒng)提供自動支持。半形式化方法：在上述兩種方法之間，它可以在宏觀上準(zhǔn)確地描述語言和語義，而在一些局部方面，它允許使用非正式的自然語言。2.1.4需求工程的發(fā)展歷史，(3)自動化已經(jīng)從實施層面和設(shè)計層

8、面發(fā)展到功能層面，并逐漸滲透到需求層面。2.1.4需求工程的發(fā)展歷史，2.1.5需求工程的研究內(nèi)容，需求工程的目標(biāo)需求工程有兩個主要任務(wù)：第一，通過對問題及其環(huán)境的理解、分析和綜合，建立分析模型；其次，在充分了解用戶對軟件系統(tǒng)的確切需求的基礎(chǔ)上，用用戶需求表來表達用戶的需求。建立需求分析模型分析模型是一組描述軟件需求的模型。需求分析模型包括問題及其環(huán)境所涉及的信息流、處理功能、用戶界面、行為模型和設(shè)計約束，是形成需求規(guī)格說明、設(shè)計和實現(xiàn)軟件的基礎(chǔ)。()編寫軟件參考系統(tǒng)軟件參考系統(tǒng)應(yīng)以需求分析模型為基礎(chǔ)，根據(jù)軟件組織定義的軟件參考系統(tǒng)大綱，并使用一些需求描述語言。2.1.5需求工程研究內(nèi)容，需求

9、工程的層次分解需求工程可分為需求開發(fā)和需求管理。前者衡量需求的產(chǎn)生，而后者衡量需求變化的控制。圖2.3需求工程的研究內(nèi)容、2.1.5需求工程的研究內(nèi)容、需求開發(fā)和需求管理有邊界，如圖2.4所示：圖2.4需求開發(fā)和管理的邊界、2.1.5需求工程的研究內(nèi)容、2.2需求開發(fā)、2.2.1需求開發(fā)活動、2.2.2需求獲取、2.2.3需求分析、2.2.4需求文件的編制、2.2.5需求驗證、2.2.6某公司“船舶發(fā)電”的：需求開發(fā)案例表2.5需求開發(fā)需求獲取的主要活動和成果：確定需求開發(fā)流程、編制項目視圖和范圍文件、對用戶進行分類、選擇產(chǎn)品代表、建立核心團隊、確定用例、召開應(yīng)用程序開發(fā)聯(lián)系會議、分析用戶工作

10、流程、確定質(zhì)量屬性、檢查問題報告、重用需求、2.2.2需求獲取、2.2.3需求分析，包括細化、分析和仔細審查收集的需求，以確保項目參與者理解其含義并找出錯誤、遺漏或其他缺陷。 需求分析的目的：為了獲得高質(zhì)量的特定需求，繪制相關(guān)圖，創(chuàng)建用戶界面原型，分析可行性，確定需求優(yōu)先級，建立需求模型，編寫數(shù)據(jù)字典，應(yīng)用質(zhì)量功能分配，2.2.3需求分析，在編寫需求文檔時，應(yīng)注意以下幾點：當(dāng)語句和段落表達盡可能簡短時，主動語態(tài)語句應(yīng)完整且符合語法，標(biāo)點符號和其他正確使用的術(shù)語應(yīng)與詞匯表中的定義一致。在陳述時，我們應(yīng)該采用一致的風(fēng)格來避免模糊和主觀的術(shù)語，如優(yōu)績避免使用比較級的詞語，并盡量給出量化的解釋。含糊不

11、清的語句會導(dǎo)致無法驗證的需求。2.2.4編寫需求文檔，并使用對象需求文檔的角色。軟件項目客戶了解軟件項目能夠提供的軟件產(chǎn)品。為了檢查軟件需求是否充分，項目經(jīng)理需要根據(jù)需求文檔制定項目的開發(fā)計劃和軟件流程。對資源使用的初步預(yù)測軟件開發(fā)人員了解要開發(fā)的產(chǎn)品和要開發(fā)的具體內(nèi)容。軟件測試人員驗證軟件系統(tǒng)是否滿足預(yù)期要求。軟件維護人員使用需求文檔來幫助理解軟件系統(tǒng)的內(nèi)在邏輯關(guān)系。軟件發(fā)布者基于需求文檔來編譯用戶文檔，例如用戶手冊。軟件培訓(xùn)師根據(jù)需求文檔編寫培訓(xùn)材料。需求文檔：2.2.4的功能是編制需求文檔和軟件需求規(guī)范，(1)基本含義規(guī)范是預(yù)期的或現(xiàn)有的計算機系統(tǒng)的表示，它可以作為開發(fā)人員和用戶之間達成

12、協(xié)議的基礎(chǔ)，以生成預(yù)期的系統(tǒng)軟件需求規(guī)范SRS，也稱為功能規(guī)范、需求協(xié)議或系統(tǒng)規(guī)范。它是對外部行為和系統(tǒng)環(huán)境(軟件、硬件、通信端口和人機界面)的簡明而完整的描述性文檔。軟件項目經(jīng)理使用SRS來計劃和管理項目。除了設(shè)計和實施的限制之外，SRS一般不包括設(shè)計、施工、測試或項目管理的細節(jié)。2.2.4準(zhǔn)備要求文件。服務(wù)請求系統(tǒng)的基本內(nèi)容包括功能性需求和非功能性需求。功能需求定義了系統(tǒng)需要做什么，描述了系統(tǒng)輸入輸出及其相關(guān)信息的映射，完整地描述了系統(tǒng)功能，這是整個軟件需求的核心。非功能性需求定義了系統(tǒng)的屬性，描述了與功能無關(guān)的目標(biāo)系統(tǒng)特征，包括系統(tǒng)的性能、有效性、可靠性、安全性、可維護性和可見性。(2)

13、電氣和電子工程師協(xié)會標(biāo)準(zhǔn)830-1998，2.2.4，編制要求文件，介紹a.1要求規(guī)范的目的a.2軟件產(chǎn)品范圍a.3定義，縮寫a.4參考a.5文件概要b .一般說明b.1產(chǎn)品觀點b.2產(chǎn)品功能b.3用戶特征b.4一般約束b.5假設(shè)和依賴性c特殊要求包括功能要求、非功能要求和接口要求d附錄e索引，2.2.4要求文件的準(zhǔn)備，2.2.5要求驗證，要求驗證過程應(yīng)根據(jù)要求文件2.2.5要求驗證、2.2.6案例：公司“船舶發(fā)電”項目的需求開發(fā)中定義的要求進行各種類型的檢查，參見教科書P57。 2.3.1需求管理的必要性2.3.2需求管理的難度2.3.3需求管理的目標(biāo)和原則2.3.4需求管理活動2.3.5需

14、求變更管理2.3.6需求狀態(tài)2.3.7需求文檔版本控制2.3.8需求跟蹤2.3.8案例：需求變更的成本，2.3需求管理需求變更且難以表達的軟件項目中的問題是需求分析階段的禍根。軟件需求仍然難以表達。正是因為需求描述的可變性和困難性，才需要科學(xué)的分析和管理方法。2.3.1需求管理的必要性、需求錯誤的高頻率和修復(fù)需求錯誤的高成本是軟件項目開發(fā)中最常見的。修復(fù)軟件缺陷的高成本，如圖2.5，所示，2.3.1需求管理的必要性，需求階段出現(xiàn)的錯誤，維護階段的修復(fù)成本大約是需求階段的兩倍。對于軟件缺陷，發(fā)現(xiàn)和修復(fù)得越早，成本就越低。做好需求管理，減少需求錯誤的發(fā)生，對于降低軟件項目的成本非常重要。圖2.5軟

15、件缺陷修復(fù)的成本，2.3.2需求管理的難度，需求并不總是顯而易見的，它可以來自各個方面；需求總是可以用語言清楚而容易地表達出來；不同的需求有不同的細節(jié)層次。如果不加以控制，需求數(shù)量本身將難以管理；需求是相互關(guān)聯(lián)的，并且需求還與軟件工程過程中的其他交付物相關(guān)。需求的獨特特征或特征值。例如，他們的重要性和滿意度是不同的；需求涉及許多相關(guān)的方面，這意味著需求應(yīng)該由職能重疊的每一組人來管理；要求會改變；要求可能是時間敏感的。2.3.3需求管理的目標(biāo)和原則。目標(biāo)需求管理的目的是在客戶和處理客戶需求的軟件項目團隊之間建立對客戶需求的共同理解。具體來說，需求管理有兩個目標(biāo)： (1)控制軟件需求并為軟件工程和

16、管理建立需求基線。(2)使軟件計劃、產(chǎn)品和活動符合軟件要求。有效需求管理的原則，應(yīng)遵循以下五個原則：(1)必須對需求進行分類和管理；(2)必須對需求進行優(yōu)先排序；(3)必須記錄需求；(4)一旦需求發(fā)生變化，就必須評估需求變化的影響；(5)需求管理必須與需求工程的其他活動緊密結(jié)合。需求管理策略必須與投入相關(guān)。需求變化必須得到投資者的批準(zhǔn)。小的需求變化也必須通過正式的需求管理流程。準(zhǔn)確的需求和范圍定義不會阻止需求變化。2.3.4需求管理的目標(biāo)和原則，2.3.4需求管理活動，需求管理規(guī)劃包括需求識別、變更管理過程、需求跟蹤和自動化工具。需求管理是理解和控制系統(tǒng)需求變化的過程。需求管理的過程與其他需求工程過程是相互關(guān)聯(lián)的。需求管理計劃在導(dǎo)出初始需求的同時開始。一旦需求文檔的草稿版本形成，需求管理活動就開始了。需求管理活動的具體內(nèi)容見表2.3:表2.3需求管理活動、2.3.4需求管理活動、2.3.5需求變更管理、需求變更的原因軟件項目的需求總是在變化。有兩個普遍的原因： (1)在項目的早期階段，所有的問題都不能完全定義，軟件需求不完整，這注定了需求的變化。(2)隨著軟件項目的進展，軟件開發(fā)人員的理解會發(fā)生變化，這些變化應(yīng)該反饋到需