求管理錯誤和調整 
　　Standish Group1995年發(fā)布的Chaos Report中，73%的項目都由于不充分的需求定義與分析而被取消或者以失敗告終。同樣Sequent Computer Systems1997年的一份研究表明，接受調查的500為IT經(jīng)理中的76%在他們的職業(yè)生涯中都經(jīng)歷過失敗的項目，而大部分的失敗歸結于不斷改變的用戶需求。在需求管理過程中，對需求定義的不準確、對用戶提出需求的誤解和傳遞錯誤、對非功能性需求的忽略都會造成需求管理的失敗，進而導致整個項目的失敗。 
需求的定義不準確
　　在計算機有句術語：“垃圾進，垃圾出”（Garbage in, garbage out），從項目一開始，就要有正確的輸入，也就是正確的用戶需求。在整個軟件研發(fā)過程中，保持整個團隊對需求的關注、確保所有開發(fā)活動都可以跟蹤到最初的用戶需求無疑是極為關鍵的。 
　　在一個系統(tǒng)執(zhí)行項目中，業(yè)務客戶提供了對項目的要求，由于項目組對需求定義的不準確，造成項目最后以失敗告終。
　　這個項目的最初范圍是開發(fā)一個用于微軟Access數(shù)據(jù)庫應用程序的模擬工具?？蛻粝胍獙θ藗冞M行訓練，使其使用web網(wǎng)頁，以取代依賴Access應用程序的本地復制。供應商遵循高水平需求管理，并開展類似于30＋Access screens的基于萬維網(wǎng)的應用程序。商業(yè)客戶也沒有很快注意后臺的運算工作和在不同模塊之間數(shù)據(jù)的流動情況。  
　　供應商根據(jù)項目建議書提出了項目需求，把封裝的MS-Access數(shù)據(jù)庫轉換成基于網(wǎng)頁的訓練模擬。由于需求沒有正確定義，供應商認為顧客唯一需要的是數(shù)據(jù)的輸入復制。他們想把任何商業(yè)合理性包括在最終產(chǎn)品中。對給出需求的進一步分析之后，供應商最后確定商業(yè)用戶希望得到的項目需求是，運行在基于網(wǎng)頁中的Access應用程序，這與客戶要求完全不同。 
　　在整個項目的需求管理中，雖然客戶把自己業(yè)務需求提的比較明確，但是由于項目組起初對需求定義的不準確，因此在項目實施過程中整個項目發(fā)生了很大的變更。供應商成本超支明顯，并且需要追加資金才能維系項目，但是整個項目是固定總價合同，項目難以維系，最終被取消了。 
對需求的不當傳達和翻譯 
　　在整個世界全球化和外包的發(fā)展，在進行需求開發(fā)的過程中，語言的障礙需要被理解和克服。對需求不當?shù)慕忉寱е虏缓玫慕鉀Q方案。在以前的一個財務報表項目中，業(yè)務需求包括開發(fā)一個報表，這個報表在貨幣符號和財務價值之間的有一個空格。 
業(yè)務客戶希望得到使用這種格式的報表： 
$ 100,000.00
可是,開發(fā)團隊把"開發(fā)報表，在貨幣符號和財務價值之間有一個空格"解釋為： 
$space100,000.00 
　　需求正確地被定義；可是，解釋引起缺陷。如果起初的需求被提供一個簡單的格式，溝通的偏差可以被避免。這個世界可能是平的，但是傳遞解釋偏差仍然可以發(fā)生，盡管現(xiàn)在服務和技術是全球性的。 
　　溝通失敗的另一個例子不是在信息的編碼和解碼中，但是在需求傳輸?shù)倪^程中。一個項目上，客戶需要在每一份報表上都包括公司的logo商標。客戶沒有一份具有公司商標的電子圖文件和簡單的通用報表傳真。外包供應商從傳真上掃描商標變成一個圖形格式并包含在報表中。
　　但是在用戶進行驗收測試中，每份報表上都顯示了公司的商標，但是那個商標傾斜了30度。當那客戶傳真商標時、傳真機器圖象輕微的發(fā)生了變形。幸好,用戶驗收測試發(fā)現(xiàn)了偏差；可是,供應商堅持他們符合需求。 
不良的或遺漏無功能的需求
　　有時需求管理的失敗并非是

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

    http://www.vanceur.cn/pmqhd/index.html