·需求不清楚。
需求的變化問題是每個開發人員、每個項目經理都遇到的問題，也是最頭痛的問題，一旦發生了需求變化，你不得不來修改你的設計、重寫你的代碼、修改你的測試用例、調整你的項目計劃等等，需求的變化好比是萬惡之源，為項目的正常的進展帶來不盡的麻煩，怎么辦？管理它！使需求在受控的狀態下發生變化，而不是隨意變化，需求管理就是要按照標準的流程來控制需求的變化。難題隨之而來，需求中的變化一般不是突發的革命性的變化，最常見的是項目需求的漸變（Project Scope Creep）問題，這種漸變很可能是客戶與開發方都沒有意識到的，當達到一定層度時，雙方才驀然回首，發現已經物是人非，換了一番天地。
三、需求管理策略
需求管理需要遵守以下策略：
1、需求一定要與投入有必然的聯系。
需求一定要與投入有必然的聯系，否則如果需求變更的成本由開發方來承擔，則項目需求的變更就成為必然了。人們常說世上沒有免費的午餐，同樣也不應該有免費的需求變更。但是，接受需求變更目前卻是軟件開發商不得不咽下的苦果。所以，在項目的開始無論是開發方還是出資方都要明確這一條：需求變，軟件開發的投入也要變。
2、需求的變更要經過出資者的認可。
需求的變更引起投入的變化，所以要通過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。筆者曾經經歷過一個項目，為了避免項目的風險，我們請了用戶代表全程參與了開發過程，結果此用戶代表在開發過程提出了大量“小的需求變更，當開發人員按此需求變更修改了軟件時，在項目進入現場實施階段時，卻有大量的這些變更需要改回去，問題就是出在我們的項目組成員視該用戶代表的需求為圣旨，卻忽略了需求是否經過了客戶方真正有決策權的人員的認可。
3、小的需求變更也要經過正規的需求管理流程。
小的需求變更也要經過正規的需求管理流程，否則會積少成多。在實踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間。正式由于這種觀念才使需求的漸變不可控，最終導致項目的失敗。
4、精確的需求與范圍定義并不會阻止需求的變更。
并非對需求定義的越細，越能避免需求的漸變，這是2個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非由于需求寫細了，它就不會變化了。注意溝通的技巧。實際情況是用戶、開發者都認識了到了上面的幾點問題，但是由于需求的變更可能來自客戶方、也可能來自開發方，作為客戶他們可能不愿意為需求的變更付出更多的投資，開發方有可能是主動的變更了需求，他們的目的可能是使軟件做的更精致，于是作為需求管理者、項目經理需要采用各種溝通技巧來使項目的各方各得其所。
基于上述的問題，必須對需求進行管理，使需求能夠真正成為軟件工程和管理的基線，使軟件計劃、活動和工作產品同軟件需求保持一致，使需求可以復用。
文章來源于領測軟件測試網 http://www.k11sc111.com/
