對需求的理解分歧當客戶向需求分析人員提出需求的時候往往是通過自然語言來表達的，這樣的表達對于真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫出來的時候客戶當然會跳起來了！這是理解分歧的問題，一般跟分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關；系統實施時間過長一個大中型系統的建設可能要延續一段時間，當客戶提出要求之后，他當時并不能看到系統的運行情況，當雙方認為理解大概沒有分歧的時候（事實上還會有個Deadline ），開發方就開始工作了。當客戶拿到差不多可以試用的產品時他可以實際操作，這時候他就會對系統的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求；客戶具體情況不一當前客戶的情況不一，有可能客戶行業的競爭度高，需要隨時作出調整和反應，那么他們自然會經常提出需求變更的要求；也有可能客戶所在的行業操作不規范，本身存在很多人為因素，這時候開發方更是需要隨時準備應變；開發本身要求有可能是來自開發方自身版本升級或性能改進、設計修正的要求出現需求變更，這時更是無法繞開這個問題的了！所以說就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統還是會提出一些個人意見，就算沒有個人意見，他們自己的業務會變化或環境發生變化，這些都是無法避免的，所以不要夢想那么理想的需求分析，當你開始一個項目的時候就應該意識到，客戶需求變更一定會有的，那么對于這樣的現狀，我們該怎么辦呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設計也會改變得支離破碎，系統難以維護？客觀面對需求變更如果需求一定會變化，如果我們不得不面對，如果我們已經痛定思痛，想要變革，那么還有什么辦法可以改善我們的現狀答案是有的。加強人員培訓從客觀方面可以采取的措施來說，首先，我想不容置疑的是加強對需求分析人員的培訓，盡可能增強軟件系統、行業的背景知識，提高與客戶的溝通能力，增強服務意識和責任感，因為將要開發的系統直接建立在需求分析的基礎上；同時規范需求分析人員和客戶溝通的方式，以及規范需求說明的格式，如果可能的話，盡量采取象XP 的UserStory ，或者用戶可以理解的用例圖來對需求進行標準、規范的描述，保證雙方在工具的協助下對需求達到共同的認識，這一點是老生常談，就不多說。
確定文檔的有效性（Validity ）順便要提的一句是關于文檔，需求文檔是相當重要的，可是目前存在一種奇怪的現象，本來說必須要有文檔，而且是按照某種特定的格式，當然這沒有錯，但接下來，卻沒有人關心文檔的真正內容是否正確，格式是否真的合理，是否實用（而且很多情況下是在幾天時間里趕出來或補上去的），例如我遇到一個例子，需要在原來的需求基礎上進行后續開發，文檔找到了，完全符合格式的要求，但是我在里面找到的線索是有限的，結果是自己花幾天的時間查找數據表結構、甚至查看數據表的內容，詢問當時的開發人員，才分析到所要的關系，這種情況在設計文檔里也存在，所以同時提一提，希望我們的開發人員、PM 以及各級領導可以注意文檔的有效性和有用性問題，甚至對文檔的格式進行一下合理性檢查。建立代價估算（Cost Estimate ）概念這一點對開發方和客戶同樣重要，因為如果出現需求變更，不可避免將帶來成本的增加、開發時間延長等不良后果，這樣的影響是雙方的。這時候需要區分需求變更的原因，是客戶方必要/不必要的要求，還是由于開發方的工作失誤，還是雙方都有原因，然后對現實情況進行分析，得出雙方實現變更需求的需要的成本，包括時間，人力，資源等等方面，再與客戶商討是否必要進行變更和如何在最小代價下實現變更。當客戶看到實際的代價估算，他們也會再一次慎重地考慮需求變更問題，也會更容易理解系統建設中的進行狀況，自然開發方也不用負擔所有的需求變更成本，所以進行成本分攤還是有其積極意義的。當然還有建立需求變更版本控制等等專業的需求管理，在這里不做專門論述。從軟件分析和設計著手前面說了面對需求變更的幾種策略，那么從軟件系統分析和設計的角度來看，通過采用合理的分析設計方法，進行可擴展性設計可以有效地降低需求變更引起的風險和維護代價。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
