需求工程

需求工程是指套用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特徵和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。

基本介紹

• 中文名：需求工程
• 外文名：Requirement engineering

概念

需求工程是指套用已證實有效的原理 、方法 , 通過合適的工具和記號 ,系統地描述待開發系統及其行為特徵和相關約束 。需求工程覆蓋了體系結構設計之 前的各項開發活動 , 主要包括分析客戶要求、對未來系統的各項功性 及非功能性需求進行規格說明 , 並針對不同的對象可分為系統需求工程 (如果是針對由軟硬體共同組成的整個系統 )和軟體需求工程(如 果僅是 專門針對 純 軟體部分 )。 在系統開發中 , 需求工程往往與體系結構設計交替進行 ,直到分解的子問題可以單純地由軟體或硬體系統解決 。軟體需求工程則是對套用於純 軟體系統開發生命期中系統設計之前的第 一 階段 。因此 , 需求工程的目標相當簡單明了 : 確定客戶需 求 , 定義構想中系統的所有外部特徵 。

發展

隨著軟體工程技術的發展 ,需求工程越來越引起人們的關注。特別是當今“面向服務”的軟體工程時代 ,需求工程占據空前重要的位置。 充分了解需求工程的發展歷程對於把握其發展方向大有裨益。下表給出了需求工程發展的幾個重要階段。

年代	主要模型	主要技術	受……影響	當前狀態
1970-1980	軟體需求工程方法學	控制流或程式流程圖	面向過程的程式語言	已退出歷史舞台
1970-1990	結構化分析	數據流圖	業務過程	已經不再重要
1990-至今	面向對象分析	類、對象、順序圖、用例圖等	面向對象的設計和程式語言	當前的工業標準
2004-至今	面向服務分析	工作流、服務和面向服務架構( SO A)	SO A架構: . Net、Wb服務、 IBMSOA基礎架構	逐漸形成

需求工程方法

需求工程是一個不斷反覆的需求定義、文檔記錄、需求演進的過程 ,並最終在驗證的基礎上完成需求規
范。為了提高目標軟體需求規格的質量 ,需求工程提出了以下幾種方法。

結構化需求抽取方法

需求工程支持結構化的需求抽取過程 ,為需求的抽取過程提供構型未來系統的理念 ,提供需求抽取的線索、需求描述的框架和需求抽取方法論 ,明確指出需求抽取過程中所涉及的有關問題及其正確的處理方法 ,從而保證抽取過程的質量 ,並提供系統化、工程化的指南和有效的支持工具 ,使得需求信息的無二義性、完整性和一致性。

系統化的需求建模方法

需求工程支持系統化的需求建模過程和途徑 ,為軟體需求模型提供預定義的語義解釋和預定義的語義約束 ,支持需求提供者和系統開發者從語義上正確地理解所獲得需求信息的含義 ,使得需求提供者可以正確地判斷當前已提供的需求信息是否真正表達了他們自己的意圖 ,也使得系統開發者可以了解自己對需求提供者所提供需求信息的理解程度。 軟體項目成功的關鍵是開發者真正理解並在軟體中正確地表達用戶的意圖。

形式化的需求驗證技術

形式化的驗證技術是在形式化需求模型基礎之上進一步保證需求信息正確性的手段。 它採用精確的數學語言來表達需求模型 ,並藉助於數學推導的手段 ,使得需求模型中含糊的、不完整的、矛盾的以及無法實現的表述能夠被準確地發現 ,從而儘早得到糾正。形式化需求驗證技術一般分為 3類 ,分別是代數方法、基於模型的方法和基於進程代數的方法 ,它們分別適用於描述和分析不同類型的軟體系統。 形式化需求驗證技術的作用分為兩個方面: 一方面是驗證需求提供者的意圖可滿足性 (即需求模型的有效性 ) ;另一方面是驗證需求模型的可實現性 (即需求模型的正確性 ) ,這一點使得形式化需求驗證技術和一般的形式化方法得以區別開來。形式化需求驗證的意義在於: 如果方法被正確使用的話 ,對於特定的語義是有充分定義的。

階段

綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：

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

需求工程作用

需求工程的作用主要表現在: 增強了項目涉眾對複雜產品特徵在細節和相互依賴關係上的理解， 增強了項目涉眾對需求( 尤其是複雜需求) 的掌握; 增進了項目涉眾之間的交流， 減少了可能的誤解和交流偏差; 需求管理能夠更加有效地處理需求變更，提高了生產效率; 需求跟蹤信息能夠更加準確地反映項目的進展情況，以便進行更好的項目決策; 使得項目涉眾認識到需求在項目工作中的重要性， 使得需求的作用得到重視和有效發揮。良好的需求分析和管理工作， 才能把系統的功能描述和性能指標轉化為具體的軟體需求規格說明書，成為系統建設的依據和基礎。

需求工程內容

需求獲取階段

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

需求分析階段

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

文檔編寫階段

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

需求確認階段

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

需求跟蹤階段

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

需求復用階段

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

變更控制階段

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

版本控制階段

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

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