項目需求分析

微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接受程度，在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟體設計打下基礎。需求分析階段結束后，要求得到：1.SRS文檔(System Requirement Specification); 2.DRM 文檔；3.Acceptance Plan. 從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。狹義上理解：需求分析是指需求的分析、定義過程。

需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力，財力，時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的.(相信大家都有體會)比如，用戶需要一個for linux的軟體，而你在軟體開發前期忽略了軟體的運行環境，忘了向用戶詢問這個問題，而想當然地認為是開發for windows的軟體，當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。

需求分析之所以重要，就因為他具有決策性，方向性，策略性的作用，他在軟體開發的過程中具有舉足輕重的地位。大家一定要對需求分析具有足夠的重視。在一個大型軟體系統的開發中，他的作用要遠遠大於程序設計。

簡言之，需求分析的任務就是解決"做什麼"的問題，就是要全面地理解用戶的各項要求，並準確地表達所接受的用戶需求。

需求分析階段的工作，可以分為四個方面：問題識別,分析與綜合,制訂規格說明，評審。

問題識別

就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼),性能需求(要達到什麼指標),環境需求(如機型，操作系統等),可靠性需求(不發生故障的概率）,安全保密需求，用戶界面需求，資源使用需求(軟體運行時所需的內存,CPU等),軟體成本消耗與開發進度需求，預先估計以後系統可能達到的目標。

分析與綜合

逐步細化所有的軟體功能，找出系統各元素間的聯繫，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後，綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。

制訂規格說明書

即編製文檔，描述需求的文檔稱為軟體需求規格說明書。請注意，需求分析階段的成果是需求規格說明書(好像軟考曾經考過這個問題),向下一階段提交。

評審

對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作，否則重新進行需求分析。

需求分析的方法有很多。這裡只強調原型化方法，其它的方法如:結構化方法,動態分析法等(個人認為，對初學者不必深究這些方法，實際上我也從來沒用過這些方法)在此不討論。

原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本，它實現了目標系統的某些或全部功能。

原型化方法就是儘可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能，但是這個系統可能在可靠性，界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如演演算法的可行性，技術的可行性，或考察是否滿足用戶的需求等。如，為了考察是否滿足用戶的要求，可以用某些軟體工具快速地建造一個原型系統,這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。

原型主要有三種類型(軟考考過):探索型，實驗型，進化型。探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。

在使用原型化方法是有兩種不同的策略：廢棄策略，追加策略。廢棄策略：先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反覆進行修改，形成比較好的思想，據此設計出較完整，準確，一致，可靠的最終系統。系統構造完成後，原來的模型系統就被廢棄不用。探索型和實驗型屬於這種策略。

追加策略：先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心，然後通過不斷地擴充修改，逐步追加新要求，發展成為最終系統。進化型屬於這種策略。