做過的項目同軟件，基本上最后的程序同開始時確定的都有些偏差...

總結下，隨便說3個常常碰到的:

第一類，常見的合情理但不合規矩的，比如報表增加，文檔格式更改，數據的查詢，數據統計更改條件等等,事先沒有考慮進來但實際中存在的;

第二類，頭疼的管理決策層需求同應用者的沖突,管理決策要加入他們的管理思想，而這需求有時與軟件終端用戶的需求產生不可避免的矛盾沖突，比如管理者需要一個長的清晰明確的數據流過程，寄希望在這一套系統上來完善業務的管理制度，這樣不可避免的，系統上就會多了一些內容，而對應用者來說，方便快捷，才是他們想要的，內容越少,流程越短他們的效率才越高；

第三類，最頭大的...需求描述與交流不足，理解上的不一致,導致要大改,這個本來應該最能避免的,但常常發生.

下面講下如何避免發生這類問題：

第一類的問題在于開始時需求就不確定，客戶自己都沒有碰到過的一些突發事件的考慮是所有人都沒有預料的,因此對開發是按行業開發思路還是按使用者的意愿的問題就能明白回答了,在開發時,在數據結構上一定要多考慮,即使一些客戶沒有要求的,也要按一般行業要求來考慮,要考慮可擴展性,不能因為客戶需求沒有要求,或從系統性能上優化上考慮,而放棄一些模塊的措施,這樣能避免很多軟件后期更改需求時對數據庫或功能模塊作大的修改;

第二類解決時應該避免問題放大，確定局部性范圍. 現在在企業內部搭建ERP,CRM等性質系統的企業還是不多,很多的客戶管理需求只是簡單的管理層個人需求而已,而不是說對企業進行系統分析,再對業務流程合理化或重組,制定管理業務標準等措施來把信息技術與先進管理集合起來的大工程, 所以一方面要明確用戶需求的來源同優先級別,雖然一般參與系統建立的決策人對業務流程都比較熟悉，但對細節上并不是很了解，一些特性就很少了解,對這些熟悉的還是實際前臺操作人員,所以在流程同功能模塊上聽取客戶管理層外,交互界面的處理一定要注意同終端用戶進行溝通；另一方面,要多讓用戶做測試同培訓,讓用戶能在系統完善的過程中熟悉操作同流程,參與系統建立,畢竟接受新事物都有一個過程的,這樣當正式使用時就不會產生抵觸或被迫的心理.

第三類的問題歸根結底就是人與人之間的溝通問題,各方面都有自己的想法同考慮. 有時候語言的交流不如用 DEMO來的有效果,一份初期的DEMO能讓雙方少走很多彎路,而且,通過 DEMO能確定下來很多文檔,省了很多功夫,又能讓客戶心中對軟件系統有個一個大致的概念.

最后說下客戶的后期要求,一般除非前期合約說定的很清晰明白,否則,只有妥協,畢竟還沒有交貨收錢...,當然客戶的意見也不能完全聽取,并且要適當的通過一些相關行業的實例來引導客戶的要求,但也要明白決權還是在客戶手中，你的期望不是他的期望,即使最后的軟件的質量不會高,也許這也算是做軟件的一種悲哀吧.

轉載于:https://www.cnblogs.com/Augur/archive/2006/09/12/502590.html

總結

以上是生活随笔為你收集整理的需求变更的处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。