在項目管理中，需求的重要性是眾所周知的，在IT業(yè)界的研究是：高達60%缺陷來源于需求不清晰，超過80%的項目維護成本用于需求問題處理，需求管理影響了整個項目成敗，而關鍵項目成敗則影響了公司的生存。
在需求管理中常遇到三種情況：
(1)需求定義清晰，沒有異議性：
對于這種情況處理，我們一般要根據(jù)項目規(guī)模的大小進行同行專家評審，根據(jù)成本/效益之比，可以采用walkthouth或Inspection的方式來確定項目需求說明書；
對于需求的跟蹤，可以根據(jù)實際情況，采用需求跟蹤矩陣，主要目的是跟蹤相對應的Function需求在設計、編碼、測試階段是否有遺漏，其實并不是必須的，如果項目規(guī)模很小，或者可裁剪掉或者可以采用其他替代方式。
(2)項目需求有部分不明確：
我們一般都會采取分期實施的辦法，先進行需求明確的一期的需求合同的開發(fā)，如有重大變更，征得客戶同意后列入下期開發(fā)，這樣相對容易規(guī)避風險，否則項目永遠沒有完結的時候，質量也難以保證。
(3)項目需求基本上都是未知的：
這種項目風險最大，如果采用閉門造車，可能采用了很好的技術，結果卻找不到市場，造成投資血本無歸。一般而言，我們都采用原型Demo的方法，讓典型的客戶去參與原型的評審，不斷確認需求，形成需求基線。相信這種方法能有效緩解風險。
對于項目需求控制，一般都是采取與客戶協(xié)商的方式進行：
“客戶就是上帝”，是的，但并不表示客戶的所有需求都要馬上得到滿足，曾經(jīng)看過一些公司，規(guī)模都很大，所做的項目都是全省推行的，一般人都會想，項目利潤是很大的。但是詢問起來，都是有苦難言，都說公司沒有真正賺到錢。后來一分析情況，發(fā)現(xiàn)項目估算時，軟硬件原來都是有較大利潤的，但最后都倒貼到后期的維護成本。根本原因公司為了爭取客戶，對于每個大客戶的需求都無條件滿足，定制化版本，每個地級市都有一個版本，可想而知，整個省就有二、三十個版本。前期開發(fā)是工作量不算太大，在原始版本上修修改改，多加點功能，當時客戶滿意度都很好，但一旦所有地方版本都上線了，麻煩就來了。單一個產品就要維護如此之多版本，維護成本可想而知，公司還要不要生存?公司發(fā)展就會因此而被拖累，甚至被市場淘汰。
針對這種情況，一般而言，都是采取與財政撥款的上級單位一起控制需求，統(tǒng)一版本。業(yè)內有些公司的做法是很好的，對于全省的項目，取得省相關部門的支持，和省公司一起共同分級規(guī)范全省需求提出(如根據(jù)重要性、緊急性分為ABCD類需求，每類需求成本是多少，一清二楚，而且也有計劃)，能有效地避免版本的頻繁變更，保證了項目質量，也大大地提升了客戶滿意度。