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