1、第三章 軟件需求管理 3.1 需求工程與需求管理的概念需求工程與需求管理的概念3.1.1 需求的噩夢需求的噩夢3.1.2 需求與需求管理的概念需求與需求管理的概念3.1.3 現代軟件工程的需求工程現代軟件工程的需求工程3.1.4 傳統軟件工程的局限性傳統軟件工程的局限性 對大多數軟件和系統開發團隊來說，與過去自由對大多數軟件和系統開發團隊來說，與過去自由的日子相比，的日子相比，20 20 世紀世紀 90 90 年代是一個強調流程的時年代是一個強調流程的時代。評測和驗證有效的軟件開發流程的標準得到推廣代。評測和驗證有效的軟件開發流程的標準得到推廣和普及。許多論述軟件開發流程的書籍和文獻以及關和普

2、及。許多論述軟件開發流程的書籍和文獻以及關于業務建模和重構的相關材料紛紛出版。不斷涌現出于業務建模和重構的相關材料紛紛出版。不斷涌現出的軟件工具已經幫助人們制定和應用有效的軟件開發的軟件工具已經幫助人們制定和應用有效的軟件開發流程。在這十年內，全球經濟對軟件的依賴程度加深，流程。在這十年內，全球經濟對軟件的依賴程度加深，它推動著開發流程的發展，提高了系統質量。它推動著開發流程的發展，提高了系統質量。 既然如此，那么今天頻頻發生的軟件項目失敗的既然如此，那么今天頻頻發生的軟件項目失敗的事件又如何解釋呢？事件又如何解釋呢？ 即使不是大多數，但為什么仍即使不是大多數，但為什么仍有那么多的項目受到延期

3、、預算超支和質量問題的困有那么多的項目受到延期、預算超支和質量問題的困擾呢？隨著我們的業務、國家經濟和日常活動越來越擾呢？隨著我們的業務、國家經濟和日常活動越來越依賴于系統，如何才能提高系統的質量？依賴于系統，如何才能提高系統的質量？ 需求工程與需求管理的概念為什么要管理需求？為什么要管理需求？簡單地說，系統開發團隊之所以管理需求，是因為他們簡單地說，系統開發團隊之所以管理需求，是因為他們想讓項目獲得成功。滿足項目需求即為成功打下了基礎。想讓項目獲得成功。滿足項目需求即為成功打下了基礎。若無法管理需求，達到目標的幾率就會降低。若無法管理需求，達到目標的幾率就會降低。也就是說：好的需求管理是項目

4、成功的第一位因素。采也就是說：好的需求管理是項目成功的第一位因素。采用需求管理可以給用需求管理可以給項目項目組帶來很多的好處，直至項目取組帶來很多的好處，直至項目取得成功得成功。 Brooks1987Brooks1987：不能得到完整、正確以及無二義性的軟：不能得到完整、正確以及無二義性的軟件需求仍然是如今導致軟件開發失敗的一個重大原因件需求仍然是如今導致軟件開發失敗的一個重大原因3.1.1 需求的噩夢需求的噩夢一組數字一組數字據據Standish Group(1994)Standish Group(1994)的研究表明，在美國：的研究表明，在美國：n每年大約花每年大約花25002500億美元

5、，開發億美元，開發17.517.5萬個應用程序項目萬個應用程序項目n大公司開發項目的平均成本是大公司開發項目的平均成本是232.2232.2萬美元萬美元n中等公司的平均成本是中等公司的平均成本是133.1133.1萬美元萬美元n小公司則是小公司則是43.443.4萬美元萬美元另一方面：另一方面：n大約大約31%31%的項目在完成之前被取消的項目在完成之前被取消n52.7%52.7%的項目成本是項目原來預算的的項目成本是項目原來預算的189%189%因此，因此， Standish Group估計，美國公司和政府機構估計，美國公司和政府機構l在被取消軟件項目上的花費，每年大約是在被取消軟件項目上的

