● 必須與需求工程的其它活動緊密整合
談需求管理一定不能脫離需求工程。從完整意義上講，需求工程包括了需求獲取、需求分析、需求描述、需求驗證、需求管理。狹義上，需求管理關心的是需求管理過程的建立，在企業或項目組中需要有一套規范的需求管理過程。而實際上從項目經理的角度上看，可能還有50%甚至更多的精力是用于關注結果的，所以對需求內容的管理與對需求形式的管理是密不可分的。
● 需求必須是文檔化的、正確的、最新的、可管理的、可理解的
需求必須有文檔來記錄，該文檔必須是正確的，是經過驗證的，是在受控的狀態下變更的。而很多開發人員往往會問：“簡單的系統就不用寫需求了吧？”其實簡單的系統未必簡單，只有想清楚、寫清楚、說清楚才說明已經真正把需求整理清楚了。有一次，筆者安排2名開發人員編寫一個簡單的單據錄入模塊。由于這兩名開發人員以前均做過類似的系統，所以筆者僅給出了數據庫的設計，并簡單講了一下模塊的需求。然而，當系統交付時，才發現與想象中的系統差距非常大，很多需求在提出者看來是理所當然的，卻被開發人員全部忽略了。
● 只要需求變化了，需求變更的影響就必須被評估
無論需求變化的程度如何，只要需求變化了就必須進行評估，這是基本的原則。此外，在一個項目組中必須明確定義一個需求管理員，由他負責整個項目的需求管理工作，確保在發生需求變更時，受影響的產品能得到修改并與需求的變更保持一致，受影響的其它組也必須與客戶協商一致。
● 需求必須分優先級 需求的優先級可能比需求本身更加重要
在每一次產品開發過程中，都會遇到這樣一個問題：負責產品需求的領域專家羅列了長長的功能列表，每個功能似乎都是不可或缺的，而當排出進度表后，卻發現工期是公司不能接受的，沒辦法，必須裁剪需求。沒有需求就不會有產品，而沒有產品就沒有利潤。如果需求過多，反而可能是陷阱——只有投入，沒有產出。一個好的項目需求，必須有需求的優先級，便于進行項目的整體平衡。
● 需求一定要分類管理
在做工程項目的時候一定要將需求分出層次，不同層次的需求側重點是不一樣的，描述的方式是不同的，管理的方式也是不同的。比如說，在企業里高層領導提出來的是目標性需求，中層管理人員提出來的是具體的業務流程的需求，而作業人員提出來的是更側重于操作性的需求。對于目標性的需求可能采用簡短的幾句話就可以描述清楚，但這是項目的決策性需求，需要很穩定，不能輕易更改，在確定的時候需要慎之又慎
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
