隨著時間的發展，需求已經開始為人們所重視，因此，需求已經提升到了一個新的高度——需求工程。作為軟件工程的子領域，需求工程的重要性和決定性越來越突出。需求中的一個不慎都有可能導致后續工作中的大量返工，甚至是項目的失敗。Robert Glass在其著作《Software Runaways》中評述到：“項目需求無疑是在軟件項目前期造成麻煩的一個***原因，一個又一個的研究已經發現，當項目失敗時，需求問題通常正是其核心問題。”

需求工程定義

既然需求工程如此重要，那么，什么才是需求工程呢？在IEEE標準610.12 – 1990軟件項目語境中將需求工程定義如下：

1．用戶解決一個問題或達到某個目標所需要的條件或能力。

2．一個系統必須滿足的條件或擁有的處理能力，或者一個能滿足一項合同、標準、規格說明或其他正式文檔的系統或系統組件。

3．前兩項中的一個條件或能力的文檔表示。

Abbot在他的著作An Integrated Approach to Software Development中將軟件需求定義為：“為了實現系統的目標，用戶需要且必須提供的符合或滿足的任何功能、限制或其他屬性”。

事實上，需求工程常被劃分為需求開發和需求管理兩部分，其中各部分包含四個子工程，如圖1-1所示。這八個子過程是順序遞進的，且是以一次次迭代的形式貫穿于軟件工程的整個生命周期之中的。

簡而言之，需求工程的目的就是定義所需解決的問題。凡用于收集、分析、文檔化、評審和管理軟件需求的良好工程原則的使用就可以稱作軟件需求工程。

需求的重要性

美國于1995年開始的一項調查的結果有力的證明了需求的重要性。在調查中，他們對全國范圍內的8000個軟件項目進行跟蹤調查，結果表明，有1/3的項目沒能完成，而在完成的2/3的項目中，又有1/2的項目沒有成功實施。他們仔細分析失敗的原因后發現，與需求過程相關的原因占了45%，而其中缺乏最終用戶的參與以及不完整的需求又是兩大首要原因，各占13%和12%。

需求工程是軟件工程中最復雜的一個部分。從人員角度講，要想做出***質的需求就離不開最終用戶的積極參與和設計人員對所涉及領域的了解，然而，這正是現階段最難解決的問題。用戶和設計人員不能完整、正確的了解對方領域的知識，加上溝通不充分，此外還有很多需求是隱性的，用戶都說不清楚自己的需求，這些就必然會導致需求中會存在問題。從一個客觀的角度講，需求又是一個非常空泛的事情，沒有人能夠準確且完整的說出針對一個項目的所有需求，這就從側面說明了，要想做出***的需求是不太可能的，需求中存在些許的遺漏是必然的。但是，作為開發人員來講之所以會在只有1%的希望的情況下也要用100%的心去盡力完成需求，是因為在軟件工程的一系列工程中，遺留的問題發現的越晚，所付出的成本就會越高，如圖所示。

圖：在各階段糾正一個錯誤的成本對比

需求中面臨的問題

需求是軟件生命周期中的***個階段，也是軟件工程中最重要的一個部分。但是，人們卻沒有像研究軟件工程一樣深入的研究需求。

軟件需求不同于其他行業中的需求那樣的明確、可描述、客觀、可驗證。軟件需求是模糊的、多變的、主觀的，正因如此軟件需求中才會存在如下的一些問題：

建設方領域知識的缺乏。

軟件已經開始涉及到各行各業中，然而建設方中承擔需求分析任務的分析人員大多是技術出身，而不是業務出身，他們的知識結構的重點是計算機。這種客觀存在的因素導致分析人員即使在需求方面擁有豐富的經驗，但是在許多項目中他們的知識仍然是不夠用的。所以在一個從未接觸過的領域里開展需求工作一定會面臨很大的困難和障礙。

需求的描述問題。

目前在開展需求工作中我國普遍存在的現象是用戶對需求描述不清。由于大多數用戶雖然精通業務，但是在提及需求時卻不知道應該提什么需求，或者說他們不知道什么才能算是需求，更甚者說他們對未來的目標系統僅僅只有一個模糊的概念。出于以上這些原因，想要出色完成需求工作是障礙重重。

需求理解的問題。

