在整個開發的生命周期中維護在用戶與分析人員之間的交流是尤其有效的。雙方都應該理解他們擁有相同的目標：建立滿足質量要求的可以解決問題的方案，同時成本是可接受的。如果他們的關系是圍繞著爭論關于什么是以前達成的一致和誰應該為此付錢，而不是建立一個正確的方案的話，那么項目就陷入了麻煩之中。這并不意味著分析人員應該接受所有的需求或者最終用戶不應該作出變更的請求。相反，這意味著所有的項目相關的人員應該在提出需求和最終進入到訂單中的需求進行一個平衡以形成更好方案的開發。他們需要認可當他們過分的嚴格時，應該通過一些討論以達到一個折中的方案，并且要作積極的改變以保持項目按照計劃進行。當然，這一點做起來要比說的有難度。但是朝著有效的 團隊協作的第一步是在分析人員與最終用戶之間建立起有建設性的對話。
過度的指出預想的需求是不明智的
傳統的開發方法提倡詳細的預先需求，并且在過去的多年里很多人覺得項目失敗是因為他們的需求對啟動項目是不夠詳細的。但是增加需求說明的詳細程度將會減少的回報。在一些情況下，項目團隊需要不斷的構建方案，并假設需求在整個項目周期不斷的改進。記�。很浖椖康闹饕繕耸窃诒M可能低成本的條件下生成可執行的能夠解決手工形式的業務問題的代碼。一旦你的需求到達了一定的細化程度，將他們定案的最廉價的方法是對系統進行部分的實現以可以向最終用戶進行演示。同時你可以一起確定你還需要提供什么樣的其他能力。定案需求通常要經過幾次的迭代，在迭代期間你可以調整需求、設計和代碼，然后對測試進行引導。
在項目周期的后期你可以不必正式的文檔化很多的詳細的需求；代碼本身可以提供足夠的文檔，并且很少在團隊中誤解什么是需要實現方面存在 風險。這依賴于正被開發的系統自然的改變了參與的人數、系統期望的生命跨度、和約的義務和附加的質量 標準的需求。最后，也許是最重要的，你應該象驅趕技術風險一樣在項目中盡早驅趕商業上的風險。在細化預想的需求上花費過多的時間會使你的注意偏離出降低關鍵的風險。
開發人員的新思想
擴大了的職責包括詳細設計、實現和單元測試。
成為需求工作中的一部分：幫助闡明需求然后創建符合需求的方案。
成為了測試工作的一部分：按照測試先行的設計原則開發代碼。
盡可能的重用已存在的方案而不是重新構建方案。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
