在需求管理中常遇到三種情況：
(1)需求定義清晰，沒有異議性：
對于這種情況處理，我們一般要根據項目規模的大小進行同行專家評審，根據成本/效益之比，可以采用walkthouth或Inspection的方式來確定項目需求說明書；
對于需求的跟蹤，可以根據實際情況，采用需求跟蹤矩陣，主要目的是跟蹤相對應的Function需求在設計、編碼、測試階段是否有遺漏，其實并不是必須的，如果項目規模很小，或者可裁剪掉或者可以采用其他替代方式。
(2)項目需求有部分不明確：
我們一般都會采取分期實施的辦法，先進行需求明確的一期的需求合同的開發，如有重大變更，征得客戶同意后列入下期開發，這樣相對容易規避風險，否則項目永遠沒有完結的時候，質量也難以保證。
(3)項目需求基本上都是未知的：
這種項目風險最大，如果采用閉門造車，可能采用了很好的技術，結果卻找不到市場，造成投資血本無歸。一般而言，我們都采用原型Demo的方法，讓典型的客戶去參與原型的評審，不斷確認需求，形成需求基線。相信這種方法能有效緩解風險。
對于項目需求控制，一般都是采取與客戶協商的方式進行：
“客戶就是上帝”，是的，但并不表示客戶的所有需求都要馬上得到滿足，曾經看過一些公司，規模都很大，所做的項目都是全省推行的，一般人都會想，項目利潤是很大的。但是詢問起來，都是有苦難言，都說公司沒有真正賺到錢。后來一分析情況，發現項目估算時，軟硬件原來都是有較大利潤的，但最后都倒貼到后期的維護成本。根本原因公司為了爭取客戶，對于每個大客戶的需求都無條件滿足，定制化版本，每個地級市都有一個版本，可想而知，整個省就有二、三十個版本。前期開發是工作量不算太大，在原始版本上修修改改，多加點功能，當時客戶滿意度都很好，但一旦所有地方版本都上線了，麻煩就來了。單一個產品就要維護如此之多版本，維護成本可想而知，公司還要不要生存?公司發展就會因此而被拖累，甚至被市場淘汰。
針對這種情況，一般而言，都是采取與財政撥款的上級單位一起控制需求，統一版本。業內有些公司的做法是很好的，對于全省的項目，取得省相關部門的支持，和省公司一起共同分級規范全省需求提出(如根據重要性、緊急性分為ABCD類需求，每類需求成本是多少，一清二楚，而且也有計劃)，能有效地避免版本的頻繁變更，保證了項目質量，也大大地提升了客戶滿意度。
作者簡介
張勁：中大工學碩士，國家信息系統項目管理師、系統集成項目經理、高工，廣東軟件協會過程改進專家、希賽顧問團專家顧問，十多年軟件開發和項目管理經驗，其中八年以上的流程改進經驗，曾擔任多個優秀公司團隊的過程改進負責人，負責推進ISO/CMM/CMMI的認證評估及管理工作。
博客：http://blog.csai.cn/user1/35585/index.html
文章來源于領測軟件測試網 http://www.kjueaiud.com/