需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發(fā)計劃的一個復(fù)雜過程。從廣義上理解：需求分析包括需求的獲取、分析、規(guī)格說明、變更、驗證、管理的一系列需求工程。狹義上理解：需求分析指需求的分析、定義過程。要想說什么是好的需求分析，不如說什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。以下就是一些不好的情況：
（１）創(chuàng)意和求實
毋庸質(zhì)疑的，每個人都會為自己的一個新的idea而激動萬分，特別是當這個idea受到一些根本不知道你原本要干嘛的人的驚贊時。但是請注意，當你激動得意的時候，你可能已經(jīng)忘了你原本是在描述一個需求，而不是在策劃一個創(chuàng)意、創(chuàng)造一個概念。很多剛開始做需求分析的人員都或多或少的會犯這樣的錯誤，陶醉在自己的新想法和新思路中，卻違背了需求的原始客觀性和真實性原則。
永遠別忘了：需求不是空中樓閣，是實實在在的一磚一瓦。
（２）解剖的快感
幾乎所有搞軟件的人，做需求分析的時候，一上來就會把用戶告訴你的要求，完完整整的作個解剖，切開分成幾個塊，再細分成幾個子塊，然后再條分縷析?？墒钱斢脩裘曰蟮目粗阈列量嗫嘧龀鰜淼姆治鼋Y(jié)果問你：我想作一個數(shù)據(jù)備份的任務(wù)，怎么做？這時，你會發(fā)現(xiàn)，需要先后打開三個窗口才能完成這個任務(wù)。
永遠別忘了：分解是必需的，但最終的目的是為了更好的組合，而不是為了分解。
（3）程序員邏輯
從程序員成長為系統(tǒng)分析員是一個普遍的軌跡，但并不是一個好的程序員就必然能成為一個好的系統(tǒng)分析員。一些程序員的固化邏輯，使得他們在做需求分析的時候往往鉆進了一些牛角里面。比如說１／０邏輯（或者是說黑白邏輯），認為不是這樣就是那樣，沒有第三種情況。可實際情況往往是，在一定的時候是這樣，其它時候是那樣。又比如窮舉邏輯，喜歡上來就把所有一二三可能的情況列舉出來，然后一個一個分別處理，每個占用三分之一的時間；可是實際的情況往往是，三分之一的情況占了９９％的比例，其它兩種情況一年都不會遇到一次。實際中還有很多這樣的例子，不一一列舉了。
永遠別忘了：需求分析和程序設(shè)計不盡相同，合理、可行是才是重要的。跳出程序設(shè)計的圈子，站在系統(tǒng)的角度上來看問題，你的結(jié)論會截然不同。
（4）角度和思維
經(jīng)常聽到這樣的抱怨：“用戶怎么可以提出這樣苛刻的要求呢？”。細細一了解，你會發(fā)現(xiàn)，用戶只不過是要求把一個需要兩次點擊的功能，改成只有一次點擊。這樣會導(dǎo)致需要改變需求、改變編碼、甚至重新測試，增加工作量?？墒牵绻麚Q個角度來想想，這個功能，開發(fā)的時候只用了幾次、幾十次，可是用戶每天都要用幾百次甚 至幾千次幾萬次，改動一下就減少了一半的工作量，對他來說，這樣的需求難道會苛刻嗎？
永遠別忘了：沒有任何需求是不對的，不對的只是你的需求分析。試著站在用戶的思維角度想想，你的需求分析就會更加的貼近用戶，更加的合理。軟件應(yīng)該是以人為本的。