程中，必須得解決這種模糊性和不準確性。而你恰是為解決這些問題作出決定的最佳人選。不然的話，你就只好靠開發(fā)人員去正確猜測了。在需求規(guī)格說明中暫時加上待定（to be determined, TBD也可采用漢語拼音略寫“DQD：待確定”）的標志是個不錯的辦法。用該標志可指明了哪些需要進一步探討、分析或增加信息的地方。不過，有時也可能因為某個特殊需求難以解決或沒有人愿意處理它而注上TBD標志。盡量將每項需求的內容都闡述清楚，以便分析人員能準確的將其寫進軟件需求規(guī)格說明中。如果你一時不能準確表述，那就得允許獲取必要的準確信息這樣一個過程。通常使用所謂的原型技術。通過開發(fā)的原型，你可以同開發(fā)人員一起反復修改，不斷完善需求定義。
4：及時地作出決定
    正如一位建筑師為你修建房屋，分析人員將要求你做出一些選擇和決定。這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息準確度中選擇折衷方案等。有權做出決定的客戶必須積極地對待這一切，盡快做處理、做決定。因為開發(fā)人員通常只有等你做出了決定才能行動，而這種等待會延誤項目的進展。
5：尊重開發(fā)人員的需求可行性及成本評估
    所有的軟件功能都有其成本價格，開發(fā)人員最適合預算這些成本（盡管許多開發(fā)人員并不擅長評估預測）。你所希望的某些產品特性可能在技術上行不通，或者實現(xiàn)它要付出極為高昂的代價。而某些需求試圖在操作環(huán)境中要求不可能達到的性能或試圖得到一些根本得不到的數(shù)據(jù)，開發(fā)人員會對此作出負面的評價意見，你應該尊重他們的意見。有時，你可以重新給出一個在技術上可行、實現(xiàn)上便宜的需求，例如，要求某個行為在“瞬間”發(fā)生是不可行的，但換種更具體的時間需求說法（“在50ms以內”,但若沒有準確的技術分析不能輕易下結論），這就可以實現(xiàn)了。
6： 劃分需求優(yōu)先級別
    大多數(shù)項目沒有足夠的時間或資源來實現(xiàn)功能性的每個細節(jié)。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發(fā)的主要部分。只能由你來負責設定需求優(yōu)先級，因為開發(fā)者并不可能按你的觀點決定需求優(yōu)先級。開發(fā)者將為你確定優(yōu)先級提供有關每個需求的花費和風險的信息。當你設定優(yōu)先級時，你幫助開發(fā)者確保在適當?shù)臅r間內用最小的開支取得最好的效果。在時間和資源限制下，關于所需特性能否完成或完成多少應該尊重開發(fā)人員的意見。盡管沒有人愿意看到自己所希望的需求在項目中未被實現(xiàn)，但畢竟是要面對這種現(xiàn)實的。業(yè)務決策有時不得不依據(jù)優(yōu)先級來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。
7：評審需求文檔和原型
    正如我們將在第1 4章討論的，無論是正式的還是非正式的方式，對需求文檔進行評審都會對軟件質量提高有所幫助。讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性。評審也給客戶代表提供一個機會，給需求分析人員帶來反饋信息以改進他們的工作。如果你認為編寫的需求文檔不夠準確，就有義務盡早告訴分析人員并為改進提供建議。通過閱讀需求規(guī)格說明，很難想象實際的軟件是什么樣子的。更好的方法是先為產品開發(fā)一個原型。這樣你就能提供更有價值的反饋信息給開發(fā)人員，幫助他們更好地理解你的需求。必須認識到：原型并非是一個實際產品，但開發(fā)人員能將其轉變、擴充成功能齊全的系統(tǒng)。
8：需求出現(xiàn)變更要馬上聯(lián)系
    不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響。變更是不可避免的，但在開發(fā)周期中變更越在晚期出現(xiàn)，其影響越大。變更不僅會導致代價極高的返工，而且工期也會被迫延誤，特別是在大體結構已完成后又需要增加新特性時。所以一旦你發(fā)現(xiàn)需要變更需求時，請一定立即通知分析人員。
9：應遵照開發(fā)組織處理需求變更的過

    項目經理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html