需求工程？？？

需求工程？？？
鄧 輝
軟件是一種商品，既然是一種商品，就必然要滿足購買者的需要。是的，人們是不會爲那些不能滿足自己需要的東西付錢的。另外，開發軟件是需要成本的。只有那些成本低，並且能滿足客戶需要的軟件產品才能夠爲軟件企業帶來利潤。因此，要想使軟件能夠爲軟件企業帶來最大的效益，一個首要的前提條件就是要弄清楚客戶需要的到底是什麼，也就是說，要搞清楚用戶需求。弄清楚了用戶需求，不僅可以使得所開發出來的軟件確實是用戶想要購買的，並且還可以避免由於開發那些多餘的特性而造成的成本增加。開發出符合需求的軟件是每一個軟件企業在市場競爭中取得勝利的最爲重要的條件。
於是，許多軟件企業就把軟件開發活動中和需求相關的活動放在了最爲重要的一個位置上。這些企業對項目成員進行了大量的需求獲取、分析、記錄方面的培訓，試圖以工程化的方法規範需求的開發，甚至專門成立了一個獨立的需求開發團隊來爲項目的後續開發提供一個穩定、清晰、明確的需求集。重視需求這種想法本身是非常正確的，遺憾的是，很多企業在把“重視需求”這種理念落實到具體的實施中去時卻犯了很多嚴重的錯誤。這些錯誤足以使“重視需求”成爲一句空話。下面，我們來對這些嚴重錯誤逐條進行分析。
錯誤認識一：試圖預先固化需求
“軟件需求無法預先固化，並且隨時可能發生變化”已經是現在整個軟件工程界的共識。但是，還是有很多軟件企業試圖在項目開展實際的開發工作前固化需求。爲什麼呢？因爲如果能夠在實際的項目開發前把需求固化下來，那麼就會大大降低以後由於需求變化帶來的各種風險和問題。然而，無數的實踐表明，在捕獲需求方面，無論你多麼的刻苦論你多麼的一絲不苟，無論你做多麼什麼的思考，無論你付出了多少努力，需求總是會變化的。
需求的易變性是由激烈的市場競爭和軟件本身的特性決定的。客戶企業很少會在軟件交付的那一刻還保持原始的需求不變。客戶企業要想在激烈的市場競爭中生存下去，就必要根據市場的變化來調整自己的業務流程，而這種變化就相應地反映到所需要的軟件當中。另外，由於軟件的不可見性，有時客戶自己都不是非常清楚自己想要的是什麼，就更不用說把需求明確、清楚的表達出來了。在大多數情況下，只有在見到了真正運行的系統後，客戶才知道自己想要的到底是什麼。
因此，當我們在項目進入實際的開發之後發現需求變化時，不要再發出“需求沒有做好”這樣的感慨了。因爲易變性是需求的根本特性。如果真要重視需求的話，首先就不應該試圖在一開始就把固化下來。重視需求是一項持續的活動，試圖預先固化需求的做法其實是一種偷懶的行爲。
錯誤認識二：需求的記錄必須要規範、詳盡
這句陳述本身沒有錯誤，如果需求是以規範形式記錄的，那麼其他人就會比較容易理解，這樣也有利於交流。這裏很關鍵的一點是，你什麼時候去規範地記錄需求，也就是規範地記錄需求的時機。很多需求分析團隊總是試圖一開始就以use case圖的方式記錄需求。談論的內容也往往是形式多於實質。他們在preconditions、postconditions、actors、secondary actors以及許多在目前階段根本不重要的事情上討論的火熱。
其實對於use case說，最爲重要的一點就是要保持簡單。在一開始根本無需關注形式，隨意地記錄下來就行了。也無需過多地關注細節，細節只有到了後期纔有用。更不要試圖去記錄所有的use case，正如前面所述，這是一項不可能完成的任務。因爲需求很可能會發生變化，正因爲它要變化，我們根本無需一開始就記錄下它的細節。捕獲需求的細節應該在一個合適時機，一般來講就是“在開始實現該需求的前幾天。”而最爲規範、準確的需求就是可以自動運行的驗收測試用例（這些測試用例完全可以以客戶非常容易理解的語言編寫，這取決於是否真正重視需求），這些測試用例不但非常精確地描述了系統應該完成什麼功能，而且還驗證了這些功能是否被正確的實現，並時刻和實現保持同步。
那些一開始就以非常規範的形式、非常詳盡地記錄需求的做法，最終只會產生一些和實際需求完全失去同步的文檔。這樣的文檔有什麼價值呢？
錯誤認識三：需求的分析和實現是獨立的活動
“需求的分析和實現是不相干的活動”這句話聽起來好像沒有什麼問題，需求的獲取和分析是要搞清楚“要做什麼”，搞清楚後做（實現）就是了。不是嗎？問題沒有這麼簡單。
要想真正地把需求搞清楚，和客戶頻繁、有效地交流和溝通固然重要，但是從交流和溝通中得到的信息只能作爲一個大概的需求。要想真正把這些需求弄清楚出來，就必須去實現它們。只有在實現中，很多東西才能明朗。只有在實現中才能加深對需求的理解，甚至啓發出新的需求，幫助客戶取得優勢，獲取雙贏。只有在實現中，才能發現更好的需求分解方式，從而使得整個系統的架構朝着更好的方向演化。
所以說，“弄清楚需求”是一項持續地活動，是一項測試驅動、反饋驅動的迭代式活動。那些試圖把需求分析限制、固定在某個階段的做法，根本不能稱之爲“重視需求”的做法。
什麼纔是注重實效的需求工程？
 判斷某項活動是不是符合工程化的做法，並不是以該項活動的結果是否以某種規範或者流行的方式來描述和記錄爲標準的，更不是以在描述和記錄中出現多少專業名詞爲標準的。那些一開始就試圖固化需求、並用“規範、漂亮”的use case圖來記錄需求的做法不是工程化的做法，那些試圖把需求的分析和實現完全隔離的做法更不是工程化的做法。判斷某項活動是不是工程化的首要標準應該是：該項活動的過程是不是符合它所涉及的領域的基本規律。只有符合了領域的基本規律，才能真正的降低這項活動的成本和風險，纔是真正的工程化做法。
 對於軟件領域來說，我們在進行需求方面的活動時，就必須要按照軟件本身的特性和規律辦事。和其他領域相比，軟件的最爲獨特的特性就是：幾乎無成本的構建和可逆性。正是這兩個特性使得我們無需像其他領域那樣在前期投入大量的精力和資金去證明所作出來的產品是正確的、可靠的（想想飛機工程中的大量原型試驗、風洞試驗等）。
