需求管理之被遺忘的需求

       先說一個小笑話。有一個生産隊隊長，他對專家說：“現在我們生産隊的地越來越多，牛越來越忙不過來了。我想要這麼一種牛，他吃的草和普通牛一樣多，但是幹的活是普通牛的十倍。”專家說：“這種牛是可以造出來的，現在有基因工程。”隊長說：“好吧，你給這造幾頭這樣的牛。”于是專家找到了生物實驗室，讓生物實驗室的人搞一個基因工程，把牛造出來。于是工程浩大，投資無法保證，合作多半是不愉快的收場。

      現實世界裡很多人分析需求的過程就類似于這位專家，他們把注意力放在使用者提出的功能點上，而對使用者的實際需求沒有興趣。有不少軟體公司和程式員，其實都在做類似的基因工程。如果這個專家把注意力放在生産隊長的業務需求上，而不是太在乎他提出的功能點，他會說：“我認識一個賣拖拉機的，可以帶你去看看。”

      軟體的維護為什麼這麼痛苦，一個很重要的原因在于：需求已經被遺忘了。

      需求是對使用者具有直接商業價值的活動，而不應該牽涉到任何的功能實作方式。實作同一個需求可以使用多個方案，每個方案有自己的功能方式，在某個方案中至關重要的功能點，也許在另一個方案中根本無關緊要。

      瀑布式的開發過程，首先是由一批懂得使用者業務的專家去調查使用者的需求，分析出這個系統應該具有哪些功能，形成一個非常重要的檔案——《xxx系統需求規格說明書》。客戶認可了這個《說明書》，在上面簽字蓋章，加入合同附件，到時候項目驗收就以此為準。這時候，需求就已經分解成了一個個功能點，從這時候開始，需求本身就漸漸被人們遺忘。設計人員圍繞着這些功能點進行工作，考慮用什麼樣的技術手段把功能點制造出來。功能點的制作細節形成了另外一份重要的檔案——《xxx項目設計規格說明書》。這個《設計規格說明書》交給程式員去進行編碼。

      這樣的做法在開發中已經形成了很大的問題。

      首先，面對這樣的《需求規格說明書》，設計人員已經無法知道最初的需求是什麼。假如這個《需求規格說明書》中的功能點沒有出現互相沖突的情況，而他們串起來卻和使用者的需求不同，設計人員沒辦法發現這樣的情況，編碼人員也無法發現。假如測試也是根據這個《需求規格說明書》來做的，測試人員也發現不了。直到最後客戶看見這個程式展現在他們面前。需求的分析需要在随後的過程中不斷得到回報，傳統的過程不是沒有回報，而是回報的時間太長了。

      其次，由于設計人員已經無法知道基本的需求是什麼，也就無法對業務進行模組化。這樣的需求分析是以開發人員的需要為核心的，可是結果恰恰妨礙了開發人員對需求的了解。如果開發人員對使用者的業務過程不甚了解，他們隻有一種選擇：不要試圖去了解需求了，直接按照這些功能點做吧。于是，他們建立的對象模型就不是以需求為核心的，而是以功能、界面為核心的。我見到過很多這樣的系統，開發者确實有很高的抽象思維水準，程式中設計了非常巧妙的控制器和界面，可以很友善的進行開發和變更。唯獨業務層的對象非常簡陋，一旦發生實際業務的變更，仍然十分辛苦。

      更大的困難發生在維護程式的時候。

     假設有一個移動通信公司需要制造一個系統，用來解決手機使用者入網的問題。這個需求有下面幾個要點：

     1：使用者付錢，得到一個SIM卡和一個号碼，把這個SIM卡裝到手機裡就可以通話。

     2：營業員收的錢要記錄下來，提供給稽核人員，現金和帳目必須是平的。

     3：使用者付的話費要劃入他自己的帳戶，可以列印票據。

     4：使用者要在入網合同上簽字，然後營業員把合同歸檔。

     這幾個要點都是和通信公司的商業利益直接相關的，沒有牽涉到任何系統實作方式。如果不考慮通信公司内部的業務規範，實作方案可以有幾十種，下面列舉兩種：

      1：SIM卡發給營業員，使用者入網的時候，選擇一個号碼，然後付錢。營業員把SIM卡号碼和電話号碼輸入系統，在交換網絡上進行注冊，這個SIM卡就可以通話了。然後各種費用記入各人帳戶，合同歸檔。

     2：SIM卡在下發給營業員之前，先在交換網絡上和注冊，并且已經預先設定了一定的話費。使用者選擇了這個号碼，付錢之後直接SIM卡拿走就可以打電話了。營業員事後再輸入使用者的合同資料，費用計入各人帳戶，合同歸檔。

     這兩種方案在實作過程上是不同的，是以具有不同的功能點。比如第二種方案中的SIM卡在出售之前是可以進行通話的，是以必須對這樣的号碼的通話費用進行監控，這個功能在第一種方案中是根本不需要的。并且兩種方案在帳目的核對方式上差別也是比較大的。這兩種方案是不同的功能點的集合，他們完成的是同一個業務需求。

      系統在開發階段如果沒有保留使用者的業務需求情況，而是隻留下一個功能點的清單，會給維護人員帶來成很大的困難。維護人員無法從這樣一堆功能點中發現最初的需求是什麼樣子。各位可以試試，假設我們忘記上面的四個需求要點，隻看下面的某個實作方案，從這個複雜的實作過程中，我們很難知道使用者現在的需求到底是什麼。一旦需求發生了變化，這些功能點就會出錯，或者是功能點的時序發生意料不到的錯誤，也許帳目核對不上了，也許是使用者拿走的SIM卡不能打電話了。

     看不見需求在哪裡，不知道手裡這段代碼會觸動需求的哪根神經。維護人員的痛苦大部分來源于此。

   “不要緊，客戶記得自己的需求。”但是客戶通常不懂技術，即使他們懂技術，他們也不知道系統是如何實作的。如果開發人員依靠客戶提出新需求的解決方案，結果就是讓軟體工程變成“生物工程”。到最後是錢基本花光，人基本累死，甲乙雙方感情基本破裂。

      軟體開發必須劃分成幾個過程，但是各個步驟應該有一個統一的核心——業務需求。

     在需求調查階段要搞清楚使用者的業務需求，為了達到這個目的，可以提問回答，可以對使用者進行跟蹤采訪，或者做一個demo給使用者看看，最終的目的是為了搞清楚使用者在做什麼事，遇到了什麼問題，程式應該去解決什麼問題，這就是這一階段的工作。

      然後開始進行設計，設計系統的邏輯結構和實體結構，邏輯結構要符合需求的概念，各個對象互相調用要能夠實作需求中的業務過程，同時實體結構劃分合理，符合實際的分布狀況，可以達到要求的的性能，業務過程的實體運作方式合理高效。這一階段仍然是以業務需求為核心。

     接下來是編碼。首先是編寫一些基礎設施，比如網絡通信、資料庫、檔案的讀寫、分布式計算，這些基礎設施和業務需求沒有什麼關系，有很多現成的架構，借助這些架構我們可以盡快度過這個黑暗的階段。然後編寫業務對象，這時候業務需求中的一些概念逐漸出現在代碼中。接着這些業務對象串接起來，實作業務過程，現在業務需求又回到了人們的視野當中。業務需求是什麼，如何實作，在這裡一目了然。最後将這些過程在UI或者接口中調用，将功能提供給使用者或者别的系統。

     測試更是要圍繞着業務需求來進行，正常的業務流程應該産生正常的結果，如果缺少某個資源，或者輸入了不合适的資料，應該出現業務含義明确的異常。并且系統的業務對象是處在一個獨立的層次上，與UI和基礎設施沒有很大的關聯，這樣可以友善的采用自動化的測試方法。

     這樣的系統維護起來一定少很多痛苦。