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

需求工程定義

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

1．用戶解決一個問題或達(dá)到某個目標(biāo)所需要的條件或能力。

2．一個系統(tǒng)必須滿足的條件或擁有的處理能力，或者一個能滿足一項合同、標(biāo)準(zhǔn)、規(guī)格說明或其他正式文檔的系統(tǒng)或系統(tǒng)組件。

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

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

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

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

需求的重要性

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

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

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

需求中面臨的問題

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

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

建設(shè)方領(lǐng)域知識的缺乏。

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

需求的描述問題。

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

需求理解的問題。

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

需求的完備程度問題。

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

需求的細(xì)致程度問題。

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

需求變更問題。

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

需求工程內(nèi)容及管理探討

需求獲取階段

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

需求分析階段

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

需求文檔編寫階段

需求開發(fā)的最終成果是，在對所要開發(fā)的產(chǎn)品達(dá)成共識后，所編寫的具體的文檔。需求文檔是在需求獲取和需求分析兩個階段任務(wù)結(jié)束時生成的，所以文檔要包含所有需求。

在此階段先要從軟件工程和文檔管理的角度出發(fā)依據(jù)相關(guān)的標(biāo)準(zhǔn)審核需求文檔內(nèi)容，確定需求文檔內(nèi)容是否完整。對需求文檔中存留問題進(jìn)行修改的工作。

需求確認(rèn)階段

需求確認(rèn)主要是針對《需求規(guī)格說明書》的評審，保證需求符合優(yōu)秀需求成熟的特征，并且符合好的需求規(guī)格說明的特征。在需求確認(rèn)階段需要保證以下幾點(diǎn)：

軟件需求規(guī)格說明正確描述了預(yù)期的滿足各方涉眾需求的系統(tǒng)能力和特征。

從系統(tǒng)需求、業(yè)務(wù)規(guī)則或其他來源中正確的推導(dǎo)出軟件需求。

需求是完整的、高質(zhì)量的。

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

需求為繼續(xù)進(jìn)行產(chǎn)品設(shè)計和構(gòu)造提供充分的基礎(chǔ)。

需求跟蹤階段與需求復(fù)用階段

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

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

某些可能的需求跟蹤聯(lián)系鏈

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

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

第四步，更新聯(lián)系鏈。在需求發(fā)生變動后一定要及時地更新聯(lián)系鏈。

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

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

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

(6) 需求復(fù)用階段

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

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

(7) 需求變更控制階段

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

(8) 版本控制階段

版本控制是管理需求規(guī)格說明和其他項目文檔必不可少的一個方面，也是需求變更文檔化管理的最有效辦法?？梢栽敿?xì)記錄發(fā)生需求變更的需求文檔版本的版本，發(fā)生變更的原因，變更發(fā)生的控制記錄，并對變更后的需求文檔進(jìn)行唯一版本號的標(biāo)識。使得每個成員都能及時訪問***版本的需求文檔。

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

結(jié) 論

需求工程是近幾年里提出的一個新概念，所謂需求工程就是所有與需求直接相關(guān)的活動。作為軟件工程的子領(lǐng)域，需求工程通過需求開發(fā)和需求管理兩個方面對需求工作進(jìn)行全面的管理。而其在整個項目中的重要性和決定性也越來越突出?？墒切枨蠊こ讨型瑯訒媾R諸多的問題，所以有了需求工程實施管理的系統(tǒng)方法外，引入對需求工程進(jìn)行監(jiān)督管理的機(jī)制大有必要。