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