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