需求即使在使用者簽字確認之後，還是會有所變化，可能從設計、開發甚至測試階段反饋回來的需求，其中的一些是的確需要做變更處理的，可是其中很大一部分，不應該作為變更處理，但是在過程中，這些需求改如何處理，我著實有些迷茫，答案還在繼續尋覓中。。。。。。
我自己是這樣處理的，我自己有乙份記錄文件，記錄下了各個方面反饋回來的需要對需求的改變，用來跟蹤所有那些算不上變更的需求修改記錄，雖然這似乎不符合cmm或cmmi的規範，可是如果把所有這些都通過需求變更來做，需要增加多少工作量啊？需求變更單恐怕會象紙片一樣飛向我，飛向設計人員、開發人員和測試人員，甚至客戶會煩死在不斷的確認中。不過這種做法也比較危險，畢竟人如果範懶，就會把那些變更也通過這種來做了。
可能是我的需求還做得不夠好，客戶在簽字的時候總是特別猶豫，還特別說明，以後如果有什麼改動可不要算工作量來收錢哦，呵呵，這種問題我有什麼權力答應啊？
我是比較喜歡cmm或cmmi這種規範的，只是規範畢竟只是規範，並沒有一些度量的標準來判斷改怎麼做，而是不管度量結果如何，按規範都只有一種做法。不知道是我對cmmi規範了解不深呢，還是這些本身就是規範的缺陷？
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
如何做好需求變更管理？ 需求變更流程規範
一 引言 由於目前公司內部對產品的需求變動都只是口頭或郵件中進行通知，並沒有進行內部評審和相關需求變動後的記錄，導致後續出的產品某些需求增加了，某些沒有進行增加。這樣就會導致測試得到的資訊不完整，以及後續產品的維護困難。在這裡書寫乙份規範說明書，希望能得到一些改善。二 目的 控制需求變化引起的開發 ...