需求變更的代價
一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間、人力、資源等等方面。
變更都是有代價的，應該評估一下變更的代價和對專案的影響，在評估代價並且與客戶討論的過程中，要讓客戶了解變更的後果，變更之後面臨最大的問題就是專案延期，讓客戶一起做判斷：「我可以修改，但您能接受後果嗎？」。現在會出現三種可能：客戶接受延期這一後果，開發人員按客戶要求做出相應修改，讓客戶知道為此需要付出延期的代價；如果客戶認為代價太大，那開發人員就不必修改了，可以記錄下需求，待到下一版本再做修改；客戶不接受變更的代價，導致專案夭折。如果客戶不知道你為變更付出的代價，對你的辛苦便難以體會，以致沒完沒了的提出新的變更。
減少需求變更
正如前文所說，需求變更往往是不可避免的。通常是專案負責人員花費了大量的氣力避免需求變更，可最後需求變更總是會出現。但是這並不意味著專案開發人員不應該做這方面的工作，專案開發人員對於需求變更的正確態度應該和軟體測試的態度一樣，在需求變更發生之前儘量減少需求變更，以將需求變更帶來的風險降低到最低。專案開發人員切忌在專案設計之前試圖消除需求變更，這樣做往往費力不討好。
相比於需求開發人員而言，客戶可能對需求變更認識不足，認為他們出錢，程式設計師或軟體開發公司就要為它服務，因此客戶對需求變更往往更加肆無忌彈，將需求變更視為兒戲，隨個人喜好隨意變更需求。因此，在需求人員同使用者代表或使用者部門主管人員接觸時，就應該向他們挑明態度，和他們協商好，特別是應該讓他們清楚軟體的定價應該與軟體的功能相關，以及需求隨意變更所帶來的風險的承擔者應該由客戶和專案開發者共同承擔。通過這樣做，讓客戶在需求分析之前就盡量對他們所需要的功能有個整體的了解和確定的思路，而不是等到程式設計師開始編碼了，才提出以前原本在需求分析時就可以提出的需求。
讓客戶明白減少需求變更的重要性後，需求分析人員應該採取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關係不應該僅僅是記錄人員和需求提供者，他們的關係應該更多的是戰略合作夥伴關係。雖然需求分析人員和客戶存在著服務商和顧客的關係，但是他們有著乙個共同的目標：開發出適合客戶需求的軟體，因此需求分析人員除了記錄客戶提出的需求以外，還應和使用者討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，盡量多的召集需求研討會，邀請開發人員和客戶共同協商**，在研討會上允許任意的提出需求，並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能，這樣能夠盡量使得需求完備。在需求開發時，開發人員採用原型的方法啟發客戶思考功能需求也不失為乙個好辦法。
雖然需求不可能是完備的、變更不可能沒有的，但是在專案開始設計時使得需求盡可能完備還是應該的，也是值得的，完備需求的過程也就相應的減少了因為需求不清楚而產生變更的機率。
如何做好需求變更管理？ 需求變更流程規範
一 引言 由於目前公司內部對產品的需求變動都只是口頭或郵件中進行通知，並沒有進行內部評審和相關需求變動後的記錄，導致後續出的產品某些需求增加了，某些沒有進行增加。這樣就會導致測試得到的資訊不完整，以及後續產品的維護困難。在這裡書寫乙份規範說明書，希望能得到一些改善。二 目的 控制需求變化引起的開發 ...
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...
需求變更的煩惱
客戶今天要求變更需求，加某某功能，這個應該不難吧，某某公司的產品都有這個功能的。客戶的需求一直在變，煩惱。開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的。客戶方和開發方在一起 workshop 還好，如果分開在兩地就更糟糕。永...