一.概念
需求的定義包括從用戶角度(系統(tǒng)的外部行為)，及從研發(fā)者角度(一些內(nèi)部特性)來(lái)闡述需求。
關(guān)鍵的問(wèn)題是一定要編寫(xiě)需求文件。我原來(lái)目睹過(guò)一個(gè)項(xiàng)目中途更換了所有的研發(fā)者，客戶被迫和新的需求分析者坐到一起。系統(tǒng)的分析人員說(shuō)：“我們想和你談?wù)勀愕男枨??！笨蛻舻牡谝环磻?yīng)便是：“我已將我的需求都告訴你們前任了，目前我要的就是給我編一個(gè)系統(tǒng)”。而實(shí)際上，需求并未編寫(xiě)成文件，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會(huì)談?dòng)涗浕蛞恍┝闼榈奈凑淼膶?duì)話，你就確信你已明白用戶的需求，那完全是自欺欺人。
需求的另外一種定義認(rèn)為需求是“用戶所需要的并能觸發(fā)一個(gè)程式或系統(tǒng)研發(fā)工作的說(shuō)明”。有些需求分析專家拓展了這個(gè)概念：“從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點(diǎn)、功能及屬性等”。這些定義強(qiáng)調(diào)的是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設(shè)計(jì)、構(gòu)造的。而下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性：
需求是指明必須實(shí)現(xiàn)什么的規(guī)格說(shuō)明。他描述了系統(tǒng)的行為、特性或?qū)傩?，是在研發(fā)過(guò)程中對(duì)系統(tǒng)的約束。
從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒(méi)有一個(gè)清晰、毫無(wú)二義性的“需求”術(shù)語(yǔ)存在，真正的“需求”實(shí)際上在人們的腦海中，這個(gè)人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統(tǒng)分析人員根據(jù)用戶的自己語(yǔ)言的描述整理出相關(guān)的需要再進(jìn)一步和客戶核對(duì)。系統(tǒng)分析員和客戶需要確保所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識(shí)。
所有文件形式的需求(例如如下將要描述的需求規(guī)格說(shuō)明書(shū))僅是個(gè)模型，一種描述。
二.需求分析的任務(wù)
研發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明研發(fā)什么。最為困難的概念性工作便是編寫(xiě)出周詳技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其他軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò)，將最終會(huì)給系統(tǒng)帶來(lái)極大損害的部分，并且以后再對(duì)他進(jìn)行修改也極為困難。
目前，國(guó)內(nèi)產(chǎn)品的龐雜，一家企業(yè)可能有幾個(gè)系統(tǒng)并立運(yùn)行，他們之間接口是系統(tǒng)研發(fā)人員最頭痛的問(wèn)題。
對(duì)于商業(yè)最終用戶應(yīng)用程式，企業(yè)信息系統(tǒng)和軟件作為一個(gè)大系統(tǒng)的一部分的產(chǎn)品是顯而易見(jiàn)的。不過(guò)對(duì)于我們研發(fā)人員來(lái)說(shuō)，并沒(méi)有編寫(xiě)出客戶認(rèn)可的需求文件，我們?cè)趺粗理?xiàng)目于何時(shí)結(jié)束?而如果我們不知道什么對(duì)客戶來(lái)說(shuō)是重要的，那我們又怎么能使客戶感到滿意呢?
然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫(kù)、組件和工具這些供研發(fā)小組內(nèi)部使用的軟件。當(dāng)然你可能偶爾勿需文件說(shuō)明就能和其他人意見(jiàn)較為一致，但更常見(jiàn)的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價(jià)遠(yuǎn)遠(yuǎn)超過(guò)重寫(xiě)一份需求文件的代價(jià)，這些血的教訓(xùn)正在國(guó)內(nèi)的軟件研發(fā)者身上發(fā)生。
近來(lái)，我遇見(jiàn)一個(gè)研發(fā)小組研發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計(jì)算機(jī)輔助軟件。不幸的是，當(dāng)他們研發(fā)完這個(gè)工具后，發(fā)現(xiàn)這個(gè)工具不能打印出原始碼文件，使用者當(dāng)然希望有這個(gè)功能。結(jié)果這個(gè)小組只好手工抄寫(xiě)原始碼文件以供代碼檢查。這說(shuō)明那怕需求明確無(wú)誤并構(gòu)思準(zhǔn)確，如果我們沒(méi)有編寫(xiě)文件，軟件達(dá)不到期望目標(biāo)也只能是咎由自取了。
相反的情況，我曾見(jiàn)一個(gè)要集成到“錯(cuò)誤跟蹤系統(tǒng)”中的簡(jiǎn)單界面寫(xiě)了一頁(yè)需求說(shuō)明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時(shí)發(fā)現(xiàn)簡(jiǎn)單的一張需求清單竟是如此有用。他們依據(jù)需求對(duì)系統(tǒng)進(jìn)行測(cè)試時(shí)，此系統(tǒng)不僅非常清晰地實(shí)現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)所有錯(cuò)誤。
事實(shí)上，需求文件在研發(fā)過(guò)程中一直起指導(dǎo)作用。
三.需求分析過(guò)程
可把整個(gè)軟件需求工程研究領(lǐng)域劃分為需求研發(fā)和需求管理兩部分更合適
需