需求管理之被遺忘的需求
”專家說：“這種牛是能夠造出來的，如今有基因project。”隊長說：“好吧，你給這造幾頭這種牛。”於是專家找到了生物實驗室。讓生物實驗室的人搞一個基因project，把牛造出來。
於是project浩大，投資無法保證，合作多半是不愉快的收場。
現實世界裏非常多人分析需求的過程就相似於這位專家。他們把註意力放在用戶提出的功能點上。而對用戶的實際需求沒有興趣。有不少軟件公司和程序猿，事實上都在做相似的基因project。假設這個專家把註意力放在生產隊長的業務需求上，而不是太在乎他提出的功能點。他會說：“我認識一個賣拖拉機的，能夠帶你去看看。”
軟件的維護為什麽這麽痛苦。一個非常重要的原因在於：需求已經被遺忘了。
需求是對用戶具有直接商業價值的活動。而不應該牽涉到不論什麽的功能實現方式。實現同一個需求能夠使用多個方案。每一個方案有自己的功能方式，在某個方案中至關重要的功能點，或許在還有一個方案中根本無關緊要。
瀑布式的開發過程，首先是由一批懂得用戶業務的專家去調查用戶的需求，分析出這個系統應該具有哪些功能，形成一個非常關鍵的文件——《xxx系統需求規格說明書》。客戶認可了這個《說明書》，在上面簽字蓋章，增加合同附件，到時候項目驗收就以此為準。
這時候。需求就已經分解成了一個個功能點，從這時候開始，需求本身就漸漸被人們遺忘。設計人員環繞著這些功能點進行工作，考慮用什麽樣的技術手段把功能點制造出來。
功能點的制作細節形成了另外一份關鍵的文件——《xxx項目設計規格說明書》。這個《設計規格說明書》交給程序猿去進行編碼。
這種做法在開發中已經形成了非常大的問題。
首先。面對這種《需求規格說明書》，設計人員已經無法知道最初的需求是什麽。假如這個《需求規格說明書》中的功能點沒有出現互相矛盾的情況。而他們串起來卻和用戶的需求不同。設計人員沒辦法發現這種情況。編碼人員也無法發現。
假如測試也是依據這個《需求規格說明書》來做的。測試人員也發現不了。直到最後客戶看見這個程序展如今他們面前。
需求的分析須要在隨後的過程中不斷得到反饋，傳統的過程不是沒有反饋，而是反饋的時間太長了。
其次，因為設計人員已經無法知道主要的需求是什麽，也就無法對業務進行建模。
這種需求分析是以開發者的須要為核心的，可是結果恰恰妨礙了開發者對需求的理解。
假設開發者對用戶的業務過程不甚了解，他們僅僅有一種選擇：不要試圖去了解需求了，直接依照這些功能點做吧。
於是，他們建立的對象模型就不是以需求為核心的。而是以功能、界面為核心的。我見到過非常多這種系統，開發者確實有非常高的抽象思維水平，程序中設計了非常巧妙的控制器和界面，能夠非常方便的進行開發和變更。只有業務層的對象非常簡陋，一旦發生實際業務的變更。仍然十分辛苦。
更大的困難發生在維護程序的時候。
假設有一個移動通信公司須要制造一個系統，用來解決手機用戶入網的問題。這個需求有以下幾個要點：
1：用戶付錢，得到一個SIM卡和一個號碼，把這個SIM卡裝到手機裏就能夠通話。
2：營業員收的錢要記錄下來，提供給稽核人員，現金和帳目必須是平的。
3：用戶付的話費要劃入他自己的帳戶，能夠打印票據。
4：用戶要在入網合同上簽字，然後營業員把合同歸檔。
這幾個要點都是和通信公司的商業利益直接相關的。沒有牽涉到不論什麽系統實現方式。
假設不考慮通信公司內部的業務規範，實現方案能夠有幾十種，以下列舉兩種：
1：SIM卡發給營業員。用戶入網的時候。選擇一個號碼。然後付錢。
營業員把SIM卡號碼和電話號碼輸入系統，在交換網絡上進行註冊，這個SIM卡就能夠通話了。
然後各種費用記入各人帳戶，合同歸檔。
2：SIM卡在下發給營業員之前。先在交換網絡上和註冊。而且已經預先設置了一定的話費。
用戶選擇了這個號碼，付錢之後直接SIM卡拿走就能夠打電話了。
營業員事後再輸入用戶的合同資料，費用計入各人帳戶。合同歸檔。
這兩種方案在實現過程上是不同的。因此具有不同的功能點。比方另外一種方案中的SIM卡在出售之前是能夠進行通話的，所以必須對這種號碼的通話費用進行監控。這個功能在第一種方案中是根本不須要的。而且兩種方案在帳目的核對方式上差別也是比較大的。這兩種方案是不同的功能點的集合。他們完畢的是同一個業務需求。
系統在開發階段假設沒有保留用戶的業務需求情況，而是僅僅留下一個功能點的列表。會給維護人員帶來成非常大的困難。維護人員無法從這樣一堆功能點中發現最初的需求是什麽樣子。
各位能夠試試，假設我們忘記上面的四個需求要點。僅僅看以下的某個實現方案。從這個復雜的實現過程中。我們非常難知道用戶如今的需求究竟是什麽。一旦需求發生了變化，這些功能點就會出錯，或者是功能點的時序發生意料不到的錯誤，或許帳目核對不上了，或許是用戶拿走的SIM卡不能打電話了。
看不見需求在哪裏，不知道手裏這段代碼會觸動需求的哪根神經。維護人員的痛苦大部分來源於此。
“不要緊，客戶記得自己的需求。
”可是客戶通常不懂技術，即使他們懂技術，他們也不知道系統是怎樣實現的。
假設開發者依靠客戶提出新需求的解決方式，結果就是讓軟件project變成“生物project”。到最後是錢基本花光，人基本累死，甲乙兩方感情基本破裂。
軟件開發必須劃分成幾個過程，可是各個步驟應該有一個統一的核心——業務需求。
在需求調查階段要搞清楚用戶的業務需求，為了達到這個目的。能夠提問回答，能夠對用戶進行跟蹤採訪，或者做一個demo給用戶看看，終於的目的是為了搞清楚用戶在做什麽事。遇到了什麽問題，程序應該去解決什麽問題，這就是這一階段的工作。
然後開始進行設計，設計系統的邏輯結構和物理結構，邏輯結構要符合需求的概念。各個對象互相調用要能夠實現需求中的業務過程。同一時候物理結構劃分合理，符合實際的分布狀況，能夠達到要求的的性能，業務過程的物理執行方式合理高效。
這一階段仍然是以業務需求為核心。
接下來是編碼。
首先是編寫一些基礎設施，比方網絡通信、數據庫、文件的讀寫、分布式計算，這些基礎設施和業務需求沒有什麽關系，有非常多現成的框架，借助這些框架我們能夠盡快度過這個黑暗的階段。
然後編寫業務對象，這時候業務需求中的一些概念逐步出如今代碼中。接著這些業務對象串接起來，實現業務過程，如今業務需求又回到了人們的視野其中。
業務需求是什麽，怎樣實現，在這裏一目了然。最後將這些過程在UI或者接口中調用。將功能提供給用戶或者別的系統。
測試更是要環繞著業務需求來進行，正常的業務流程應該產生正常的結果，假設缺少某個資源，或者輸入了不合適的數據。應該出現業務含義明白的異常。而且系統的業務對象是處在一個獨立的層次上，與UI和基礎設施沒有非常大的關聯，這樣能夠方便的採用自己主動化的測試方法。
這種系統維護起來一定少非常多痛苦。
需求管理之被遺忘的需求