需求變更的管理
需求變更是因為需求發生變化。根據軟體工程思想，需求說明書一般要經過論證，如果在需求說明書經過論證以後，需要在原有需求基礎上追加和補充新的需求或對原有需求進行修改和削減，均屬於需求變更。需求變更的出現主要是因為在專案的需求確定階段，使用者往往不能確切地定義自己需要什麼。使用者常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而採用的新裝置、新技術通常會改變他們的工作方式;或者要開發的系統對使用者來說也是個未知數，他們以前沒有過相關的使用經驗。隨著開發工作的不斷進展，系統開始展現功能的雛形，使用者對系統的了解也逐步深入。於是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現。
這時，如果開發團隊缺少明確的需求變更控制過程或採用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那麼很可能造成專案進度拖延、成本不足、人力緊缺，甚至導致整個專案失敗。當然，即使按照需求變更控制流程進行管理，由於受進度、成本等因素的制約，軟體質量還是會受到不同程度的影響。但實施嚴格的軟體需求管理會最大限度地控制需求變更給軟體質量造成的負面影響，這也正是我們進行需求變更管理的目的所在。源自csdn 可惜沒找到原始出處.實施需求變更管理需要遵循以下六大原則
（1）建立需求基線，需求基線是需求變更的依據。在開發過程中，需求確定並經過評審後（使用者參與評審），可以建立第乙個需求基線。此後每次變更並經過評審後，都要重新確定新的需求基線。
（2）制訂簡單、有效的變更控制流程，並形成文件。在建立了需求基線後提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以後的專案開發和其他專案都有借鑑作用。
（3）成立專案變更控制委員會（ccb）或相關職能的類似組織，負責裁定接受哪些變更。ccb由專案所涉及的多方人員共同組成，應該包括使用者方和開發方的決策人員在內。
（4）需求變更一定要先申請然後再評估，最後經過與變更大小相當級別的評審確認。
（5）需求變更後，受影響的軟體計畫、產品、活動都要進行相應的變更，以保持和更新的需求一致。
（6）妥善儲存變更產生的相關文件。
應對之道
需求變更控制一般要經過變更申請、變更評估、決策、回覆這四大步驟。如果變更被接受，還要增加實施變更和驗證兩個步驟，有時還會有取消變更的步驟。針對變更控制流程，在實際工作中總結出了軟體開發人員在需求變更管理實踐中的幾點對策：
優先排序 分批實現
每個需求的重要性是不同的。由於資源或技術條件的限制，會顯得「僧多粥少」，因此不可能把所有的需求一次完成。怎麼辦？把每個需求按照對效益的貢獻打個分，排出個優先順序來，優先順序高的需求先實現，低的到一下版式本實現。由於不斷有新的需求進來，有的需求可能永遠沒有機會被子實現，但不緊，還是要記錄下來，並一起參加排序，保證在每個版本發布時重要的需求先得到滿足。每個需求的實現是需要花時間的，沒人有百分百的把握預估得很清楚，但借鑑過去的經驗可以大概估算出人力成本，然後根據開發人員和開發周期得出可用人力投入作為上限。從優先順序高的需求中挑，直到挑中的人力成本總和剛剛低於可用投入上限，這樣得出的就是需求的錄取榜。今後的軟體開發規劃也會以此為依據，分期分批地在不同的回合中實現。最合理的不一定是優先順序最高的，也就是說不一不定是最先考慮的，「經濟為本」是指導優先排序的最終原則。
相互協作很難想像遭到使用者抵制的專案能夠成功。在討論需求時，開發人員與使用者應該盡量採取相互理解、相互協作的態度，對能解決的問題盡量解決。即使使用者提出了在開發人員看來"過分"的要求，也應該仔細分析原因，積極提出可行的替代方案。
充分交流需求變更管理的過程很大程度上就是使用者與開發人員的交流過程。軟體開發人員必須學會認真聽取使用者的要求、考慮和設想，並加以分析和整理。同時，軟體開發人員應該向使用者說明，進入設計階段以後，再提出需求變更會給整個開發工作帶來什麼樣的衝擊和不良後果。
安排專職人員負責需求變更管理有時開發任務較重，開發人員容易陷入開發工作中而忽略了與使用者的隨時溝通，因此需要一名專職的需求變更管理人員負責與使用者及時交流。
合同約束需求變更給軟體開發帶來的影響有目共睹，所以在與使用者簽訂合同時，可以增加一些相關條款，如限定使用者提出需求變更的時間，規定何種情況的變更可以接受、拒絕接受或部分接受，還可以規定發生需求變更時必須執行變更控制流程。
區別對待隨著開發進展，有些使用者會不斷提出一些在專案組看來確實無法實現或工作量比較大、對專案進度有重大影響的需求。遇到這種情況，開發人員可以向使用者說明，專案的啟動是以最初的基本需求作為開發前提的，如果大量增加新的需求（雖然使用者認為是細化需求，但實際上是增加了工作量的新需求），會使專案不能按時完成。如果使用者堅持實施新需求，可以建議使用者將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據。同時，還要注意控制新需求提出的頻率。
選用適當的開發模型採用建立原型的開發模型比較適合需求不明確的開發專案。開發人員先根據使用者對需求的說明建立乙個系統原型，再與使用者溝通。一般使用者看到一些實際的東西後，對需求會有更為詳細的解釋，開發人員可根據使用者的說明進一步完善系統原型。這個過程重複幾次後，系統原型逐漸向最終的使用者需求靠攏，從根本上減少需求變更的出現。目前業界較為流行的疊代式開發方法對工期緊迫的專案的需求變更控制很有成效。
使用者參與需求評審作為需求的提出者，使用者理所當然是最具權威的發言人之一。實際上，在需求評審過程中，使用者往往能提出許多有價值的意見。同時，這也是由使用者對需求進行最後確認的機會，可以有效減少需求變更的發生。
變更控制流程如圖所示。
需求變更的代價
一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間、人力、資源等等方面。
變更都是有代價的，應該評估一下變更的代價和對專案的影響，在評估代價並且與客戶討論的過程中，
要讓客戶了解變更的後果，變更之後面臨最大的問題就是專案延期，
讓客戶一起做判斷：
「我可以修改，但您能接受後果嗎？
」。現在會出現三種可能：客戶接受延期這一後果，開發人員按客戶要求做出相應修改，讓客戶知道為此需要付出延期的代價
；如果客戶認為代價太大，那開發人員就不必修改了，可以記錄下需求，待到下一版本再做修改；客戶不接受變更的代價，導致專案夭折。 如果客戶不知道你為變更付出的代價，對你的辛苦便難以體會，以致沒完沒了的提出新的變更。
減少需求變更
正如前文所說，需求變更往往是不可避免的。通常是專案負責人員花費了大量的氣力避免需求變更，可最後需求變更總是會出現。但是這並不意味著專案開發人員不應該做這方面的工作，專案開發人員對於需求變更的正確態度應該和軟體測試的態度一樣，在需求變更發生之前儘量減少需求變更，以將需求變更帶來的風險降低到最低。專案開發人員切忌在專案設計之前試圖消除需求變更，這樣做往往費力不討好。
相比於需求開發人員而言，客戶可能對需求變更認識不足，認為他們出錢，程式設計師或軟體開發公司就要為它服務，因此客戶對需求變更往往更加肆無忌彈，將需求變更視為兒戲，隨個人喜好隨意變更需求。因此，在需求人員同使用者代表或使用者部門主管人員接觸時，就應該向他們挑明態度，和他們協商好，特別是應該讓他們清楚軟體的定價應該與軟體的功能相關，以及需求隨意變更所帶來的風險的承擔者應該由客戶和專案開發者共同承擔。通過這樣做，讓客戶在需求分析之前就盡量對他們所需要的功能有個整體的了解和確定的思路，而不是等到程式設計師開始編碼了，才提出以前原本在需求分析時就可以提出的需求。
讓客戶明白減少需求變更的重要性後，需求分析人員應該採取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關係不應該僅僅是記錄人員和需求提供者，他們的關係應該更多的是戰略合作夥伴關係。雖然需求分析人員和客戶存在著服務商和顧客的關係，但是他們有著乙個共同的目標：開發出適合客戶需求的軟體，因此需求分析人員除了記錄客戶提出的需求以外，還應和使用者討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，盡量多的召集需求研討會，邀請開發人員和客戶共同協商**，在研討會上允許任意的提出需求，並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能，這樣能夠盡量使得需求完備。在需求開發時，開發人員採用原型的方法啟發客戶思考功能需求也不失為乙個好辦法。
雖然需求不可能是完備的、變更不可能沒有的，但是在專案開始設計時使得需求盡可能完備還是應該的，也是值得的，完備需求的過程也就相應的減少了因為需求不清楚而產生變更的機率。
需求變更管理的應對和需要遵循的六大原則
需求變更的管理 需求變更是因為需求發生變化。根據軟體工程思想，需求說明書一般要經過論證，如果在需求說明書經過論證以後，需要在原有需求基礎上追加和補充新的需求或對原有需求進行修改和削減，均屬於需求變更。需求變更的出現主要是因為在專案的需求確定階段，使用者往往不能確切地定義自己需要什麼。使用者常常以為自...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
需求變更管理和需求的可追溯性
在專案管理過程中，總是難免會碰到需求的變更，需求變更之所以會產生，可能是使用者不能清晰描述需求或對需求也不是特別明確，也可能是開發人員對需求理解與使用者不一致，或者是使用者需求確實有更改，或者是遇到其他外部環境的影響 如國家政策 需求的變更總會對專案產生一定的影響，比如專案範圍 專案進度 專案質量 ...