需求工程的基本過程

需求工程的活動

划分為以下5個獨立的階段：
需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；
需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，並盡可能多的捕獲現實世界的語義；
形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；
需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性，包含有效性檢查，一致性檢查，可行性檢查和確認可驗證性；
需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。

 

需求獲取階段

需求獲取首先需要的是技術的支持，其次，在需求獲取工作中主要涉及了 3 個至關重要的因素：應搜集什么信息；從什么來源中搜集信息；用什么機制或技術搜集信息。再次，需求獲取的開始，代表着軟件項目正式開始實施，正所謂萬事開頭難。綜合上述 3 個點使得需求獲取成為軟件開發中最困難、最關鍵、最易出錯也是最需要交流的方面。在工作開展中，主要是就業務流程、組織架構、軟硬件環境和現有系統等相關內容進行溝通，挖掘系統最終用戶的真正需求，把握需求的方向。在需求獲取調研會中首先對需求獲取方法作了驗證。現行的需求獲
　　取方法一般有基於調查的需求獲取方法、基於用例的需求獲取方法、原型法等幾種方法。各種需求獲取方法各有利弊。[7]  

需求分析階段

需求分析與需求獲取是密切相關的，需求獲取是需求分析的基礎，需求分析是需求獲取的直接表現，兩者相互促進，相互制約。需求分析與需求獲取的不同主要在於需求分析是在已經了解承建方的實際的客觀的較全面的業務及相關信息的基礎上，結合軟、硬件實現方案，並做出初步的系統原型給承建方做演示。承建方則通過原型演示來體驗業務流程的合理化、准確性、易用性。同時，用戶還要通過原型演示及時地發現並提出其中存在的問題和改進意見和方法。

需求文檔編寫階段

需求開發的最終成果是，在對所要開發的產品達成共識后，所編寫的具體的文檔。需求文檔是在需求獲取和需求分析兩個階段任務結束時生成的，所以文檔要包含所有需求。在此階段先要從軟件工程和文檔管理的角度出發依據相關的標准審核需求文檔內容，確定需求文檔內容是否完整。對需求文檔中存留問題進行修改的工作。

需求確認階段

需求確認主要是針對《需求規格說明書》的評審，保證需求符合優秀需求成熟的特征，並且符合好的需求規格說明的特征。在需求確認階段需要保證以下幾點：
　　（1）軟件需求規格說明正確描述了預期的滿足各方涉眾需求的系統能力和特征。
　　（2）從系統需求、業務規則或其他來源中正確的推導出軟件需求。
　　（3）需求是完整的、高質量的。
　　（4）需求的表示在所有地方都是一致的。
　　（5）需求為繼續進行產品設計和構造提供充分的基礎。

需求跟蹤階段與需求復用階段

需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，確保產品依據需求文檔進行開發，建立與維護“需求——設計——編程——測試”之間的一致性，確保所有工作成果符合用戶需求。需求跟蹤是一項需要進行大量手工勞動的任務，在系統開發和維護的過程中一定要隨時對跟蹤聯系鏈信息進行更新。需求跟蹤能力的好壞會直接影響產品質量，降低維護成本，容易實現復用，同時，需求跟蹤還需要建設方的大力支持。

需求復用階段

在軟件項目實施過程中，許多不同項目間存在着許多相似的需求，尤其是類型相同的項目在不同的用戶群眾的實施中，需求的相似性就更加明顯、更加普遍了。有了需求復用，建設方就能快速的形成一個需求的原型，這樣，后期的需求工作只需要在此原型的基礎上進行修改、擴充和完善即可，大大提高了需求分析的工作進度。所以，對於需求的復用就需要加以重視。對於需求復用，首要責任就是要提取可復用的需求，對需求復用的理解和擴充。其次就是要保證需求復用不存在沖突。

需求變更控制階段

需求變更在軟件項目開發中是不可避免的。無休止的需求變更只會造成各種資源無休止的浪費，但是其中也不乏有許多是必要的、合理的需求變更。對於需求變更，首先是要盡量及早的發現，以避免更大的損失。其次，是要采取相應的、合理的變更管理制度和流程，這樣同樣可以降低需求變更帶來的風險。

版本控制階段

版本控制是管理需求規格說明和其他項目文檔必不可少的一個方面，也是需求變更文檔化管理的最有效辦法。可以詳細記錄發生需求變更的需求文檔版本的版本，發生變更的原因，變更發生的控制記錄，並對變更后的需求文檔進行唯一版本號的標識。使得每個成員都能及時訪問最新版本的需求文檔。

實施版本控制的基礎是需求基線，所謂需求基線就是項目組成員一經承諾將在某一特定產品版本中實現的功能性和非功能性需求的集合。需求基線的確定可以保證項目的涉眾各方可以對發布的產品中希望具有的功能和屬性有一個一致的理解。