在美國紐約有一個“失敗產品博物館”，里面展出的“失敗產品”高達8萬多件，其中不乏大公司功能強大、新奇的產品。博物館提供了這樣一組數字：美國每年推向市場的新產品達54000多種，而真正受到青睞的只有20%。產品失敗的原因有很多，但最主要的就是產品功能與消費者的需求相去甚遠。

　　從需求分析到原形設計再到編程、測試、應用維護，在軟件產品的全生命周期內，需求作為根源和基礎，它的優(yōu)劣實際上決定了一個軟件產品或者軟件研發(fā)應用項目的成敗。

　　疲于應對總在變化的需求

　　“我是在需求報告上簽字確認了，可是我并沒有時間讀完這么厚的文檔，是你們要我簽字的。”不少開發(fā)團隊經常聽到他們的客戶——業(yè)務部門說這樣的話，尤其是客戶對軟件感到不滿意，需要提修改意見的時候。

　　就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。需求是軟件項目的根源，對產品的影響最大。好的開始等于成功的一半。從軟件項目一開始，就要有正確的輸入，也就是正確的用戶需求。

　　如何才能做到呢?首先要討論的就是做需求的工具。當前在軟件項目的需求分析階段最常用的工具是什么呢?Word!對，就是Word文檔。技術人員通常是通過與業(yè)務人員交流等方式熟悉業(yè)務流程，根據自己頭腦中對某個業(yè)務的理解，按照自己的邏輯，用系列的Word文檔來描述業(yè)務需求。由于一個軟件開發(fā)項目都是要多人完成，在寫需求的時候，由于每個人的邏輯和習慣不一樣，以及在共享協(xié)同方面的不完善，往往導致無效需求，這是導致項目失敗的根源。

　　我們以銀行ATM機的程序為例，來說明無效需求是怎樣產生的。ATM機的需求怎么寫?一般來講，簡而言之，開發(fā)人員會按照業(yè)務流程來寫，第一步是讀卡;第二步是在讀卡的時候讀用戶身份信息，給客戶一個窗口輸入密碼;第三步驗證;第四步開始有分支，給客戶操作界面，往下再按照細化的業(yè)務流程繼續(xù)。但問題是項目合作中并不是每個開發(fā)人員都會嚴格按照這種順序來寫，并相互共享。某個開發(fā)人員他可能是按照自己想的業(yè)務邏輯先寫一遍，比如他本來已經寫了16條需求，第8條到第10條是描寫查詢的，第10條到12條是描寫取款的，12條到16條是寫轉賬的，但該開發(fā)人員可能寫著寫著突然發(fā)現(xiàn)在取款方面應該讓客戶更方便一點，于是在16條之后又產生了一條有關取款的需求，這樣可能就會有重復，有遺漏，造成需求無效。

　　而且因為在一個軟件項目進行的過程中，普遍的是業(yè)務需求在不斷變化：一邊是業(yè)務需求本身就在不斷變化，一邊是需求和需求之間又互相關聯(lián)引導。這對項目團隊做出正確有效的需求提出了巨大的挑戰(zhàn)。

　　長篇累牘的Word文檔如何能做到有效的需求確認和變更管理呢?康普科緯迅公司(以下簡稱Compuware)中國區(qū)技術經理馬怡驄的答案是將需求結構化，并定義好需求之間的約束關系，從而做好需求管理。這也正是Compuware日前發(fā)布的最新的業(yè)務需求管理解決方案Optimal Trace 5.1的核心所在。

　　微軟的Visual就是結構化。馬怡驄說，如果有人已經用Visual來寫需求，那么說明他已經比還在用Word的人進步了，因為他已經開始使用結構化需求。但是很遺憾，Visual的結構化需求默認沒有約束關系，如果再請幾個需求管理的專家把約束關系寫進去，這就有了一半Optimal Trace的意思了。馬怡驄說，Optimal Trace不光描述需求，它還可以描述需求之間的關系和影響力，所以當需求變動的時候，開發(fā)人員可以輕易地追溯到還有哪幾個需求要重新查看編寫。另外，Optimal Trace還支持在需求定義完畢后，生成測試用例，有針對性地對這些需求做出驗證。這對于測試人員來說也是一個福音。

　　對于新版本的重要性，Compuware產品解決方案副總裁John Williams表示，一方面是結構化需求，另一方面它是一個開放性的架構，可以跟第三方的測試工具和測試管理工具進行相應的集成，包括需求的版本管理工具在內。這樣用戶可以看到需求變化帶動的整個軟件的基線變化，以及針對性的解決辦法，告訴用戶不同需求版本要在具體什么地方產生變化，并提供適用相應變化的測試用例。結構化需求，并對其進行更有效管理，可以給業(yè)務市場人員的訪問、管理團隊的審批和技術團隊的實現(xiàn)提供更高的靈活性。

