的產品。從這層意義上說，需求管理是產品質量的基礎。
需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。
需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。
需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產品依據(jù)需求文檔進行開發(fā)。
需求變更控制是指依據(jù)“變更申請-審批-更改-重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發(fā)生混亂。
根據(jù)上面描述的具體方法及步驟，由于需求分析的參與人員、業(yè)務模式、投資、時間等客觀因素的影響和需求本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛在的風險，應引起項目相關干系人的注意。這些風險主要表現(xiàn)如下：
1）用戶不能正確表達自身的需求。在實際開發(fā)過程中，常常碰到用戶對自己真正的需求并不是十分明確的情況，他們認為計算機是萬能的，只要簡單的說說自己想干什么就是把需求說明白了，而對業(yè)務的規(guī)則、工作流程卻不愿多談，也講不清楚。這種情況往往會增加需求分析工作難度，分析人員需要花費更多的時間和精力與用戶交流，幫助他們梳理思路，搞清用戶的真實需求。從另一方面來看，他們對于計算機的理解肯定不是很到位，而我們如何引導，正確梳理出正確的需求就需要先從工作業(yè)務流程出發(fā)，而不是先從計算機方面來考慮問題。
2）業(yè)務人員配合力度不夠。有的用戶日常工作繁忙，他們不愿意付出更多的時間和精力向分析人員講解業(yè)務，這樣會加大分析人員的工作難度和工作量，也可能導致因業(yè)務需求不足而使系統(tǒng)無法使用。針對此類問題我們一般的做法是在項目開始階段先確定好一個與客戶溝通過的需求調研計劃，當然這樣還是經(jīng)常會有變動，但相對來講從責任上來講，客戶也會有一定的壓力，因為如果不配合可能會導致系統(tǒng)進度的延誤，其實這也不是客戶希望看到的。
3）用戶需求的不斷變更。由于需求識別不全、業(yè)務發(fā)生變化、需求本身錯誤、需求不清楚等原因，需求在項目的整個生命周期都可能發(fā)生變化，因此，我們要認識到，軟件開發(fā)的過程實際上是同變化做斗爭的過程，需求變化是每個開發(fā)人員、項目管理人員都會遇到的問題，也是最頭痛的問題，一旦發(fā)生了需求變化，就不得不修改設計、重寫代碼、修改測試用例、調整項目計劃等等，需求的變化就像是萬惡之源，為項目的正常的進展帶來不盡的麻煩。針對這類需求變更的問題，個人認為是影響進度的最大的敵人，目前我們的做法是每次根據(jù)客戶的需求整理出一個書面的文件，由客戶簽字確認。當然這里還有一個很重要的問題就是不是每個需求都是必須做的，我們要學習如何拒絕客戶。
4）需求的完整程度。需求如何做到?jīng)]有遺漏？這是一個大問題，大的系統(tǒng)要想窮舉需求幾乎是不可能的，即使小的系統(tǒng)，新的需求也總會不時地冒出來。一個系統(tǒng)很難確定明確的范圍并把所有需求一次性提出來，這會導致開發(fā)人員在項目進展中去不斷完善需求，先建立系統(tǒng)結構再完成需求說明，造成返工的可能性很大，會給開發(fā)人員帶來挫折感，降低他們完成項目的信心。
5）需求的細化程度。需求到底描述到多細，才算可以結束了？雖然國家標準有需求說明的編寫規(guī)范，但具體到某一個需求上，很難給出一個具體的指標，可謂仁者見仁，智者見智，并沒有定論。需求越細，周期越長，可能的變化越多，對設計的限制越嚴格，對需求的共性提取要求也越高，相反，需求越粗，開發(fā)人員在技術設計時不清楚的地方就越多，影響技術設計。
6）需求描述的多義性。需求描述的多義性一方面是指不同讀者對需求說明產生了不同的理