人和人的思維方式是不同的，因此對于用戶表達的需求，不同的開發人員可能會有不同的理解。如果真的誤解了用戶的需求，將會導致后續階段的開發方向的偏離。所以這個問題只有通過與用戶增加交流和日后的需求驗證加以解決。

需求的完備程度問題。

任何的完備都只是從一個相對的角度看待的，不存在絕對的完備。隨著系統范圍的擴大，要想窮舉需求幾乎是不可能的。因此，要想有一個相對完備的需求，只有先確定一個基線。

需求的細致程度問題。

對于這個問題，只能說是仁者見仁，智者見智，誰也下不清楚這個定義。而且，隨著需求時間的加長，變化也會隨之增多的。因此，在遵守需求工期的前提下盡量描述細致就可以了。

需求變更問題。

“需求的變化是永恒的”這句話想必是人人贊同的。當然，經常變更需求會給人力資源、經費以及項目進度帶來巨大的影響，但是變更是不可避免的，有時需求變更也并不一定就是壞事，及早及時的發生變更可以有效地更正原有需求中的錯誤。既然是不可避免，也就不必畏懼，只要相應的變更措施跟上了就可以做到坦然處之了。

需求工程內容及管理探討

需求獲取階段

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

需求分析階段

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

需求文檔編寫階段

需求開發的最終成果是，在對所要開發的產品達成共識后，所編寫的具體的文檔。需求文檔是在需求獲取和需求分析兩個階段任務結束時生成的，所以文檔要包含所有需求。

在此階段先要從軟件工程和文檔管理的角度出發依據相關的標準審核需求文檔內容，確定需求文檔內容是否完整。對需求文檔中存留問題進行修改的工作。

需求確認階段

需求確認主要是針對《需求規格說明書》的評審，保證需求符合優秀需求成熟的特征，并且符合好的需求規格說明的特征。在需求確認階段需要保證以下幾點：

軟件需求規格說明正確描述了預期的滿足各方涉眾需求的系統能力和特征。

從系統需求、業務規則或其他來源中正確的推導出軟件需求。

需求是完整的、高質量的。

需求的表示在所有地方都是一致的。

需求為繼續進行產品設計和構造提供充分的基礎。

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

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

需求跟蹤的***步是要選擇一個適于本項目的聯系鏈，如圖4-1所示。只有建立了明確的聯系鏈才可以了解各需求之間的父子關系、相互連接和依賴關系。

某些可能的需求跟蹤聯系鏈

第二步，選擇跟蹤矩陣類型。跟蹤矩陣分為單矩陣和多矩陣。兩種矩陣都可以明確地顯示一個需求的相關聯系，而作為多矩陣的好處就是可以追溯到一個需求的特定用例，而且，便于自動工具的支持。

第三步，根據項目中各部分的重要性，有選擇性的進行部分的跟蹤。

第四步，更新聯系鏈。在需求發生變動后一定要及時地更新聯系鏈。

第五步，確定聯系鏈的信息提供人員，以及管理人員。

第六步，要定期審查跟蹤信息，以確保信息***。

需求跟蹤的工作，首先是要保障需求跟蹤管理工作在每次出現需求變更時都要及時進行，避免出現工作結束后在重新創建。其次要注意需求跟蹤鏈和需求跟蹤矩陣建立是否正確、合理、科學。并且要通過審查方式檢查跟蹤數據的完整和準確。待確立了需求跟蹤矩陣后，依據矩陣中各需求間的關系檢查是否每個底層的需求是否都能夠向上找到一個高層的需求，并且在查找的同時還要再次檢查每個需求是否都是有唯一的標識。

(6) 需求復用階段

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

對于需求復用，首要責任就是要提取可復用的需求，對需求復用的理解和擴充。其次就是要保證需求復用不存在沖突。

(7) 需求變更控制階段

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

(8) 版本控制階段

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

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

結 論

需求工程是近幾年里提出的一個新概念，所謂需求工程就是所有與需求直接相關的活動。作為軟件工程的子領域，需求工程通過需求開發和需求管理兩個方面對需求工作進行全面的管理。而其在整個項目中的重要性和決定性也越來越突出。可是需求工程中同樣會面臨諸多的問題，所以有了需求工程實施管理的系統方法外，引入對需求工程進行監督管理的機制大有必要。