所謂“需求分析”，是指對要解決的問題進行詳細的分析，明確問題的需求，包括需要輸入什麽數據，要得到什麽結果，最後要輸出什麽。可以說“需求分析”就是確定妳希望計算機做什麽。
需求分析是指了解用戶需求，與客戶就軟件功能達成壹致，估計軟件風險和評估項目成本，最終形成開發計劃的復雜過程。在這個過程中，用戶確實處於主導地位。需求分析工程師和項目經理要負責整理用戶需求，為後續的軟件設計打下基礎。需求分析階段後，要求獲得:1。SRS文檔(系統需求規格)；2.DRM文檔；3.驗收計劃。
從廣義上講，需求分析包括需求獲取、分析、規格說明、變更、驗證和管理等壹系列需求項目。
狹義的需求分析是指需求分析和定義的過程。
壹、為什麽需要需求分析？
需求分析就是分析軟件用戶的需求是什麽。如果投入了大量的人力、物力、財力、時間，但是開發出來的軟件沒人要，那麽所有的投入就白費了。如果妳花了很大的精力去開發壹個軟件，但是最後不符合用戶的要求，妳就要重新開發。這種返工讓人心痛。(相信大家都知道)比如用戶需要壹個linux的軟件。在軟件開發的前期，妳忽略了軟件的運行環境，忘了問用戶這個問題，想當然的認為妳是在為windows開發軟件。當妳辛辛苦苦開發出來，提交給用戶的時候，妳發現不對勁了。那時候妳想哭，找不到壹塊豆腐就死了。
需求分析之所以重要，是因為它起著決定性、方向性和戰略性的作用，在軟件開發過程中起著重要的作用。每個人都必須足夠重視需求分析。在大型軟件系統的開發中，它的作用遠遠大於編程。
二、需求分析的任務
簡而言之，需求分析的任務是解決“怎麽辦”的問題，即充分理解用戶的需求，準確表達已接受的用戶需求。
三、需求分析的過程
需求分析階段的工作可以分為四個方面:問題識別、分析綜合、規格制定和評估。
問題識別
它是從系統的角度來理解軟件，為開發的系統確定綜合需求，提出這些需求的實現條件和需求應滿足的標準。這些需求包括:功能需求(做什麽)、性能需求(達到什麽指標)、環境需求(如型號、操作系統等。)、可靠性要求(故障概率)、安全性要求、用戶界面要求和資源使用要求(軟件操作是
分析與綜合
逐步細化所有的軟件功能，找出系統的要素、接口特性和設計限制之間的關系，分析是否滿足要求，剔除不合理的部分，增加需要的部分。最後綜合系統解決方案，給出待開發系統的詳細邏輯模型(做什麽)。
制定規格
也就是說，描述需求的文檔稱為軟件需求說明書。請註意，需求分析階段的結果是需求說明書(看來是軟考通過了這個問題)，提交到下壹個階段。
評價
評估功能和其他要求的正確性、完整性和清晰性。通過評估後才能進行下壹階段的工作，否則將重新進行需求分析。
四、需求分析的方法
需求分析的方法有很多。這裏只強調原型法，其他方法，如結構法、動態分析法(個人認為初學者沒必要去鉆研這些方法，事實上我也沒用過)，這裏不討論。
原型法很重要(是軟測試等常見知識點)。原型是軟件的早期運行版本，實現目標系統的部分或全部功能。
原型法是盡快構建壹個粗糙的系統，實現目標系統的部分或全部功能，但這個系統可能在可靠性、界面友好性或其他方面存在缺陷。構建這樣壹個系統的目的是考察某壹方面的可行性，比如算法的可行性，技術的可行性，或者是否符合用戶的需求等等。比如為了考察是否符合用戶的要求，可以用壹些軟件工具快速搭建壹個原型系統，只是壹個界面，然後聽取用戶意見，完善原型。未來的目標系統將在原型系統的基礎上開發。
原型主要有三種類型(通過了軟測試):探索型、實驗型和進化型。探索性:目的是找出對目標系統的要求，確定期望的特性，探索各種方案的可行性。實驗性:在用於大規模開發實現之前，需要檢查方案是否合適，規範是否可靠。進化式:目的不是改進規範，而是讓系統易於更改，改進原型。
使用原型法有兩種不同的策略:丟棄策略和附加策略。放棄策略:先建立壹個功能簡單、質量要求不高的模型系統，反復修改形成壹個比較好的思路，然後設計壹個比較完整、準確、壹致、可靠的最終系統。系統構建完成後，原有的模型系統將被丟棄。探索性和實驗性模型屬於這種策略。
附加策略:先構建壹個功能簡單、質量要求低的模型系統，作為最終系統的核心，然後通過不斷的擴展和修改，逐步添加新的需求，發展成為最終系統。進化型屬於這種策略。
五、需求分析的20條規則
客戶需要好的方法與開發者交流。這裏有20條規則，客戶和開發人員可以通過查看以下內容來達成理解。在意見不壹致的情況下，通過協商達成對各自義務的相互理解，以減少以後的摩擦(比如壹方提出要求，另壹方不願意或不能滿足要求)。
1.分析師應該使用符合客戶語言習慣的表達方式。
需求討論集中在業務需求和任務上，所以要使用術語。客戶要教分析師相關術語(比如采購價格、印刷商品等采購術語)，但客戶不壹定要知道計算機行業的術語。
2、分析師要了解客戶的業務和目標。
只有分析師對客戶的業務有了更好的了解，產品才能更好的滿足需求。這將有助於開發人員設計出真正滿足客戶需求和期望的優秀軟件。為了幫助開發人員和分析師，客戶可以考慮邀請他們觀察自己的工作流程。如果切換到新系統，開發人員和分析師應該使用當前的舊系統來幫助他們了解當前系統的工作方式、流程以及可以改進的地方。
3、分析師必須撰寫軟件需求報告。
分析師應該整理從客戶那裏獲得的所有信息，以區分業務需求和規範、功能需求、質量目標、解決方案和其他信息。通過這些分析，客戶可以得到壹份“需求分析報告”，使開發者和客戶就要開發的產品內容達成壹致。報告應以客戶認為易於閱讀和理解的方式組織和編寫。客戶應審閱此報告，以確保報告的內容準確、完整地表達了他們的需求。高質量的“需求分析報告”有助於開發人員開發出他們真正需要的產品。
4.要求對所需工作的結果進行解釋。
分析師可能會使用各種圖表作為對文本化的“需求分析報告”的補充說明，因為工作圖可以清晰地描述系統行為的某些方面，所以報告中的圖表具有很大的價值；雖然它們並不太難理解，但客戶可能並不熟悉，因此客戶可以要求分析師解釋每個圖表的功能、符號的含義和需求開發工作的結果，以及如何檢查圖表中是否存在錯誤和不壹致。
5.開發商應該尊重客戶的意見。
如果用戶和開發人員不能互相理解，需求的討論就會有障礙。* * *合作才能讓大家“聽得進去”。參與需求開發過程的客戶有權要求開發人員尊重他們，珍惜他們為項目成功所花費的時間。同樣，客戶也應該尊重開發人員為項目成功的相同目標所做的努力。
6.開發人員要對需求和產品實現提出建議和解決方案。
通常情況下，客戶所說的“需求”是壹個切實可行的實施方案。分析師要盡量從這些解決方案中了解真實的業務需求，同時要找出現有系統與當前業務的不壹致之處，確保產品不會失效或低效。在徹底了解業務領域的東西後，分析師可以提出相當好的改進方法，有經驗有創意的分析師也可以提出增加壹些用戶沒有發現的有價值的系統特性。
7.描述產品的使用特性
客戶可以在實現功能需求的同時，要求分析師關註軟件的易用性，因為這些易用的特性或質量屬性可以使客戶更準確、更高效地完成任務。例如，客戶有時要求產品“用戶友好”或“健壯”或“高效”，但對於開發者來說，這太主觀了，沒有實用價值。正確的做法是分析師通過詢問和調查，了解客戶想要的“友好、健壯、高效”的具體特征，具體分析哪些特征對哪些特征有負面影響，並在提出的解決方案的性能成本和預期收益之間做出權衡，以確保做出合理的選擇。
8.允許重用現有的軟件組件。
需求通常是靈活的，分析師可能會發現現有的軟件組件符合客戶描述的需求。在這種情況下，分析師應該提供壹些修改需求的選項，以便開發人員可以降低新系統的開發成本和節省時間，而不必嚴格遵循原始需求。所以，如果妳想在產品中使用壹些現有的商用組件，而它們又不完全適合妳所需要的特性，那麽壹定程度的需求靈活性是極其重要的。
9.需要對變更的成本進行真實可靠的評估。
有時候，當面對更好更貴的解決方案時，人們會做出不同的選擇。這時候就需要評估需求變化的影響來幫助商業決策。因此，客戶有權要求開發商通過分析給出真實可信的評價，包括影響、成本、得失等。開發人員不能因為不想實現變更而任意誇大評估成本。
10，得到壹個滿足客戶功能和質量要求的系統。
每個人都希望項目成功，但這不僅需要客戶清楚地告訴開發人員系統做什麽的所有信息，還需要開發人員通過溝通清楚地了解權衡和限制，必須清楚地說明妳的假設和潛在期望，否則，開發人員開發的產品可能不會讓妳滿意。
11.向分析師解釋妳的業務。
分析師依靠客戶解釋業務概念和術語，但客戶不能指望分析師成為這方面的專家，只能讓他們理解妳的問題和目標；不要指望分析師能抓住客戶業務的微妙潛力。他們可能不知道客戶認為理所當然的“常識”。
12，抓緊時間講清楚，完善要求。
客戶很忙，但無論如何，客戶都有必要抽出時間參加“大腦峰會”討論、訪談或其他活動來獲取需求。有些分析師可能會先理解妳的觀點，後來發現他們需要妳的解釋。在細化需求的過程中，請耐心對待壹些需求和重復，因為這是人與人交流中的自然現象，對軟件產品的成功極其重要。
13.準確詳細地解釋需求。
很難寫出清晰準確的需求文檔。因為處理細節既煩人又費時，很容易留下模糊的需求。但是在開發的過程中，我們必須解決這種模糊性和不準確性，而客戶是做出決定解決這些問題的最佳人選，否則，我們就不得不依賴於開發人員的正確猜測。
這是在需求分析中臨時添加“待定”標誌的壹種方法。使用此標誌表示需要進壹步討論、分析或信息的地方，有時可能會標記為“待定”，因為某個特殊要求很難解決或沒有人願意處理它。客戶應該盡量明確每個需求的內容，以便分析師準確地將它們寫入“軟件需求報告”。如果客戶壹時無法準確表達，通常需要使用原型技術。通過原型開發，客戶可以和開發人員反復修改，不斷完善需求的定義。
14，及時做決定
分析師會要求客戶做出壹些選擇和決策，包括多個用戶提出的處理方法或者在質量特性沖突和信息準確性之間選擇壹個折中方案。有決定權的客戶壹定要積極的對待這壹切，盡快處理，做出決定，因為開發人員通常要等客戶做出決定後才能行動，這種等待會耽誤項目的進度。
15.尊重開發商的需求、可行性和成本評估
所有的軟件功能都有其成本。有些客戶想要的產品特性可能在技術上不可行，或者實現起來需要很大的成本，而有些需求試圖達到在運行環境下不可能達到的性能，或者試圖得到壹些根本得不到的數據。開發者會對此做出負面評價，客戶要尊重他們的意見。
16.區分需求的優先級
大多數項目沒有足夠的時間或資源來實現功能的每個細節。決定哪些特性是必要的，哪些是重要的，這是需求開發的主要部分，只能由客戶來設定，因為開發人員不可能根據客戶的觀點來決定需求優先級；開發人員將提供關於每個需求的成本和風險的信息，供您進行優先級排序。在時間和資源的限制下，是否能完成或能完成多少所需的功能，應該尊重開發人員的意見。雖然沒有人願意看到自己想要的要求在項目中沒有實現，但畢竟要面對現實。商業決策有時不得不縮小項目範圍或延長建設周期，增加資源，或根據優先級在質量上找到壹個折中方案。
17，審查需求文檔和原型
客戶評審需求文檔是向分析師提供反饋信息的機會。如果客戶認為“需求分析報告”不夠準確，就要盡快通知分析師，並提供改進建議。更好的方法是先為產品開發壹個原型。這樣，客戶可以給開發者提供更有價值的反饋信息，讓他們更好地了解妳的需求；原型並不是實際應用產品，但開發者可以將其轉化和擴展為功能齊全的系統。
18.如果需求發生變化，請立即聯系。
不斷的需求變化會給預定計劃內完成的優質產品帶來嚴重的不利影響。變化是不可避免的，但在開發周期中，變化出現的越晚，其影響越大；變更不僅會導致成本高昂的返工，還會延誤工期，尤其是在壹般結構完成後需要添加新功能時。因此，壹旦客戶發現有必要更改需求，請立即通知分析師。
19.遵循開發團隊處理需求變更的流程。
為了將變更的負面影響降至最低，所有參與者都必須遵循項目變更控制流程。這就需要不放棄所有提出的變更，對每壹個需要的變更進行分析和綜合考慮，最後做出適當的決策，確定哪些變更應該引入到項目中。
20.尊重開發人員采用的需求分析過程。
軟件開發最具挑戰性的是收集需求並確定其正確性，分析師采用的方法是合理的。也許客戶認為收集需求的過程不劃算，但是請相信，花在需求開發上的時間是非常寶貴的；如果您理解並支持分析師收集和編寫需求文檔所使用的技術，並確保其質量，整個過程將會更加順利。
“需求確認”是什麽意思？
簽署“需求分析報告”通常被認為是客戶同意需求分析的標誌。然而，在實踐中，客戶往往認為“簽字”是沒有意義的。“他們讓我在需求文檔的最後壹行下面簽名，我就簽了，否則這些開發人員不會開始編碼。”
這種態度會帶來麻煩。比如當客戶想改變需求或者對產品不滿意的時候，他們會說:“是的，我簽了需求分析報告，但是我沒來得及看完所有的內容。我相信妳，但妳讓我簽了。”
同樣的問題也會發生在只把“簽字確認”當成完成任務的分析師身上。壹旦有需求變更，他就指著《需求分析報告》說:“妳已經在需求上簽字了，所以這些就是我們開發的。如果妳想要別的，妳應該早點告訴我們。”
這兩種態度都是錯誤的。因為不可能在項目前期就知道所有的需求，而且毫無疑問需求會發生變化，所以在“需求分析報告”上簽字是終止需求分析過程的正確方式，所以壹定要明白簽字是什麽意思。
“需求分析報告”的簽名是基於壹個需求協議的基線，我們應該這樣理解簽名:“我同意這個需求文檔表達了我們對項目的軟件需求的理解，在這個基線上可以通過項目定義的變更過程進行進壹步的變更。我知道這種變化可能會導致我們重新協商成本、資源和項目任務等問題。”對需求分析達成壹定的理解，會讓雙方容易容忍未來的摩擦，這些摩擦來自於項目的改進和需求的錯誤或者市場和業務的新要求。需求確認驅散了迷霧，揭示了需求的真實面目，為最初的需求開發工作畫上了清晰的句號，有助於客戶和開發人員之間形成持續良好的關系，為項目的成功打下堅實的基礎。
第六，評論需求分析的誤區
如果要說什麽是好的需求分析，不如說什麽是壞的需求分析。知道什麽是不好的，自然就知道什麽是好的。以下是壹些糟糕的情況:
(1)創意與現實
毫無疑問，每個人都會對他們的新想法感到非常興奮，尤其是當這個想法被壹些不知道妳要做什麽的人稱贊的時候。但是請註意，當妳興奮的時候，妳可能忘記了妳最初是在描述壹個需求，而不是在策劃壹個想法或者創造壹個概念。很多剛開始做需求分析的人，或多或少都會犯這樣的錯誤，陶醉於自己的新思想新觀點，卻違背了需求本來的客觀性和真實性原則。
永遠不要忘記:需求不是空中樓閣，而是實實在在的壹磚壹瓦。
(2)解剖的樂趣
幾乎所有搞軟件的人，在做需求分析的時候，用戶的需求壹上來就會告訴妳，做壹個完整的解剖，切成幾個塊，再細分成幾個子塊，然後詳細分析。但是，當用戶不解，看著妳辛辛苦苦做出來的分析結果，問妳:我想做壹個數據備份任務，怎麽做？這時，妳會發現妳需要打開三個窗口才能完成這個任務。
千萬不要忘記:分解是必須的，但最終目的是為了更好的組合，而不是為了分解。
(3)角度和思維
經常聽到這樣的抱怨:“用戶怎麽能提出這麽苛刻的要求？”。仔細壹看，妳會發現用戶只是想把壹個需要兩次點擊的功能改成只需要壹次點擊。這會導致需要修改需求，修改編碼，甚至重新測試，增加工作量。但是，如果換個角度想，這個功能雖然只開發了幾次或者幾十次，但是用戶每天都要使用幾百次甚至幾千次或者幾萬次。如果我們改變它，工作量將減少壹半。這個要求對他來說會不會很苛刻？
千萬不要忘記:沒有需求是錯的，只有妳的需求分析是錯的。盡量站在用戶的角度去思考，妳的需求分析會更貼近用戶，更合理。軟件要以人為本。
(4)程序員邏輯
從程序員成長為系統分析師是常見的軌跡，但不是好的程序員就壹定能成為好的系統分析師。壹些程序員固化的邏輯，使得他們在做需求分析的時候經常會陷入壹些死角。比如1/0邏輯(或者黑白邏輯)被認為非此即彼，沒有第三種情況。但實際情況往往是，有的時候是這樣，有的時候是那樣。另壹個例子是窮舉邏輯。喜歡的話，把123種可能的情況全部列出來，然後逐壹處理，每種占三分之壹的時間；但實際情況往往是三分之壹的情況占99%，另外兩種情況壹年也不會發生壹次。實踐中這樣的例子很多，我就不壹壹列舉了。
千萬別忘了:需求分析和程序設計是不壹樣的，合理性和可行性最重要。走出編程的圈子，站在系統的角度看問題，妳的結論會完全不同。