是的，我們無需去用程序證明的方法去證明軟件是正確的，確實也沒有任何一個軟件企業會去這麼做，爲什麼呢？因爲我們基本上可以無成本的把軟件製造出來（compile、link），然後去驗證結果，如果有問題再更改軟件（可逆性）。這裏的驗證是必需的，是爲了證明程序是否按照期望的行爲運作，這是一個探索、加深理解的過程（在這個過程中，很有可能發現對需求的理解錯誤）。我們越早的開始這個過程，越頻繁的實施這個過程，就越能夠降低軟件開發的成本和風險。那些試圖一開始就捕獲、固化所有需求並把分析和實現隔離的做法，纔是非常高風險的做法。
 另外，軟件代碼的編寫並不是一件無足輕重的活動，相反它應該是整個軟件開發活動的核心。因爲代碼的編寫不是一項體力勞動，而是一項集分析、設計、實現、改進、驗證於一體的綜合智力活動。正是在這個活動中，我們才能加深對需求的理解，甚至可以說是真正理解需求。正是在這個活動中，我們才能使得軟件具有更好的可逆性，從而進一步簡單軟件開發的成本。我們的項目開發人員在學習溝通、交流技能的同時，更要加強軟件技術方面的技能，只有這樣才能更好的挖掘出埋藏在需求底層的抽象，才能做到需求概念元素和設計實現元素間的一一映射，才能使得我們的程序更加模塊化，更加具有表達力，更加易於維護和擴展，更加具有“軟”性，從而爲迎接需求的變化打下一個良好的基礎。
 C++之父Bjarne Stroustrup在設計C++語言時，堅持這樣一個哲學觀點：“尊重一個羣體而不尊重這個羣體中的每一個個體，那麼尊重這個羣體就是一句空話。”同樣，重視軟件質量、重視軟件需求，但是卻不遵循軟件本身的特性和規律，忽視需求獲取活動的特性和規律，不重視組成軟件質量的一句句代碼的質量，那麼重視軟件質量、重視軟件需求也是一句空話。
 因此，我們在進行軟件開發活動中，如果在關注形式和過程的同時，更多地反思一下這些形式和過程本身的質量，更多地關注一下如何才能提高真正的軟件質量――可以更快、更好地滿足客戶的需求，使客戶滿意，而不是軟件開發活動是否嚴格符合某個過程。並把這些關注真正落實到日常的每一項活動之中，這纔是真正注重實效的工程化方法。