6、花費，每年大約是810810億美元億美元l同樣，他們為超過交付時間而需要多支付同樣，他們為超過交付時間而需要多支付590590億美元億美元軟件開發的問題分類軟件開發的問題分類1 1、需求規格說明、需求規格說明4 4、軟件和測試、軟件和測試2 2、管理客戶需求、管理客戶需求5 5、項目管理、項目管理3 3、建檔、建檔6 6、編碼、編碼問題的重要性依次降低問題的重要性依次降低ESPITI(ESPITI(歐洲軟件過歐洲軟件過程改進培訓倡議）程改進培訓倡議）（19951995）所作的一個）所作的一個調查，調查，38003800個被調查個被調查者認為，軟件開發的者認為，軟件開發的主要問題、次要問題主要問

7、題、次要問題和不是問題的問題如和不是問題的問題如圖。圖。一半以上的人認為，一半以上的人認為，軟件的二個最大問題軟件的二個最大問題是：是：1 1、需求規格說明、需求規格說明2 2、管理客戶需求、管理客戶需求相對而言，編碼不是相對而言，編碼不是問題問題項目失敗的根本原因項目失敗的根本原因Standish GroupStandish Group的研究表明，對軟件項目的評價因素，可的研究表明，對軟件項目的評價因素，可以歸納為：以歸納為： 成功（大公司只占成功（大公司只占9%9%、小公司有、小公司有16%16%） 有異議（推遲且沒有達到預期的目標）有異議（推遲且沒有達到預期的目標） 失敗（取消）失敗（取

8、消）而有異議的三個主要原因是：而有異議的三個主要原因是： 1 1、缺乏用戶的參與（占所有項目的、缺乏用戶的參與（占所有項目的13%13%） 2 2、不完整的需求和規格說明（占、不完整的需求和規格說明（占所有項目的所有項目的12%12%） 3 3、不斷改變的需求和規格說明（占、不斷改變的需求和規格說明（占所有項目的所有項目的12%12%）而其他因素，則比例較小，例如：而其他因素，則比例較小，例如： 不合理的時間進度和時間分段（不合理的時間進度和時間分段（4%4%） 人和資源不足（人和資源不足（6%6%） 技術技能不夠（技術技能不夠（7%7%） 結論：結論：1/31/3的項目直接與需求的獲取、建檔

9、和管理有關的項目直接與需求的獲取、建檔和管理有關需求變化合理范圍內的變化：n用戶不了解自己的需求n需求本身易變，市場、技術、競爭因素不合理的變化：n需求文檔質量不高n需求分析技能、技術和管理上的缺陷需求變化的原因：需求變化的原因：n未受控制的需求變更n遺漏需求n用戶交流不夠n需求規約質量差n低效的需求分析為什么要管理需求？為什么要管理需求？迭代開發模式下，需求在項目各迭代開發模式下，需求在項目各階段所占有的比例階段所占有的比例需要更好地適應需求變化、更好的進行范圍控制和管理需要更好地適應需求變化、更好的進行范圍控制和管理需求錯誤的代價需求錯誤的代價修復的相對成本修復的相對成本開發階段開發階段需

10、求階段需求階段0.1-0.20.1-0.2設計設計0.50.5維護維護2020驗收測試驗收測試5 5單元測試單元測試2 2編碼編碼1 13.1.2 需求與需求管理的概念需求與需求管理的概念什么是需求？什么是需求？n需求的基本概念需求的基本概念 寬泛地講，需求來源于用戶的一些寬泛地講，需求來源于用戶的一些“需要需要”，這些，這些“需需要要”被分析、確認后形成完整的文檔，該文檔詳細地說被分析、確認后形成完整的文檔，該文檔詳細地說明了產品明了產品“必須或應當必須或應當”做什么。做什么。 需求是對系統要做什么、如何工作、表現出來的特征、需求是對系統要做什么、如何工作、表現出來的特征、必須具備的質量、必

11、須滿足的約束的敘述必須具備的質量、必須滿足的約束的敘述n需求的重要性需求的重要性需求是產品的根源，需求工作的優劣對產品影響最大。就像一條需求是產品的根源，需求工作的優劣對產品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。河流，如果源頭被污染了，那么整條河流也就被污染了。 國內軟件業的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌國內軟件業的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發。不停地開發。 什么是軟件需求？什么是軟件需求？ 一般一般把需求定義為把需求定義為“（正在構建的）系統必須符合的（正在構建的）系統必須符合的條件或具備的功能或能力條件或具備的功能或能力

12、”。電氣和電子工程師學會使。電氣和電子工程師學會使用的定義與此類似。用的定義與此類似。 著名的需求工程設計師著名的需求工程設計師 Merlin Dorfman Merlin Dorfman 和和 Richard H. Thayer Richard H. Thayer 提出了一個包容且更為精練的定義，提出了一個包容且更為精練的定義，它特指軟件方面它特指軟件方面 - - 但不僅僅限于軟件：但不僅僅限于軟件： 1 1、軟件需求可定義為：、軟件需求可定義為： 用戶需解決某一問題或達到某用戶需解決某一問題或達到某一目標所需的軟件功能。一目標所需的軟件功能。 2 2、系統或系統構件為了滿足合同、規約、標準

13、或其他、系統或系統構件為了滿足合同、規約、標準或其他正式實行的文檔而必須滿足或具備的軟件功能。正式實行的文檔而必須滿足或具備的軟件功能。需求全部是來自用戶嗎？需求全部是來自用戶嗎？需求的分解需求的分解問題領域需要問題領域需要用戶需求用戶需求軟件系統需要軟件系統需要系統需求系統需求應用系統需要應用系統需要系統特性系統特性什么是需求管理？什么是需求管理？ 由于需求是正在構建的系統必須符合的事務，而且符合由于需求是正在構建的系統必須符合的事務，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什么，某些需求決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進行組織，并在發生變化時對它們進

14、行追將它們記下來，進行組織，并在發生變化時對它們進行追蹤，這些活動過程，就是需求管理。蹤，這些活動過程，就是需求管理。 換句話說，需求管理就是：換句話說，需求管理就是： 一種獲取、組織并記錄系一種獲取、組織并記錄系統需求的系統化方案，以及一個使客戶與項目團隊對不斷統需求的系統化方案，以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。變更的系統需求達成并保持一致的過程。 這個定義與這個定義與 Dorfman Dorfman 與與 Thayer Thayer 以及以及 IEEE IEEE 的的“軟件軟件需求工程需求工程”的定義相似。需求工程包括獲取、分析、規定、的定義相似。需求工程

15、包括獲取、分析、規定、驗證和管理軟件需求，而驗證和管理軟件需求，而“軟件需求管理軟件需求管理”則是對所有相則是對所有相關活動的規劃和控制。關活動的規劃和控制。所以，需求管理包括軟件需求過程的整個過程所以，需求管理包括軟件需求過程的整個過程軟件項目和軟件過程的需求管理軟件項目和軟件過程的需求管理 PMBOK的范圍管理的范圍管理 按照按照PMBOKPMBOK的定義，的定義，范圍范圍是指產生項目產品所包括的所是指產生項目產品所包括的所有工作及產生這些產品的過程。有工作及產生這些產品的過程。范圍管理范圍管理是指對項目包括是指對項目包括什么和不包括什么的定義與控制過程。什么和不包括什么的定義與控制過程。

16、 項目范圍管理的核心是：為了順利地完成項目而設置項目范圍管理的核心是：為了順利地完成項目而設置了一些過程，這些過程的目的是確保項目包括且僅僅包括了一些過程，這些過程的目的是確保項目包括且僅僅包括所要求的工作（交付成果）。這一控制過程的含義同時還所要求的工作（交付成果）。這一控制過程的含義同時還指：確保項目組和用戶（或稱為項目利益關系人）對作為指：確保項目組和用戶（或稱為項目利益關系人）對作為項目結果的項目產品以及生產這些產品所用到的過程有一項目結果的項目產品以及生產這些產品所用到的過程有一個共同的理解。個共同的理解。 從軟件項目的需求管理，理解項目管理的范圍管理從軟件項目的需求管理，理解項目管

17、理的范圍管理CMM2的需求管理的需求管理軟件過程能力成熟度模型（軟件過程能力成熟度模型（CMMCMM）對需求管理作了明確）對需求管理作了明確的要求，為達到的要求，為達到CMM2CMM2級，組織就必須具備滿足軟件開發級，組織就必須具備滿足軟件開發與管理的六個關鍵過程域（與管理的六個關鍵過程域（key Process Areaskey Process Areas，KPAKPA）的能力。而需求管理就是這六個關鍵過程域中的第一個，的能力。而需求管理就是這六個關鍵過程域中的第一個，是其他五個域實施的前提。是其他五個域實施的前提。 CMM2CMM2指出，指出，需求管理的目的需求管理的目的是在客戶和遵循客戶

18、需求是在客戶和遵循客戶需求的軟件項目之間建立一種共同的理解。因此，需求管理的軟件項目之間建立一種共同的理解。因此，需求管理活動的內容應包括就軟件的需求同客戶達成一種共識并活動的內容應包括就軟件的需求同客戶達成一種共識并加以管理。該加以管理。該共識共識就是就是“指定給軟件的系統需求指定給軟件的系統需求”。CMM2CMM2需求管理的目標是：需求管理的目標是：（1 1）控制指定給軟件的系統需求，為軟件工程和管理）控制指定給軟件的系統需求，為軟件工程和管理應用建立基線；應用建立基線；（2 2）保持軟件計劃、產品和活動與指定給軟件的系統）保持軟件計劃、產品和活動與指定給軟件的系統需求一致。需求一致。CM

19、M2CMM2的需求管理的需求管理 CMMCMM對需求管理的定義是：對需求管理的定義是： 對需求分配進行管理，既要在用戶和實現用戶需求的對需求分配進行管理，既要在用戶和實現用戶需求的項目組之間達成共識；控制系統需求，為研發過程和項項目組之間達成共識；控制系統需求，為研發過程和項目管理建立基線；保持項目計劃、產品和活動與系統需目管理建立基線；保持項目計劃、產品和活動與系統需求的一致性。求的一致性。 從定義出發，需求管理涉及三個方面的內容：從定義出發，需求管理涉及三個方面的內容： 需求定義的管理、需求實現的管理、需求變更的管理。需求定義的管理、需求實現的管理、需求變更的管理。 一般認為，需求管理并不

20、包括需求的收集和分析，而是一般認為，需求管理并不包括需求的收集和分析，而是假定組織已收集了軟件需求或已經明確地給出了需求的假定組織已收集了軟件需求或已經明確地給出了需求的定義。或者說，廣義的需求管理還應包括用戶需求的收定義。或者說，廣義的需求管理還應包括用戶需求的收集、處理、分析和驗證等內容。集、處理、分析和驗證等內容。 我們從廣義需求管理的概念出發，可以也歸納出需求管我們從廣義需求管理的概念出發，可以也歸納出需求管理活動的范圍主要有需求的開發和需求的管理二個部分理活動的范圍主要有需求的開發和需求的管理二個部分的內容。的內容。CMM2CMM2的需求管理的需求管理需求的開發包括：需求的開發包括：

21、（1 1） 需求獲取；需求獲取；（2 2） 需求分析；需求分析；（3 3） 編寫需求規格說明書；編寫需求規格說明書；（4 4） 需求驗證。需求驗證。 需求的管理包括：需求的管理包括：（1 1） 確定需求變更控制的過程；確定需求變更控制的過程；（2 2） 組織變更控制委員會；組織變更控制委員會；（3 3） 進行需求變更波及分析；進行需求變更波及分析；（4 4） 跟蹤所有受需求變更影響的工作產品；跟蹤所有受需求變更影響的工作產品；（5 5） 建立需求基準版本和需求控制版本文檔；建立需求基準版本和需求控制版本文檔；（6 6） 維護需求變更的歷史記錄；維護需求變更的歷史記錄；（7 7） 追蹤每項需求的

22、狀態并建立數據庫；追蹤每項需求的狀態并建立數據庫；（8 8） 衡量需求的穩定性；衡量需求的穩定性；（9 9） 使用需求管理工具進行需求管理。使用需求管理工具進行需求管理。 從從CMM2CMM2對需求管理的要求、目標和管理過程中可以看出，對需求管理的要求、目標和管理過程中可以看出，CMM2CMM2的側的側重點在于需求獲取以后，如何建立需求基準線，并依據需求基準線，重點在于需求獲取以后，如何建立需求基準線，并依據需求基準線，對項目的需求進行的控制和管理。對項目的需求進行的控制和管理。 p 面對軟件工程過程中存在的需求不確定性問題，軟件工程面對軟件工程過程中存在的需求不確定性問題，軟件工程進一步獲得

23、發展，其中一個具體體現，就是發展出進一步獲得發展，其中一個具體體現，就是發展出“需求需求工程工程”的概念。的概念。p 需求工程是提供一種適當的機制，以了解用戶想要什么、需求工程是提供一種適當的機制，以了解用戶想要什么、分析需求、評估可行性、協商合理的解決方案、無歧義地分析需求、評估可行性、協商合理的解決方案、無歧義地規約解決方案、確認規約以及在開發過程中管理這些被確規約解決方案、確認規約以及在開發過程中管理這些被確認的需求規約的過程。認的需求規約的過程。p 因此，需求工程的活動也可分為兩大過程域，一個過程域因此，需求工程的活動也可分為兩大過程域，一個過程域是需求開發，另一過程域是需求管理。是需

24、求開發，另一過程域是需求管理。需求工程的需求工程的兩大過程域兩大過程域現代軟件工程的需求工程需求開發過程需求管理過程需求獲取需求分析需求處理需求確認需求實現需求跟蹤需求變更控制3.1.3 現代軟件工程的需求工程現代軟件工程的需求工程需求開發過程域需求開發過程域 n需求開發需求開發的目的是通過調查與分析，獲取用戶需的目的是通過調查與分析，獲取用戶需求并定義產品需求。求并定義產品需求。 需求獲取需求獲取的目的是通過各種途徑獲取用戶的需求信息，的目的是通過各種途徑獲取用戶的需求信息，產生產生用戶需求說明書用戶需求說明書或或產品遠景文件產品遠景文件。 需求分析需求分析的目的是對各種需求信息進行分析，消

25、除錯誤，的目的是對各種需求信息進行分析，消除錯誤，刻畫細節等。常見的需求分析方法有刻畫細節等。常見的需求分析方法有“問答分析法問答分析法”和和“建模分析法建模分析法”兩類。兩類。 需求處理需求處理的目的是根據需求調查和需求分析的結果，進的目的是根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生一步定義準確無誤的產品需求，產生產品需求規格說產品需求規格說明書明書。系統設計人員將依據。系統設計人員將依據產品需求規格說明書產品需求規格說明書開展系統設計工作。開展系統設計工作。需求確認需求確認是指開發方和客戶共同對需求文檔進行評審，是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共

26、識后作出書面承諾，使需求文檔具有雙方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。商業合同效果。需求管理過程域需求管理過程域 需求管理需求管理的目的是在客戶與開發方之間建立對需求的共的目的是在客戶與開發方之間建立對需求的共同理解的基礎上，實現需求并在實現的過程中，維護需同理解的基礎上，實現需求并在實現的過程中，維護需求與其它工作成果的一致性，并控制需求的變更。求與其它工作成果的一致性，并控制需求的變更。 n需求實現需求實現是指在系統概要分析、詳細分析和系統編是指在系統概要分析、詳細分析和系統編碼、測試等開發過程中，實現系統的需求。碼、測試等開發過程中，實現系統的需求。n需求跟蹤需求

27、跟蹤是指通過比較需求文檔與后續工作成果之是指通過比較需求文檔與后續工作成果之間的對應關系，建立與維護間的對應關系，建立與維護“需求跟蹤矩陣需求跟蹤矩陣”，確，確保產品依據需求文檔進行開發。保產品依據需求文檔進行開發。 n需求變更控制需求變更控制是指依據是指依據“變更申請審批更改變更申請審批更改重新確認重新確認”的流程處理需求的變更，防止需求變更的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂。失去控制而導致項目發生混亂。 產品工程的產品工程的層次圖：層次圖：3.1.4 傳統傳統軟件工程的局限性軟件工程的局限性1 1、從過程看：、從過程看：現代軟件工程的需求過程要求參與整個產品生命周

28、期的需現代軟件工程的需求過程要求參與整個產品生命周期的需求管理，注重整個產品過程的全部而不是一個階段求管理，注重整個產品過程的全部而不是一個階段完整產品 硬件 軟件 數據功能行為需求工程（全局視圖）業務和系統建模分析和設計建模構造和集成實現傳統軟件工程的局限性傳統軟件工程的局限性 需求管理是全過程的需求管理是全過程的 需求處理過程產品使用維護系統構建實施產品規劃設計系統分析規約需求分析理解目標環境需求描述需求確認規格說明需求分析規范說明設計規范說明產品用戶反饋構建反饋設計反饋分析反饋需求工程需求工程的結構圖：的結構圖：傳統傳統軟件工程的局限性軟件工程的局限性2 2、從功能看：、從功能看：現代軟

29、件工程的需求過程擴大了對需求管理的功能范圍現代軟件工程的需求過程擴大了對需求管理的功能范圍傳統軟件工程的需求傳統軟件工程的需求分析，僅僅是對分析，僅僅是對“用用戶需求戶需求”的計算機術的計算機術語化語化“描述描述”轉換。轉換。（1） 確定對系統的確定對系統的綜合要求綜合要求（2） 分析系統的數分析系統的數據要求：據要求：（3） 抽象出并確立抽象出并確立目標系統的邏輯模型；目標系統的邏輯模型；（4） 編寫需求規格編寫需求規格說明書。說明書。 我們可以回憶一下，在軟件工程中，需求分析花了我們可以回憶一下，在軟件工程中，需求分析花了很大的時間和篇幅，介紹具體的需求分析的方法，很大的時間和篇幅，介紹具

30、體的需求分析的方法，比如：早期面向結構化的分析方法（比如：早期面向結構化的分析方法（SA）、數據）、數據流圖（流圖（DFD）等。）等。現代軟件工程的需求工程需求開發過程需求管理過程需求獲取需求分析需求處理需求確認需求實現需求跟蹤需求變更控制3、從思想方法上看：、從思想方法上看：我們從傳統軟件工程的定義和計劃階段的工作內容，可以我們從傳統軟件工程的定義和計劃階段的工作內容，可以看出，軟件工程認定：看出，軟件工程認定：“問題問題”已經是一個明確的、固定的、可獲得的；已經是一個明確的、固定的、可獲得的；如果通過可行性分析，認為項目可行，則此如果通過可行性分析，認為項目可行，則此“問題問題”也是可也是

31、可“求解求解”的。的。因此，根據這個假設，可以確定工作內容、產品與成因此，根據這個假設，可以確定工作內容、產品與成果、驗收標準等技術指標，也可以制訂工作進度、任務果、驗收標準等技術指標，也可以制訂工作進度、任務分解，以至可以進行成本預算等，確定了任務的目標。分解，以至可以進行成本預算等，確定了任務的目標。在這個假設下，軟件工程的需求分析，是一個在這個假設下，軟件工程的需求分析，是一個“純純”技術技術性的性的“轉換轉換”。既把用戶的需求，準確地描述為。既把用戶的需求，準確地描述為“軟件需軟件需求求”的過程。的過程。傳統傳統軟件工程的局限性軟件工程的局限性傳統軟件工程的假象前提：傳統軟件工程的假象

32、前提：（1 1）軟件工程假定：用戶需求在需求分析開始之前，是）軟件工程假定：用戶需求在需求分析開始之前，是一個基本明確的、固定的、可獲得的。一個基本明確的、固定的、可獲得的。（2 2）需求分析階段的目的，是）需求分析階段的目的，是“描述描述”這個已經存在，這個已經存在，但還沒有用開發者自己的方式但還沒有用開發者自己的方式“描述描述”出來的需求。出來的需求。（3 3）軟件工程把這個）軟件工程把這個“描述描述”工作，做了定義，就是需工作，做了定義，就是需求分析的四個任務。通過這個任務的完成，獲得數據字求分析的四個任務。通過這個任務的完成，獲得數據字典、系統的數據流定義、處理邏輯定義等手段，實現對典

33、、系統的數據流定義、處理邏輯定義等手段，實現對“用戶需求用戶需求”的描述。的描述。（4 4）軟件工程更關注這種：）軟件工程更關注這種：“描述描述”的方法和過程（需的方法和過程（需求分析方法）。求分析方法）。傳統傳統軟件工程的局限性軟件工程的局限性 3.2.1 需求開發的過程需求開發的過程3.2.2 需求獲取階段需求獲取階段3.2.3 需求分析需求分析階段階段3.2.4 需求處理需求處理階段階段3.2.5 需求驗證需求驗證階段階段3.2.1 需求開發的過程需求開發的過程需求獲取需求獲取需求分析需求分析需求處理需求處理需求驗證需求驗證 現代軟件工程的需求工程需求開發過程需求管理過程需求獲取需求分析

34、需求處理需求確認需求實現需求跟蹤需求變更控制需求開發過程或者需求開發過程或者又可以稱之為需求又可以稱之為需求定義過程，主要包定義過程，主要包括：括：回憶一下：問題定義階段的任務和步驟回憶一下：問題定義階段的任務和步驟(一一)系統任務的提出系統任務的提出1. 系統任務的提出者系統任務的提出者2. 系統任務的提出形式系統任務的提出形式3. 系統任務提出的目的系統任務提出的目的(二二)初步調查初步調查1. 初步調查的目的初步調查的目的2. 初步調查的主要內容初步調查的主要內容(三三)系統目標的確定系統目標的確定1. 系統目標的含義系統目標的含義2. 如何確定系統的目標如何確定系統的目標成果交付物：成

35、果交付物： 需求說明書需求說明書或或 產品前景文檔產品前景文檔需求開發過程的階段任務需求開發過程的階段任務需求開發過程的重要里程碑需求開發過程的重要里程碑需求獲取需求獲取需求分析需求分析需求處理需求處理需求驗證需求驗證問題定義階段需求分析階段面向用戶確認的需求描述面向實現的需求規格說明用戶確認需求評審面向實現的細化面向管理的規范面向成果的驗證3.2.2 3.2.2 需求獲取階段需求獲取階段1 12 23 34 45 56 6A A項目論證項目論證項目背項目背景景市場機市場機遇遇客戶價客戶價值值風險風險經濟效經濟效益分析益分析可行可行性分性分析析B B產品描述產品描述主要功主要功能描述能描述主要

36、性主要性能特征能特征主要質主要質量標準量標準 其他其他C C交 付 成 果交 付 成 果定義定義直接交直接交付物付物文檔文檔實施過實施過程程培訓與培訓與服務服務 其他其他D D項目目標項目目標進度目進度目標標成本目成本目標標質量目質量目標標 其他其他E E風險因素風險因素資源需資源需求保證求保證限制與限制與假設假設產品前景文檔：確定系統目標產品前景文檔：確定系統目標工具和方法工具和方法n傳統的結構化分析方法傳統的結構化分析方法分析模型描述工具分析模型描述工具nDFD、DD和和PSPEC nCFD、CSPEC和和STD nE-R圖圖n面向對象的分析方法面向對象的分析方法標識對象標識對象標識結構標

37、識結構標識主題標識主題定義屬性和實例聯系定義屬性和實例聯系定義操作和消息聯系定義操作和消息聯系分析模型描述工具分析模型描述工具n用例圖，對象用例圖，對象-關系圖，對象關系圖，對象-行為圖行為圖 工具和方法工具和方法nUML過程：過程：需求獲取需求獲取業務建模業務建模n建立業務模型和系統模型建立業務模型和系統模型n以業務用例形式與用戶建立共識，獲得確認以業務用例形式與用戶建立共識，獲得確認需求分析需求分析建立系統靜態和動態模型建立系統靜態和動態模型n靜態模型靜態模型類和對象類和對象n動態模型動態模型行為和事件流行為和事件流需求處理和驗證需求處理和驗證n9張圖表：張圖表：用例圖用例圖、類圖、對象圖

38、、狀態圖、時序圖、協作圖、活動圖、類圖、對象圖、狀態圖、時序圖、協作圖、活動圖、構件圖、構件圖、部署圖部署圖n5個視圖：個視圖：用例視圖、邏輯視圖、構件視圖、并發視圖、部署視圖用例視圖、邏輯視圖、構件視圖、并發視圖、部署視圖 編制軟件需求規格說明（Software Requirements Specification，SRS）需求獲取階段的目標需求獲取階段的目標獲得用戶的確認獲得用戶的確認建立業務模型的工作主要包括：建立業務模型的工作主要包括：分析領域中的業務角色分析領域中的業務角色分析角色間的業務功能等關系分析角色間的業務功能等關系分析業務組織架構分析業務組織架構分析業務規則分析業務規則分析

39、業務實體分析業務實體分析業務事件分析業務事件分析以業務角色為主角的業務用例等；分析以業務角色為主角的業務用例等；以業務用例為實例，與用戶進行溝通：以業務用例為實例，與用戶進行溝通：需求是否被清楚地陳述？需求是否被清楚地陳述？存在錯誤的理解嗎？存在錯誤的理解嗎？需求的來源（人員、規章制度、文件）是否正確？需求的來源（人員、規章制度、文件）是否正確？需求的最終陳述是否得到用戶最終責任人確認？需求的最終陳述是否得到用戶最終責任人確認？問題問題 用戶不知道他們需求什么或不知道如何表達直到開發人員把用戶所描述的東西給他們，用戶才認為知道自己要什么分析人員認為自己比用戶更了解用戶的需求解決方案解決方案將用

40、戶當作領域專家來認識和感激，嘗試一下其他溝通和啟發技術 盡早提供相互選擇的啟發技術：情節串聯板、原型、角色換位等把分析人員放在用戶的位置，試著換位一小時或一天解決用戶和開發人員綜合癥解決用戶和開發人員綜合癥用戶講故事介紹游戲規則 輸出結果幻燈片放映 動畫制作 仿真演示 交互演示 現場演示被動式介紹被動式介紹主動式介紹主動式介紹交互式介紹交互式介紹需求誘導的方法（情節串聯板）需求誘導的方法（情節串聯板）原型開發復雜程度與成本需求獲取過程需求管理的關注點需求獲取過程需求管理的關注點步驟：步驟： 1、發現和分析問題、發現和分析問題 2、理解用戶的需求、理解用戶的需求 3、定義系統（用例模型）、定義系

41、統（用例模型） 4、管理范圍（項目管理）、管理范圍（項目管理）方法：方法： 采用業務建模和系統建模的方法進行問題分析采用業務建模和系統建模的方法進行問題分析 對與系統架構和系統行為有關的用例進行描述和定義對與系統架構和系統行為有關的用例進行描述和定義目標：目標：p在問題定義上與用戶達成共識在問題定義上與用戶達成共識p理解問題背后的根本原因理解問題背后的根本原因p確定用戶和項目干系人確定用戶和項目干系人p定義問題解空間的邊界定義問題解空間的邊界p確定問題解決方案的約束和假設確定問題解決方案的約束和假設最終階段完成標志：用戶對系統目標的認可最終階段完成標志：用戶對系統目標的認可簽字簽字需求獲取過程

42、產品基線管理的關注點需求獲取過程產品基線管理的關注點產品前景文件產品前景文件技術創新和突破技術創新和突破產品特點產品特點客戶：涉眾和用例客戶：涉眾和用例分析人員和專家分析人員和專家的意見的意見與公司其他產品與公司其他產品的配套和一致性的配套和一致性與對手的競爭性與對手的競爭性產品差異和優勢產品差異和優勢開發團隊的狀況與開發團隊的狀況與產品的可持續性產品的可持續性系統平臺與兼容性系統平臺與兼容性公司目標與市場公司目標與市場需求需求一個真一個真正偉大正偉大的產品的產品需求獲取過程產品路線管理的關注點需求獲取過程產品路線管理的關注點V1.0V2.0V2.1V3.0V3.1新系統新系統 版本特性版本特

43、性基本功能安保接口客戶定義遠程維護多平臺支持中央控制單元戶主客戶控制開關05/0105/0705/0906/0106/03圖例：圖例：正在發行正在發行發布代碼行發布代碼行代碼行修改代碼行修改3.2.3 需求分析階段需求分析階段需求分析階段的任務和步驟需求分析階段的任務和步驟n復查系統規模和目標復查系統規模和目標n研究現有系統功能研究現有系統功能n導出新系統模型導出新系統模型n重新定義問題重新定義問題n導出和分析各種可選解決方案導出和分析各種可選解決方案n推薦行動方針推薦行動方針n草擬開發計劃草擬開發計劃n書寫文檔提交審查書寫文檔提交審查階段成果交付物：階段成果交付物：需求定義文檔（需求規格說明

44、）需求定義文檔（需求規格說明）循環循環需求分析需求分析需求獲取與需求分析的區別需求獲取與需求分析的區別需求獲取是面向用戶、在較高的抽象級別上對系需求獲取是面向用戶、在較高的抽象級別上對系統特性的定義統特性的定義l可以更多地關注系統的特性以及如何體現用戶的需可以更多地關注系統的特性以及如何體現用戶的需求，以便更好地理解系統的形狀和形式求，以便更好地理解系統的形狀和形式l可以對系統的完整性、一致性以及對環境的適應性可以對系統的完整性、一致性以及對環境的適應性進行評估進行評估l在繼續大量投入之前，可以利用這些信息決定可行在繼續大量投入之前，可以利用這些信息決定可行性和管理系統的范圍性和管理系統的范圍

45、l可以脫離對具體需求進行取舍和決策所帶來的風險可以脫離對具體需求進行取舍和決策所帶來的風險l需求獲取的目標是用戶的認可，因此，階段的驗收需求獲取的目標是用戶的認可，因此，階段的驗收標志是用戶簽字確認的需求描述標志是用戶簽字確認的需求描述需求分析需求分析需求獲取與需求分析的區別需求獲取與需求分析的區別需求分析是面向系統實現、嚴格對系統需求的定需求分析是面向系統實現、嚴格對系統需求的定義義l定義系統的輸入、輸出、功能、屬性以及系統環境定義系統的輸入、輸出、功能、屬性以及系統環境的屬性，決定系統的完整集合的屬性，決定系統的完整集合l面向系統技術實現，討論系統應該做什么，因此，面向系統技術實現，討論系

46、統應該做什么，因此，應避免受項目進度、計劃、預算、設計、測試等的影應避免受項目進度、計劃、預算、設計、測試等的影響響l需求和設計是迭代進行的，但需求將引導設計，也需求和設計是迭代進行的，但需求將引導設計，也受設計方法的制約受設計方法的制約l需求分析的驗收標志是組織的需求評審需求分析的驗收標志是組織的需求評審需求分析需求分析細化系統定義細化系統定義在需求獲取階段，我們已經通過建立業務模型、系統模型，在需求獲取階段，我們已經通過建立業務模型、系統模型，與用戶共同確定了系統的特性：與用戶共同確定了系統的特性：業務模型，可以映射出軟件產品核心的需求，包括與業務功能對業務模型，可以映射出軟件產品核心的需

47、求，包括與業務功能對應的組織的特性，與業務流程對應的內外部關系特性等；應的組織的特性，與業務流程對應的內外部關系特性等；系統用例模型，是在已經建立的業務模型的基礎上，建立系統的系統用例模型，是在已經建立的業務模型的基礎上，建立系統的模型。模型。用例用例業務模型和系統模型的最典型表示形式業務模型和系統模型的最典型表示形式p軟件產品本身可能還存在與業務無直接關系的另類需求（一般與硬軟件產品本身可能還存在與業務無直接關系的另類需求（一般與硬件、軟件環境相關），比如支持多種操作系統、對軟件運行的遠端監件、軟件環境相關），比如支持多種操作系統、對軟件運行的遠端監控要求、異常處理（如通訊連接中斷等非業務異

48、常）等等。控要求、異常處理（如通訊連接中斷等非業務異常）等等。p另一方面，設計約束和限制，也是系統需求必須要考慮的內容另一方面，設計約束和限制，也是系統需求必須要考慮的內容通常這三部分需求構成軟件需求的總集。通常這三部分需求構成軟件需求的總集。 需求分析需求分析細化系統定義細化系統定義在需求分析階段，我們不可避免地要在需求分析階段，我們不可避免地要涉及到進行設計決策涉及到進行設計決策設計決策：設計決策：p硬件環境（運行在硬件環境（運行在PC服務器上？服務器上？還是小型機？）還是小型機？）p平臺的選擇（只支持平臺的選擇（只支持Windows平臺，是否也支持平臺，是否也支持UNIX平臺？）平臺？）

49、p工具的限制（采用工具的限制（采用VB實現？）實現？）p方法的約束（用方法的約束（用XYZ類庫實現類庫實現數據庫訪問？）數據庫訪問？）當前需求使我們考慮采用某種設計選項被選擇的設計選項可能影響需求需求分析是在需求獲取、需求分析和設計決策之間反復需求分析是在需求獲取、需求分析和設計決策之間反復迭代循環的過程迭代循環的過程需求分析需求分析細化系統定義細化系統定義軟件需求是具體的：軟件需求是具體的：面向系統設計、編碼面向系統設計、編碼面向測試面向測試因此，在需求獲取的基礎上，進一步細化系統需求、明確因此，在需求獲取的基礎上，進一步細化系統需求、明確和細化系統定義，這就是需求分析階段的任務和細化系統定

50、義，這就是需求分析階段的任務在傳統軟件過程方法中，這二個階段不是非常清晰和明確在傳統軟件過程方法中，這二個階段不是非常清晰和明確系統需求功能性需求非功能性需求設計約束需求分析需求分析細化用例細化用例在需求獲取過程中，我們建立了業務模型和系統模型，引在需求獲取過程中，我們建立了業務模型和系統模型，引入了角色和用例的概念入了角色和用例的概念角色與用例的區別：角色與用例的區別：系統的角色是業務之外與業務交互的人或事系統的角色是業務之外與業務交互的人或事例如：例如：ATMATM取款機作為一個業務系統，來取款的客戶就是一個角色取款機作為一個業務系統，來取款的客戶就是一個角色用例是業務模型中，業務的活動用

51、例是業務模型中，業務的活動在系統模型中，描述了業務中系統的工作（內部活動）。角色是在系統模型中，描述了業務中系統的工作（內部活動）。角色是外部，用例是內部。取款的客戶是角色，取款是用例。外部，用例是內部。取款的客戶是角色，取款是用例。用例模型開始定義角色之間的關系（關聯關系：包括關系、擴展關系、用例模型開始定義角色之間的關系（關聯關系：包括關系、擴展關系、一般化關系等）。用例模型描述事件流，包括主事件流、其他事件流、一般化關系等）。用例模型描述事件流，包括主事件流、其他事件流、前提條件、事后條件等等。前提條件、事后條件等等。需求分析需求分析細化用例細化用例細化用例的主要步驟：細化用例的主要步驟

52、：l審查主角審查主角l細化描述細化描述l定義和細化事件流程定義和細化事件流程l確定前置條件和后置條件確定前置條件和后置條件l確定特殊需求確定特殊需求l擴展用例擴展用例需求分析需求分析細化用例關系細化用例關系為需求處理做準備為需求處理做準備在定義系統的用例規約之前，確定一份基本的術語詞匯表，以在定義系統的用例規約之前，確定一份基本的術語詞匯表，以統一項目開發中的用詞。統一項目開發中的用詞。確定系統的用例，通常從尋找系統的主角開始。如果做了業務確定系統的用例，通常從尋找系統的主角開始。如果做了業務建模，則可以先從業務對象模型中的業務工人（建模，則可以先從業務對象模型中的業務工人（Business

53、Business WorkerWorker）著手。著手。系統主要的主角確定后，可以根據為系統主角提供有價值的結系統主要的主角確定后，可以根據為系統主角提供有價值的結果（果（Result of ValueResult of Value）這一準則（用例是為主角的活動最終提這一準則（用例是為主角的活動最終提供一個有價值的結果的活動過程）來確定系統的用例。供一個有價值的結果的活動過程）來確定系統的用例。 理清系統用例之間存在的密切關系，具有的內在結構，如泛化理清系統用例之間存在的密切關系，具有的內在結構，如泛化關系、包含關系、擴展關系等。關系、包含關系、擴展關系等。 有二種有二種Interaction

54、Interaction圖，按時間順序排列的是圖，按時間順序排列的是SequenceSequence圖，按圖，按對象關系排列的是對象關系排列的是CollaborationCollaboration圖。二種圖從不同的角度，反圖。二種圖從不同的角度，反映了案例中特定情形的流程。映了案例中特定情形的流程。3.2.4 3.2.4 需求處理階段需求處理階段需求規格說明書需求規格說明書項目項目用戶需求說明書用戶需求說明書或或前景文件前景文件提供了業務需求的宏觀描提供了業務需求的宏觀描述文檔，使得公司內部相關部門對項目，有一個全局的了解。述文檔，使得公司內部相關部門對項目，有一個全局的了解。Use CaseU

55、se Case圖和圖和InteractionInteraction圖為用戶，為項目組提供了需求的詳細圖為用戶，為項目組提供了需求的詳細描述。描述。為了后續開發階段（概要設計和詳細設計）的需要，在傳統模式下為了后續開發階段（概要設計和詳細設計）的需要，在傳統模式下，有了用戶實例，還必須編寫從用戶實例派生出來的功能需求規格，有了用戶實例，還必須編寫從用戶實例派生出來的功能需求規格說明書和非功能需求文檔。說明書和非功能需求文檔。包括：質量檢驗標準、接口說明等。這些文件，成為需求分析的成包括：質量檢驗標準、接口說明等。這些文件，成為需求分析的成果。果。CMM2也規定，必須以文檔形式，給出給定需求。也規

56、定，必須以文檔形式，給出給定需求。 需求處理需求處理傳統的傳統的需求規格說明書需求規格說明書1 12 23 34 45 56 6A A引言引言目的目的文檔文檔約定約定預期的預期的讀者和讀者和閱讀建閱讀建議議產 品產 品的 范的 范圍圍參 考參 考文獻文獻B B綜合描述綜合描述產品產品前景前景產品產品的功的功能能用 戶用 戶類 和類 和特征特征運 行運 行環境環境設計和設計和實現上實現上的限制的限制假 設假 設和 依和 依賴 附賴 附錄錄C C外 部 接 口 需外 部 接 口 需求附錄求附錄用戶用戶界面界面附錄附錄硬件硬件接口接口軟 件軟 件接口接口通 信通 信接口接口D D系統特性系統特性說明

57、說明和優和優先級先級激勵激勵/ /響 應響 應序列序列功 能功 能需求需求E E其 他 非 功 能其 他 非 功 能需求需求性能性能需求需求完全完全設施設施需求需求安 全安 全性 需性 需求求軟 件軟 件質 量質 量屬性屬性業 務業 務規范規范用 戶用 戶文檔文檔F F其他需求其他需求G G附件附件詞匯詞匯表表分析分析模型模型待確定待確定問題清問題清單單軟件需求規格軟件需求規格說明書闡述一說明書闡述一個軟件系統必個軟件系統必須提供的功能須提供的功能和性能，以及和性能，以及他們必須考慮他們必須考慮的限制條件。的限制條件。這不但是測試這不但是測試和用戶使用、和用戶使用、維護文檔的基維護文檔的基礎，

58、而且，也礎，而且，也是系統的子系是系統的子系統規劃、設計統規劃、設計和編碼的基礎。和編碼的基礎。需求文檔：需求的形式化問題需求文檔：需求的形式化問題需求文檔化：需求文檔化：需求一旦確定，就需要把它用文檔的形式，固定下來。需求一旦確定，就需要把它用文檔的形式，固定下來。文檔化的目的：文檔化的目的：首先通過記錄（紙質的文字或數據庫記錄等），使需求被記錄下首先通過記錄（紙質的文字或數據庫記錄等），使需求被記錄下來。任何口頭的傳誤，在文字記錄上，會被減少。來。任何口頭的傳誤，在文字記錄上，會被減少。其次，形式化最主要的追求，是解決完整性和無歧義性。能真正其次，形式化最主要的追求，是解決完整性和無歧義性

59、。能真正達到形式化的需求，是需求分解、分配、追蹤、評估的條件。達到形式化的需求，是需求分解、分配、追蹤、評估的條件。2020世紀世紀8080年代的一項研究表明，年代的一項研究表明，20%20%的錯誤是對需求的錯誤解釋造成的的錯誤是對需求的錯誤解釋造成的。IBMIBM公司對需求描述的形式化研究，已經提出了一種保證需求文檔更公司對需求描述的形式化研究，已經提出了一種保證需求文檔更一致的需求描述方法學，使通過使用這種規定的方法建立的需求，不同一致的需求描述方法學，使通過使用這種規定的方法建立的需求，不同人寫的需求之間的差異，已經降到最小。人寫的需求之間的差異，已經降到最小。為了便于需求實現和變更控制

60、管理，需求形式化在形式上，進一步發展為了便于需求實現和變更控制管理，需求形式化在形式上，進一步發展為需求數據庫化。為需求數據庫化。需求形式化需求形式化消除歧義的努力消除歧義的努力消除需求描述的歧義性，是軟件工程的消除需求描述的歧義性，是軟件工程的“軟肋軟肋”，沒有什么更好的方法。，沒有什么更好的方法。因為對需求的描述和定義，不可能像計算機語言的定義那樣，做到無二因為對需求的描述和定義，不可能像計算機語言的定義那樣，做到無二義性。因為，代價太高了。義性。因為，代價太高了。消除歧義的方法：消除歧義的方法：原始：原始：了解和記錄用戶的最原始需求，不要轉述、不要用自己的理解代替。了解和記錄用戶的最原始