需求分析是對用戶需求的真正明確，是對要解決的問題的徹底理解。在解決問題之前要理解問題，只有真正的理解問題才能更好的解決問題。需求分析就是給系統分析、設計人員一個和用戶交流來理解問題的機會—了解用戶究竟需要什么。
需求分析也是一個建模的過程，與在概要設計中建模不同在需求分析中建模是面向用戶的過程。而在概要設計中的建模過程是面向開發人員的過程。這樣兩種建模的過程就會存在差異和不同，從而使用自然語言進行描述也就不同。在傳統的軟件工程中并不建議大量的使用自然語言對軟件的需求進行描述，因為太多的自然語言會引發出很多問題。比如說，二義性即不同的人對自然語言的描述會有不同的理解，就是再好的文檔編寫人員也不會保證他的文檔不存在二義性。畢竟我們不是語言學家。這樣就引入了借用圖示進行功能的描述和建模的過程。圖示有其自己的優勢比如，清晰，明確給人直觀的感覺。無論是何種背景的人群都可以理解。這樣就大大減少需求分析中的二義性。從而使系統設計人員和用戶更加有效的溝通。這樣也增加了軟件的正確性。在傳統的軟件工程中提供了多種不同的圖示，每一種都從不同的角度對同一個問題進行描述，之所以這樣�？梢允瓜到y開發人員在不同的圖示中挑出最適合他和他的團隊進行問題詳盡描述的一個或者一些圖示。比如數據流圖，在需求分析中使用數據流圖，就充分體現了數據在軟件系統中移動時被變換的邏輯過程。所以就是一個建立功能模型的最好圖示；而實體關系圖，就是描述數據對象以及他們之間關系的圖示，所以就是一個建立數據模型的最好例子。狀態轉換圖通過事件的外部作用從而對狀態進行改變，這就是一個建立行為模型的例子。
在我做需求分析時，盡量做到問題闡述明確�？墒且恢庇幸粋�問題困擾著我，就是應該選擇什么樣的圖例進行系統的描述是，數據流圖，狀態轉換圖還是實體關系圖？其實不同系統設計人員給出的答案不會是一樣的。這并不是一個哲學問題而是一個應用問題。從客戶的角度出發使用實體關系圖是最好的選擇，而數據流圖完全就是為系統設計人員量身定做的一樣。因為程序員更關心事物內部的邏輯性和相關性；而用戶只關心事物的外部表征和特性。所以問題的答案只有每個人自己去尋找，尋找一個最能體現用戶需求和問題解決方案的圖示。
在按照模版進行需求分析撰寫的時候，我發現有很多模版條目的要求是在需求分析的最初階段是無法給出確切的答案的。有的條目要經過概要設計，詳細設計之后才能對文檔內容進行修改和填充。同時我對其他同行撰寫的需求分析文檔進行研究發現，一個優秀的需求分析說明說并不是按照規定模版條目不變的照搬。其實有些冗余的項目完全可以不必關心。畢竟撰寫需求分析的真正目的，是讓系統設計人員知道用戶的需求。其他的不必過多強求。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/