在軟體開發過程中，需求分析是最開始的工作，需求分析如果做得不夠詳細或者是偏離使用者需求的話，往往會給專案帶來滅絕性的災難。因此如何保證需求分析的正確性，不偏離使用者的需求就成了決定軟體專案成敗的關鍵。
需求工程師取得使用者的顯性需求後，要仔細的分析使用者到底要求軟體實現什麼功能，使用者的表達和需求工程師的理解有時間並不會一致，這樣會導致使用者所想的和需 求說明書上所描述的有偏差。並且需求工程師取得使用者的需求後必須做仔細透徹的分析，有時候使用者的需求並不一定正確，可能是使用者忽然的想法，並不可行。如果 需求工程師不能對使用者提出的需求進行判斷的話，可能辛辛苦苦的實現了使用者需求，結果被使用者自己否決掉。使用者絕對不會將責任攬到自己身上，他們只會說「你們 是專家，怎麼能怪我呢？」。
網上有一幅漫畫形象地描述了資訊在傳遞過程中產生的誤差。
需求分析師是專案中直接與客戶接觸的人，需求做的好不好決定專案成敗，因此對於需求規格說明書的正確性必須進行徹底的驗證，將錯誤在開工前就消滅。
通常有兩種手段來檢查需求的正確性，分別是需求評審和需求測試。
1、 需求評審
需求評審可以分為正式評審與非正式評審，在需求規格說明書完成後，需求組必須自己對需求做評審。如果需求組遞交的需求規格說明書在指導後面的工作的時候出 現很明顯的錯誤，我想拿高工資的需求分析人員是無法向老闆交差的。為了需求分析人員的名譽，他們自己會對自己提交的內容進行審核，直到他們認為自己的工作 成果足夠好，才會將需求規格說明書提交給正式評審組。
正式評審組的成員一般由公司內經驗最豐富，技術最牛的人（技術總監）來擔任，當然參加評審的人中間還應該有專案經理、qa人員、測試人員、架構師，他們仔細閱讀需求規格說明書，並針對自己將要開展的工作內容進行檢查，並提出問題
正式評審是最後一關，如果正式評審通過了，將進入系統設計階段，如果在系統設計階段再跨里程碑來修改需求的話，所花費的代價將大大增加。因此正式評審將是乙個「雞蛋裡挑骨頭」的過程，只有所有的人都認為需求已經沒有什麼可挑剔評審才能通過。
2、 需求測試
可以認為需求評審也屬於需求測試範圍，但是這裡提的需求測試和評審不同，它是測部門來測試需求是否符合使用者的要求。顯然這是有難度的，傳統的測試工作都是 從單元測試開始，編碼之前全部做得都是計畫性工作。測試人員對需求分析進行測試？那麼前提條件是測試人員必須熟悉需求分析，這對測試人員的要求提高了。將 需求測試人員作為測試人員中的特殊種類來培養，能夠對需求是否正確進行檢查，這樣就能夠在需求階段就引入測試。當然需求測試人員可以是經過培訓的需求分析 人員，但是他必須脫離需求組，加入測試部門，這樣才能保證測試不是自己人測自己，以保證測試的效果。
需求測試不等同於後面階段整合測試或者系統測試，後面的測試都是軟體已經編寫完成的條件下，判斷軟體是否會出錯。而需求測試，只是驗證需求是否真的是使用者 的。對於需求的功能測試，可以用rad工具建立介面原型，使用者通過原型的操作來確定是否需求跟他的期望相同。對於那些使用者不合理的需求，測試人員要能夠分 辨出來，並跟使用者進行核對，確定使用者的真實需求。可以說需求測試是需求測試人員和使用者共同來執行的。
之所以將需求測試和需求評審並行進行，是因為需求評審是專案的各方干係人共同進行的檢查工作，評審工作關注的焦點是分散的，很難將偏離使用者的需求檢查出 來，並且涉及的人很多，因此不可能耗費太長時間。而需求測試執行的時間可以比評審時間長，有專門的關注方面，能夠檢查出不合理的需求分析，在專案前期進行 錯誤糾正，往往比實現後糾正要節約幾百甚至幾千倍的成本。
測試驅動需求分析 需求文件評審例項
需求文件評審例項 軟體的開發文件質量一般只能通過評審來進行保證，如何有效發現文件中的問題，是乙個令許多人頭疼的問題。先看一段關於日誌檔案的需求描述如下 軟體要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間 訪問結束時間 訪問者的 ip位址這三個資訊作為一條日誌記錄。要求以天為單位每天生成乙...
測試驅動需求分析 需求文件評審例項
需求文件評審例項 軟體的開發文件質量一般只能通過評審來進行保證，如何有效發現文件中的問題，是乙個令許多人頭疼的問題。先看一段關於日誌檔案的需求描述如下 軟體要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間 訪問結束時間 訪問者的 ip位址這三個資訊作為一條日誌記錄。要求以天為單位每天生成乙...
測試驅動需求分析 需求文件評審例項
需求文件評審例項 軟體的開發文件質量一般只能通過評審來進行保證，如何有效發現文件中的問題，是乙個令許多人頭疼的問題。先看一段關於日誌檔案的需求描述如下 軟體要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間 訪問結束時間 訪問者的 ip位址這三個資訊作為一條日誌記錄。要求以天為單位每天生成乙...