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

需求工程定義

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

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

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

3．前兩項(xiàng)中的一個(gè)條件或能力的文檔表示。

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

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

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

需求的重要性

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

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

圖：在各階段糾正一個(gè)錯(cuò)誤的成本對(duì)比

需求中面臨的問(wèn)題

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

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

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

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

需求的描述問(wèn)題。

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

需求理解的問(wèn)題。

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

需求的完備程度問(wèn)題。

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

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

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

需求變更問(wèn)題。

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

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

需求獲取階段

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

需求分析階段

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

需求文檔編寫階段

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

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

需求確認(rèn)階段

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(7) 需求變更控制階段

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

(8) 版本控制階段

版本控制是管理需求規(guī)格說(shuō)明和其他項(xiàng)目文檔必不可少的一個(gè)方面，也是需求變更文檔化管理的最有效辦法。可以詳細(xì)記錄發(fā)生需求變更的需求文檔版本的版本，發(fā)生變更的原因，變更發(fā)生的控制記錄，并對(duì)變更后的需求文檔進(jìn)行唯一版本號(hào)的標(biāo)識(shí)。使得每個(gè)成員都能及時(shí)訪問(wèn)***版本的需求文檔。

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

結(jié) 論

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