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