的描述，為設計階段劃定范圍，不應該包含不確性因素在里面，要么做，要么不做，不能遺留任何待解決的問題，而且還要保證需求的完整性。
4、 對優(yōu)先級的排列，任何需求在整理過程中都要分優(yōu)先級，即問題的重要程度，解決時的優(yōu)先順序，需求收集過程中會匯總大量的客戶需求，在這些需求當中，有些是客戶急需解決的，有些是起錦上添花作用的，這時就需要分析人員結合軟件的現狀，根據問題的急緩，來劃分一下將來處理問題的優(yōu)先順序，也是為設計和開發(fā)階段的相關人員提供可參照的依據。
三、 需求的評審
在我們看來需求的評審是軟件需求分析的最后一步，將整理好的需求規(guī)格進行評審，最終決定下一步如何執(zhí)行，需求的評審一般由專業(yè)人士來完成，主要包括公司的內部專家及外部專家，公司內部一般包括分析設計人員、各部門開發(fā)經理、維護經理、項目經理及資深開發(fā)人員；外部專家包括典型客戶代表、實施人員代表等，評審的目的主要就軟件需求規(guī)格中定義的各事項做進一步討論，根據評審過程中各專家提出的問題再作整理、修改，最終確定需求的狀態(tài)。評審過程中常見的問題有以下幾方面：
1、 需求的評審流于形式，需求的評審是最后的把關階段，有時會遇到這種情況：需求規(guī)格編寫完成后，在評審的過程中只是簡單的走一遍，或者評審過程中討論激烈，評審后該干么干么，沒有事后監(jiān)督與執(zhí)行，感覺這一點是導致后續(xù)軟件不急定的主要原因。
2、 對評審人員的要求要嚴格，不是任何人都可以參與評審的，人多了反而效果不好，參與人員應主要是與需求密切相關的，能對需求能提出改進建議的專家，而不是隨便找?guī)讉€人完事。
3、 沒有典型客戶參與，需求的整個過程最好讓具有代表性的客戶參與進來，哪怕客戶不明白自己真正的想要實現的東西是什么，但在整個過程中客戶自始至終起到指導作用，軟件是個比較抽象的東西，客戶不會多過的關注開發(fā)的過程，舉個例子：如果你跟客戶討論的是在建工程或大型設備的安裝，那么客戶肯定會重點關注很多細節(jié)，提出很多建議，因為客戶明白項目完工后再改造帶來的影響，但對于軟件，作為客戶他考慮不到軟件開發(fā)完成后，后期變更所帶來的麻煩，所以在討論需求時比較馬虎，描述不清楚需求，導致開發(fā)者開發(fā)出的軟件與客戶的期望存在巨大差異。
4、 用戶需求不斷的增加，這也是最常見的問題之一，在需求評審的過程中，往往評審人員根據討論的結果會提出新的需求，會導致不斷的更改，所以在編寫需求規(guī)格的時候要把握一個度，不是任何需求都要列入。
5、 對需求做全面的檢查，從需求的幾個特性去綜合考慮，如：需求的完整性、正確性、無二義性、可驗證性等。
作為客戶如果得到的最終軟件產品不能滿足某項功能，就會讓開發(fā)人員修改，雖然開發(fā)人員后期不管費多大力氣最終能修改完客戶的需求，客戶感覺是理所當然的事情，但作為開發(fā)人員來講，如果程序開發(fā)完成后再去修改，也是一件很頭疼的事，因為要放下手頭的工作，優(yōu)先去處理客戶的問題。這一切的問題都是由于在需求的收集或驗證的過程的疏忽造成的。
需求驗證的最終結果是得到一個完整、正確、可執(zhí)并且無二義性的需求規(guī)格，這樣才可為后續(xù)工作提供保障，在整個軟件生命周期中，一個錯誤發(fā)現的越晚，修復錯誤的費用越高，軟件需求分析階段可以說是發(fā)現錯誤的階段，可見其重要性，需求分析階段看似沒有明確的目標，實則不然，這期間對任何問題的疏忽，都會導致系統(tǒng)問題呈扇形擴張，估計做過需求分析的同行都能認識其重要性。任何形式的需求規(guī)格說明書都不能保證完全沒有錯誤和缺陷，我們在編寫的過程中只能盡量按照軟件工程的規(guī)范去執(zhí)行，盡量避免問題的發(fā)生。