關鍵詞：需求、需求變更、需求分析、代價估算、面向對象技術、封裝、繼承、多態、UML 、軟件設計、軟件可維護性、可擴展性、軟件可重用性、接口
摘要：作者針對當前軟件系統建設中普遍存在的需求變更問題提出了自己的見解，并提出除了從客觀上采取加強培訓和代價分析等方法外，更重要的是通過采用合理的分析設計方法，進行可擴展性設計可以有效地降低需求變更引起的風險和維護代價，并給出了可擴展性設計的一個具體例子。
軟件系統開發過程中的需求變更問題作為軟件開發人員或者軟件系統客戶，相信我們都遭遇過因為需求變更而需要修改系統的情況，一般說來客戶會要求改變界面，改變操作方式，甚至改變業務，說，當時我是那樣要求的，不過現在我們的業務調整了…這時需要中斷正在進行的工作，需要查證以往的資料，需要修正計劃，需要…
需求包括業務需求、用戶需求和功能需求。業務需求（Business Requirement ）反映了組織機構或客戶對系統、產品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產品必須完成的任務，功能需求（Functional Requirement ）定義了開發人員必須實現的軟件功能。在軟件系統開發過程中，有很多問題都是由于在需求分析階段沒有正確地收集、編寫、協商、修改產品真實需求而產生的，造成這樣的狀況有幾方面的原因:
對需求的理解分歧
當客戶向需求分析人員提出需求的時候往往是通過自然語言來表達的，這樣的表達對于真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫出來的時候客戶當然會跳起來了！這是理解分歧的問題，一般跟分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關；
系統實施時間過長
一個大中型系統的建設可能要延續一段時間，當客戶提出要求之后，他當時并不能看到系統的運行情況，當雙方認為理解大概沒有分歧的時候（事實上還會有個Deadline ），開發方就開始工作了。當客戶拿到差不多可以試用的產品時他可以實際操作，這時候他就會對系統的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求；
客戶具體情況不一
當前客戶的情況不一，有可能客戶行業的競爭度高，需要隨時作出調整和反應，那么他們自然會經常提出需求變更的要求；也有可能客戶所在的行業操作不規范，本身存在很多人為因素，這時候開發方更是需要隨時準備應變；
開發本身要求
有可能是來自開發方自身版本升級或性能改進、設計修正的要求出現需求變更，這時更是無法繞開這個問題的了！
所以說就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統還是會提出一些個人意見，就算沒有個人意見，他們自己的業務會變化或環境發生變化，這些都是無法避免的，所以不要夢想那么理想的需求分析，當你開始一個項目的時候就應該意識到，客戶需求變更一定會有的，那么對于這樣的現狀，我們該怎么辦呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設計也會改變得支離破碎，系統難以維護？
客觀面對需求變更如果需求一定會變化，如果我們不得不面對，如果我們已經痛定思痛，想要變革，那么還有什么辦法可以改善我們的現狀
答案是有的。
加強人員培訓
從客觀方面可以采取的措施來說，首先，我想不容置疑的是加強對需求分析人員的培訓，盡可能增強軟件系統、行業的背景知識，提高與客戶的溝通能力，增強服務意識和責任感，因為將要開發的系統直接建立在需求分析的基礎上；同時規范需求分析人員和客戶溝通的方式，以及規范需求說明的格式，如果可能的話，盡量采取象XP 的UserStory ，或者用戶可以理解的用例圖來對需求進行標準、規范的描述，保證雙方在工具的協助下對需求達到共同的認識，這一點是老生常談，就不多說。
確定文檔的有效性（Validity ）
順便要提的一句是關于文檔，需求文檔是相當重要的，可是目前存在一種奇怪的現象，本來說必須要有文檔，而且是按照某種特定的格式，當然這沒有錯，但接下來，卻沒有人關心文檔的真正內容是否正確，格式是否真的合理，是否實用（而且很多情況下是在幾天時間里趕出來或補上去的），例如我遇到一個例子，需要在原來的需求基礎上進行后續開發，文檔找到了，完全符合格式的要求，但是我在里面找到的線索是有限的，結果是自己花幾天的時間查找數據表結構、甚至查看數據表的內容，詢問當時的開發人員，才分析到所要的關系，這種情況在設計文檔里也存在，所以同時提一提，希望我們的開發人員、PM 以及各級領導可以注意文檔的有效性和有用性問題，甚至對文檔的格式進行一下合理性檢查。
建立代價估算（Cost Estimate ）概念
這一點對開發方和客戶同樣重要，因為如果出現需求變更，不可避免將帶來成本的增加、開發時間延長等不良后果，這樣的影響是雙方的。
這時候需要區分需求變更的原因，是客戶方必要/不必要的要求，還是由于開發方的工作失誤，還是雙方都有原因，然后對現實情況進行分析，得出雙方實現變更需求的需要的成本，包括時間，人力，資源等等方面，再與客戶商討是否必要進行變更和如何在最小代價下實現變更。
當客戶看到實際的代價估算，他們也會再一次慎重地考慮需求變更問題，也會更容易理解系統建設中的進行狀況，自然開發方也不用負擔所有的需求變更成本，所以進行成本分攤還是有其積極意義的。
當然還有建立需求變更版本控制等等專業的需求管理，在這里不做專門論述。
從軟件分析和設計著手
前面說了面對需求變更的幾種策略，那么從軟件系統分析和設計的角度來看，通過采用合理的分析設計方法，進行可擴展性設計可以有效地降低需求變更引起的風險和維護代價。
采用OO 技術
采用OO 技術可以建立易于改變和加強可重用性的軟件系統。
對于OO 技術，我想現在已經不是什么陌生的概念：
1 封裝（Encapsulation ）可以把問題影響的范圍縮小，外部的變化要求對系統的影響可
以限定到某個類層次或某些類層次中，從而改變系統的一部分相對簡單；
2 繼承（Inheritance ）可以使改變基于原有技術基礎，很大程度上減少重復開發工作；
3 多態（Polymorphism ）的應用可以使開發和設計人員在相對統一的接口下更改系統的實現細節，從而改變系統的行為；
4 而且由于對OO 的類體系結構業界有非常清楚明晰的描述方式，就是目前規范的描述語
言-UML ，非常易于被開發組的理解并達成共識，促進開發組成員之間的合作以及加強軟件開發工作的可延續性；
可見本身即是一種增強軟件可維護性、健壯性以及保持設計穩定性的一種分析和設計方法，本身可以在一定程度上快速對需求變更進行反應，并可相對減少需求變更需要的成本。（OO 的意義在于分析和設計軟件系統的思考方式，以及建立對象庫以后的軟件重用將給軟件系統的開發帶來質的改變，但是在建立OO 開發體系之前的過程，一定會是一段荊棘遍布的路，需要付出加倍的努力以及達成思想的轉變。這里還有一個誤區需要澄清的是很多人以為用了C++，PB ，VB ，DELPHI 就是面向對象的開發了，其實只是用了一些面向對象的工具，骨子里仍然是結構化的分析和設計方法，套上一層OOP 的外殼而已。）
可擴展性設計（Extensible-Design ）
其次，從我們可以控制的軟件設計來說，怎樣進行合適的設計才能最大程度減少需求變更帶來的代價？
也許有人說，我的設計極為靈活，我已經預計了客戶可能提出的要求，并設計幾種應對的方式，到時
候客戶提出來，呵呵，我已經解決了。這樣的想法不錯，至少比僵硬的設計強，但是誰可以保證設計者可以預知以后的需求變化？而同時為了達到這種靈活（萬能/多能？）的設計，設計將變得復雜，而且可能那些多余的設計從來不會被用到？復雜的設計將增加實現的難度和提高成本，并有可能帶來潛在的Bug ，使得系統難以維護。
設計的思想應該有一些小小的轉變，那就是，設計確實要靈活，但是要體現在可擴展性上面，也就是說，設計可以簡單，但是一定要易于轉變，需要給出便于改變的接口，這一點很重要。
例如，現在有一個類叫做TCPConnection ，來代表計算機網絡通信中典型的TCP 連接，對于這個連接而言，它可能處于以下幾種狀態：Established （連接已建立），Listening （正在偵聽），Closed （連接關閉）。一個連接對象需要從其他的對象接受請求，至于它的反應則決定于連接對象所處的狀態，對于（打開連接的請求），如果是在連接關閉狀態，則進行Open （），處于其他狀態則不做反應；同樣，如果在連接建立和偵聽狀態，可以進行Close （），在連接建立狀態可以進行Acknowledge （），即接收數據。
對于這樣的狀況，最不可取的設計應該是用一系列的Switch 語句（甚至If/else 語句）進行Hard 設計，對于以后每一次需求改變，都需要改變源代碼，接踵而來的系統一致性、文檔更新等工作將使開發人員不可避免地陷入一場災難，這樣的后果將導致原來就不合理的設計變得更加支離破碎，系統維護的代價將越來越大；就算沒有需求變更發生，這些設計的可重用性也會極差。稍好一些的設計是預先估計并設置TCPConnection 類所有可能的狀態，并預先加入設計，這種需要付出更多的設計、開發、維護的代價，而且也很難達到完美的效果，所以不多說了。
下面介紹一種經典的設計思路，這種設計可以充分體現“為（系統）將來改變預留接口”的可擴展性（Extensible-Design ）思想，并且很好的實現了這一思想。在這里，我們引入一個抽象類TCPState 來代表TCPConnection 類的狀態，給出具體各種狀態的通用操作接口，并派生出不同的子類（實現具體的操作）
去實現TCPConnection 類的不同狀態，例如派生出TCPEstablished 類來實現TCPConnection 類的連接建立狀態。結構圖示如下：
只需要在TC
PConnection 類中包含一個TCPState 的狀態引用，并在TCPConnection 的狀態改變時更新為當前的狀態引用，例如在連接關閉時進行Open （），狀態引用就應該從TCPClosed 變成TCPEstablished ，這樣就實現了原來的要求。
但這個設計思路的意義遠不止于此。我們可以看到，抽象類TCPState 已經為TCPConnection 類將來可能的狀態留出接口，只需要不斷派生具體的不同狀態子類就可以實現將來的狀態變更，并且無須影響原有的設計，也無須加入多余的代碼來實現現在還不需要的功能，所以這是一個優美的、可擴展的設計思路，非常清晰，易于維護，相信可以給我們在做軟件設計時帶來一些啟發。
結論
可見，在面對需求變更時，除了客觀上可以通過人員培訓、代價分析等管理方式進行有效的需求管理外，從分析和設計的角度可以通過采用合理的分析和設計方法，還有改變我們設計的意識，可以做到對需求變更的靈活應對，至少可以在一定程度上降低維護代價和提高用戶滿意度。
軟件需求的管理和控制是非常專業的學問，作者在這里結合自己的實踐提出一些粗淺的認識，只是想起到一個拋磚引玉的作用，希望大家可以一起來面對和想辦法解決我們在系統開發過程中的實際問題，我想那樣才是我真正想達到的目的。
參考文獻：
1.《軟件需求》，（美）Karl E. Wiegers 著，陸麗娜、王忠民、王志敏等譯，機械工業出版社，20002.《Design Patterns:Elements of Reusable Object-Oriented Software 》，（美）Erich Gamma 、Richard Helm 、Ralph Johnson 、
John Vlissides 著，Addison-Wesley ，1994
3.《Is Design Dead 》，（美）Martin Fowler ，Thought Works ，2000
Face the Requirement Changes
Abstract: This article illustrates the general requirement-changes during software system construction. It discovers
many useful ways such as Object-Oriented technology and Extensible-Design to resolve the problems mentioned above,
other than the enhancement of training and cost analysis. Also an Extensible-Design example is involved in this article
for better understanding.
Keywords:Requirement, Requirement Changes, Requirement Analysis,Cost Estimate,Object-Oriented technology,
Encapsulation, Inheritance, Polymorphism, UML, Software Design, Software Maintainability, Software Extensibility,
Software reusablilty, Interface
文章來源于領測軟件測試網 http://www.kjueaiud.com/