　　行百里者半九十。在整個軟件研發(fā)過程中，保持整個團隊對需求一以貫之的關注、確保所有開發(fā)活動都可以跟蹤到最初的用戶需求無疑是極為關鍵的。

　　用封裝的平臺解決問題

　　在整個軟件的生命周期中，要確保各項工作和需求之間的一致性，需求管理就顯得格外重要。對于這一點，從事了十幾年軟件研發(fā)的創(chuàng)恒信軟件有限公司(以下簡稱創(chuàng)恒信)技術總監(jiān)呂建海深有感觸。而除了需求管理之外，根據呂建海的十幾年開發(fā)經驗，他表示搭建一個良好高效的應用開發(fā)平臺，應需而變，也是實現(xiàn)敏捷開發(fā)的重要保障。

　　應用軟件開發(fā)平臺的構建一般基于底層的開發(fā)語言和一些開發(fā)框架進行，進行一些比較底層的封裝，制訂一系列軟件開發(fā)的模板或規(guī)則，要求軟件開發(fā)人員按照應用開發(fā)平臺的規(guī)則進行應用實現(xiàn)。應用軟件開發(fā)平臺一般都得到了若干個項目的應用，具備很強的穩(wěn)定性和可靠性，同時能實現(xiàn)大量的應用組件的重用，又能規(guī)范軟件開發(fā)的編碼規(guī)范，極大地增強了項目管理人員的控制能力，是當前大多數公司沿用的項目開發(fā)方法。如用友(600588行情，股吧，信息化)的UAP、金蝶的BOS、SAP 的Netwaver都是用這種方法開發(fā)的。管理軟件平臺化是近兩年來很熱的話題，也是趨勢所在。 　

　　從系統(tǒng)集成商轉型而來的創(chuàng)恒信，曾經自主開發(fā)過電力企業(yè)的ERP系統(tǒng)、工作流軟件、電子政務系統(tǒng)。有了多年的項目經驗積累之后，創(chuàng)恒信自主開發(fā)了一套Web應用軟件開發(fā)平臺eFlow，將軟件開發(fā)可視化，進行高度封裝，通過設置來實現(xiàn)應用軟件的各項功能，實現(xiàn)軟件開發(fā)的無編碼化。 　　現(xiàn)有市場的Web應用開發(fā)平臺一般都依附于特定應用領域和特定行業(yè)。所有這些Web應用開發(fā)平臺基本上都基于底層語言進行開發(fā)設計，涉及大量的編碼，對軟件開發(fā)人員的要求比較高。而eFlow應用開發(fā)平臺作為一個高度封裝的Web應用開發(fā)系統(tǒng)，其開發(fā)系統(tǒng)中內置了門戶系統(tǒng)、工作流管理系統(tǒng)、電子表單管理系統(tǒng)等，提供了一個通用的平臺組件，而主要的應用開發(fā)由電子表單管理系統(tǒng)和工作流管理系統(tǒng)來完成，其門戶及展現(xiàn)由信息門戶系統(tǒng)來完成。

　　配置后的敏捷開發(fā)

　　利用eFlow應用開發(fā)平臺進行開發(fā)，并不需要開發(fā)人員懂得J2EE的各種技術，只須使用瀏覽器，開發(fā)人員就可以像設計網頁一樣完成最終的應用開發(fā)，其開發(fā)效率相對于使用傳統(tǒng)的SSH(STRUTS + SPRING + HIBERNATE)快一個數量級。應用開發(fā)使用IE瀏覽器完成，應用的運行可以實現(xiàn)跨瀏覽器平臺應用，在Linux上的Firefox上也可以運行。

　　eFlow應用開發(fā)平臺涵蓋了底層引擎、應用組件和上層基礎系統(tǒng)，能夠做到配置化實現(xiàn)各種復雜的Web應用，其總體結構如下：

　　eFlow應用開發(fā)平臺以組件構建的方式實現(xiàn)軟件開發(fā)，大多數應用無需編寫代碼，對于復雜應用，也只需編寫少量腳本，就可以實現(xiàn)復雜的應用。平臺提供基于瀏覽器的專用應用設計工具，進行應用的開發(fā)設計、測試、跟蹤、調試以及軟件維護。平臺根據分層設計的開發(fā)思路進行封裝，同時引入了大量的構件，開發(fā)人員無需手工修改Java類、表現(xiàn)層的頁面、后臺邏輯等，直接通過開發(fā)工具進行可視化配置降低了開發(fā)人員的學習難度。通過系統(tǒng)內置的設計工具，基于瀏覽器進行模板設計、模塊設計以及流程設置，能夠大幅度地減少開發(fā)工作量，提高了開發(fā)效率。而同時由于在開發(fā)實現(xiàn)過程中，壓縮了編碼的工作量，應用跟蹤調試的時間也相應減少，整個應用實現(xiàn)的時間相應減少，提高了應用的可維護性和軟件的穩(wěn)定性。