辛辛苦苦的熬了幾個月，軟件開發終于快要告一段落了。系統功能已經基本完成了，在準備按部就班的完成最后的測試時，客戶突然提出要改變某些非功能性需求。這對于軟件開發團隊來說，不亞于晴天驚雷，這也是讓所有軟件開發人員感到最恐怖的事情之一。因為在多數情況下，對非功能性需求的變更都會演變成一個對系統無休止的修改過程，最終會把客戶和開發團隊都拖進泥潭而難以自拔。

需求變更本應是客戶的權力，如果確是需要變更，當然要滿足客戶需要。但問題是不能讓變更權力濫用，把一些無關痛癢的非功能性需求變更寵慣養成堂而皇之的變更。對于非功能性需求客戶總會有新的想法，項目好像總沒有辦法終結。以前當出現這種情況時，我總覺得很沮喪，覺得自己非常不幸，怎樣會碰上這樣的客戶。可在讀了《設計模式精解（Design Patterns Explained）》一書的一段話后，我恍然大悟，這不是我的錯，世界原來就是這樣子的啊，永遠不變的就是變化。

令人煩惱的非功能性需求變更

在軟件開發中，大家都會遇到過這樣的問題：客戶的一個新想法，就推翻了之前與客戶經過再三討論而確認定下來的需求。如果是功能性需求變更還會讓人容易接受一些，畢竟功能性需求不實現的話，是會大大影響到軟件產品的質量。但現在我所負責的這個開發項目中遇到的都是一些非功能性的變更,而且許多是看起來無關痛癢的、雞毛蒜皮的變更。

（1）什么是非功能性需求？

在IEEE中，軟件需求的定義是：用戶解決問題或達到目標所需的條件或功能。一般包含業務需求、用戶需求、功能需求、行業隱含需求和一些非功能性需求。業務需求反映了客戶對系統、產品高層次的目標要求；功能需求定義了開發人員必須實現的軟件功能。所謂非功能性需求，是指為滿足用戶業務需求而必須具有除功能需求以外的特性。包括系統性能、可靠性、可維護性、易用性和對技術和對業務適應性等。其中最常見的是軟件界面、操作方便等一系列要求。

（2）非功能性需求變更的特點

讓我們從客戶角度和開發人員角度去看看非功能性需求的特點。首先，有些非功能性小需求從客戶角度看起來工作量不大，但是實際上開發人員要耗費比較長的時間去完成這些小功能。其次，許多非功能性需求，如界面美觀、操作方便等都是客戶頭腦一熱、或領導一拍腦袋就部署下去的需求，往往是原來在需求分析階段所沒有注意的內容。

其實，非功能性需求是常常被輕視，甚至被忽視的。原因是非功能性需求描述很困難，它很難像功能性需求那樣，可以通過結構化和量化的詞語來描述清楚。在描述這類需求時候，我們經常采用軟件性能要好、操作要方便、軟件界面要美觀大方等較模糊的描述詞語。例如，易用性就同時涉及到美工和UI界面、人機工程、交互式設計、心理學、用戶行為模式等內容。這類描述詞語都是脫離了軟件的執行環境，是對人和相關的場景的描述，因此很難體現到軟件架構設計和具體的實現中。

為什么非功能性需求變更會頻繁發生？

為什么非功能性需求不能固定下來呢？或定下來后就不許變了呢？通常有許多人會問這樣的問題。實際上，當他變成了客戶時，他可能就不會問這個問題了。

（1）非功能性需求容易產生理解分歧

在軟件需求分析階段，客戶和開發人員對非功能性需求的理解呈現"大體上共識多，細節上差異多"的特點。一般跟分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關。即使通過反復溝通，但是以實踐經驗來看非功能性需求的描述還是永遠不夠清晰、不夠明確的，主要是因為在這個階段所謂的產品還只存在于大家的大腦構思中。

作為一個客戶，大多數情況下是不懂技術的，但他所需要的軟件在他的心里還是有一個印象的。他會想象出軟件的樣子和功能，然后通過口頭或者筆頭的方式告訴需求分析人員。簡單的說，就是在這個階段用戶往往不能確切地定義自己需要什么。用戶常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，或者是他們想象出來的東西。結果是當客戶向需求分析人員提出需求的時候，往往是通過自己的想法用自然語言來表達的，這樣的表達結果對于真實的需求來說只是一種描述，甚至只是某個角度的描述，但遠遠不能保證這樣的描述可以得到百分之百的正確理解。

當客戶提出要求之后，在雙方認為理解大概沒有分歧的時候，開發人員就開始工作了。但隨著開發工作的不斷進展，系統開始展現雛形，客戶對系統的了解也逐步深入。這個時候，客戶就會對系統的界面、操作、功能、性能等有一些了解，就有可能提出需求變更要求，而且這些要求很多是基于主觀的、人為的因素。總之，他們了解得越多，新的要求也就會越多。

（2）沒有明確的需求變更管理流程

在軟件開發中的常識是，一旦發生需求變更不要一味的抱怨，也不要一味地去迎合客戶的新需求，而是要管理和控制需求變更。但令人不解的是我們常常看到變更的提出、討論和執行常常只停留在口頭上。這樣做有兩個弊端：首先是時間一長，無論是當事人還是開發團隊都說不清楚變更是因何發生以及結果怎么樣了。顯然，這對于提高項目質量、改進開發過程是很不利的。其次是由于缺乏形式上的約束和對變更代價的定量分析，變更會被非常隨意地提出、或被草率地執行，也會大大影響項目的進展和開發質量。

