需求分析是對使用者需求的真正明確，是對要解決的問題的徹底理解。在解決問題之前要理解問題，只有真正的理解問題才能更好的解決問題。需求分析就是給系統分析、設計人員乙個和使用者交流來理解問題的機會—了解使用者究竟需要什麼。
需求分析也是乙個建模的過程，與在概要設計中建模不同在需求分析中建模是面向使用者的過程。而在概要設計中的建模過程是面向開發人員的過程。這樣兩種建模的過程就會存在差異和不同，從而使用自然語言進行描述也就不同。在傳統的軟體工程中並不建議大量的使用自然語言對軟體的需求進行描述，因為太多的自然語言會引發出很多問題。比如說，二義性即不同的人對自然語言的描述會有不同的理解，就是再好的文件編寫人員也不會保證他的文件不存在二義性。畢竟我們不是語言學家。這樣就引入了借用圖示進行功能的描述和建模的過程。圖示有其自己的優勢比如，清晰，明確給人直觀的感覺。無論是何種背景的人群都可以理解。這樣就大大減少需求分析中的二義性。從而使系統設計人員和使用者更加有效的溝通。這樣也增加了軟體的正確性。在傳統的軟體工程中提供了多種不同的圖示，每一種都從不同的角度對同乙個問題進行描述，之所以這樣。可以使系統開發人員在不同的圖示中挑出最適合他和他的團隊進行問題詳盡描述的乙個或者一些圖示。比如資料流圖，在需求分析中使用資料流圖，就充分體現了資料在軟體系統中移動時被變換的邏輯過程。所以就是乙個建立功能模型的最好圖示；而實體關係圖，就是描述資料物件以及他們之間關係的圖示，所以就是乙個建立資料模型的最好例子。狀態轉換圖通過事件的外部作用從而對狀態進行改變，這就是乙個建立行為模型的例子。
在我做需求分析時，盡量做到問題闡述明確。可是一直有乙個問題困擾著我，就是應該選擇什麼樣的圖例進行系統的描述是，資料流圖，狀態轉換圖還是實體關係圖？其實不同系統設計人員給出的答案不會是一樣的。這並不是乙個哲學問題而是乙個應用問題。從客戶的角度出發使用實體關係圖是最好的選擇，而資料流圖完全就是為系統設計人員量身定做的一樣。因為程式設計師更關心事物內部的邏輯性和相關性；而使用者只關心事物的外部表徵和特性。所以問題的答案只有每個人自己去尋找，尋找乙個最能體現使用者需求和問題解決方案的圖示。
在按照模版進行需求分析撰寫的時候，我發現有很多模版條目的要求是在需求分析的最初階段是無法給出確切的答案的。有的條目要經過概要設計，詳細設計之後才能對文件內容進行修改和填充。同時我對其他同行撰寫的需求分析文件進行研究發現，乙個優秀的需求分析說明說並不是按照規定模版條目不變的照搬。其實有些冗餘的專案完全可以不必關心。畢竟撰寫需求分析的真正目的，是讓系統設計人員知道使用者的需求。其他的不必過多強求。
需求分析 什麼是需求分析？
需求分析學習目錄 乙個使用者解決乙個問題或實現乙個目標所需的條件或能力 為了滿足乙個合同 標準 規範 或其它正是文件要求，乙個系統或系統構件必須具備或擁有的條件或能力。所有的需求共同形成系統或構件開發的基礎 一種反應1 2所描述的條件或能力的文件說明。在本人所上的軟體需求分析課程中，乙個軟體需求是指...
什麼是需求
需求就好比買衣服，客戶未必能很完整地 清晰地認識或知道他們需要什麼。而我們需要通過客戶給我們的資訊，把這些資訊整理，再反饋給客戶看，反覆確定客戶是否確定該需求，經過一番需求在理解 業務的 能夠指出 需求那些地方需要修改，改善，最後能夠給出一套解決方案，碟這建立在了解業務 規則，業務常識，清楚使用者到...
什麼是測試需求
究竟什麼是測試需求 早上，剛開啟電腦，看到一封德高望重的大姐給我發來一封郵件，詢問什麼是 測試需求 以及測試需求和軟體需求之間有什麼聯絡和區別。責任重大，立即行動起來，不能讓大姐失望啊。wikipedia 找，無論中文還是英文，都沒有對測試需求做定義。接著，我用 谷歌搜尋了一通，發現了幾篇文章，話題...