在軟體專案執行過程中，需求的變更在所難免。讓使用者對需求變更簽字確認往往是專案組比較頭疼的事情之一。一般來說，正常的需求變更還是需要使用者簽字確認的，當然要做通客戶的工作，讓客戶理解：簽字是為了更好的保障開發人員理解真正需求。
一般來說，使用者不簽字有兩種原因：
一是使用者認為不是變更，是應該做的工作
二是擔心承擔責任，不願意簽字
如果是前者，那只有一方認可的變更，那不管是否簽字都是乙個風險，還是要讓雙方達成共識。
對於後者「責任」問題，關鍵是如何向客戶來談變更的事情，如果字在專案初期就養成良好的工程習慣，並與客戶做好約定，客戶一般是會接受簽字這個形式的。
變更簽字和做專案前先簽合同，付款前要確認賬號一樣屬於正常的專案工程活動，是甲方的義務和責任，更是一種確認的權力，不要讓客戶覺得只是為了讓他承擔什麼責任。
最重要的是，書面簽字確認只是乙個形式，關鍵還是要就變更事宜達成共識，有效的實施變更，並使每項專案活動得到管理和控制。
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
需求變更的煩惱
客戶今天要求變更需求，加某某功能，這個應該不難吧，某某公司的產品都有這個功能的。客戶的需求一直在變，煩惱。開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的。客戶方和開發方在一起 workshop 還好，如果分開在兩地就更糟糕。永...
我的需求變更
最近好累啊，不停的在變更我所寫的需求說明書，覺得自己不想是個有思想的動物，只是在按照他人的想法在不停的修改，修改。回頭想起來，自己是不是乙個有想法的人呢？似乎又沒有辦法完全的回答，對於目前所處的這個領域我覺得自己真的是缺乏很多的知識，拼命的在補充自己，但是似乎沒有辦法在短時間內完全的掌握現在的工具，...