因此，沒有明確的需求變更管理流程，就會使需求變更變得泛濫。因為并不是所有的變更都要修改，也不是所有變更都要立刻修改，需求變更管理的目的是為了決定什么類型的變更需要修改和什么時候修改。比如界面風格問題，就可以先不修改，或者規劃一下修改的時間待到以后進行優化。

（3）沒有讓客戶知道需求變更的代價

對變更的影響沒有評估是需求變更泛濫的根本原因。變更都是有代價的，應該要評估變更的代價和要讓客戶了解需求變更的后果。如果客戶不知道需求變更付出的代價，對開發人員的辛苦就會難以體會。

相比于需求開發人員而言，客戶可能對需求變更認識不足，認為他們出錢，軟件開發團隊就要為它服務。因此，客戶對需求變更往往會肆無忌彈，將需求變更視為兒戲，隨個人喜好隨意變更需求。所以，在和客戶接觸時應該挑明態度，特別是要讓他們清楚需求隨意變更所帶來的代價和風險。如果客戶認為代價太大，那么開發人員就沒有必要及時修改，按原來的進度走，但仍要記錄變更，待下一版本在修改。

如何有效控制非功能性需求的變更?

做任何變更之前，我們都要考慮后果。由于非功能性需求變更在開發中所處的重要地位，一旦需求發生變化，影響面是很廣的。因此，有效控制非功能性需求頻繁變更是一件不容小視的事情。

（1）建立明確的非功能性需求基線

對于軟件開發來說，變更無可避免，也無從逃避，只能積極應對。因此，在開發過程中，建立明確的非功能性需求基線是一件重要的事情。如果非功能性需求沒做好，基線范圍就含糊不清，就容易被客戶抓住空子，往往要付出許多無謂的變更。如果非功能性需求基線做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的非功能性需求變更就會大大減少。因此，在建立需求基線的時候千萬不能手軟，這并非要刻意針對客戶，而是不能讓客戶養成經常變更的習慣，否則后患無窮。

（2）建立需求變更管理流程

需求變更對軟件開發成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以必須要做好需求變更的控制。有句通俗的話說得非常好：需求變更管理的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行。需求變更管理流程包括變更申請環節、審批人員、審批事項、審批流程等。

目的有兩個：一是將客戶下達變更的流程盡可能地規范化，減少張嘴就來的非必要、非緊急、非合理、非高層領導意圖的無效變更。二是留下書面依據，為今后可能的成本核算準備好變更賬。因此，凡未履行審批程序的變更，一律是無效變更不予受理。在實踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間。但正是由于這種觀念才會使到需求變更逐漸變為不可控，最終導致項目的失敗。

（3）確認客戶是否接受變更的代價

需求變更作為一個計劃外的風險對項目肯定存在沖擊，只是大小的差別。而且客戶的需求是永遠不會滿足的，可能一天一個樣,為了達到控制頻繁的需求變更。需要將變更后產生的成本進行評估與量化，形成分析報告提交雙方領導。否則，一味的妥協只會讓項目進一步惡化。因此，要讓客戶認識到變更都是有代價的，不要讓客戶養成隨意變更的毛病。一般來說，如果客戶認為該非功能性變更是必須的，而不是其上級領導拍腦袋提出的就會接受這些代價。通過與客戶的溝通和協商，開發團隊即使沒有回報也不會招致客戶的埋怨。

（4）加強合同約束力

雖然軟件開發合同很難在簽訂之初就能夠精確定義每項需求，單靠合同是幫不上忙的，但也不能忽視合同的約束力。因為有時銷售人員為使客戶能夠快速的簽訂合同，往往草率決定和片面同意客戶提出的需求。當客戶提出新的需求時，銷售人員往往一看"應該"只是一個小小的修改，沒有太大的影響，可能會直接答應能變更。所以，在與客戶簽訂開發合同時，可以增加一些相關條款，如限定客戶提出需求變更的時間，規定何種情況的變更可以接受、拒絕接受或部分接受，還可以規定發生需求變更時必須執行變更控制流程等。

（5）加強感情溝通，注意溝通技巧

大多時候單靠合同的約束力是解決不了紛爭的。客戶著急了就是一句潛臺詞：做不做，不想做就滾蛋，想做的公司多著呢。例如，有時明明是不合理的要求，可是客戶也會狡辯憑什么不給他們做，這可是合同范圍內的工作。所以，單看合同是沒用的。

那可怎么辦呢？通常的做法是通過感情聯絡，爭取客戶的同情。我們常常對客戶說的一句老生常談的話，就是提需求也要講究合情合理，這句話在變更管理中有著獨特的意義。用我們的行話說是：做好需求變更管理控制只是做好了一半的工作，還有一半的工作就是去講道理，去用心、用感情勸客戶回頭。

月有陰晴圓缺，潮漲潮落。變化并不一定總是給我們帶來麻煩，有時也會帶來驚喜。在軟件開發中，對待客戶提出的非功能性需求變更，我們需要用平常心去看待，不是一味拒絕，也不要一味答應。