在美國紐約有一個“失敗產(chǎn)品博物館”，里面展出的“失敗產(chǎn)品”高達8萬多件，其中不乏大公司功能強大、新奇的產(chǎn)品。博物館提供了這樣一組數(shù)字：美國每年推向市場的新產(chǎn)品達54000多種，而真正受到青睞的只有20%。產(chǎn)品失敗的原因有很多，但最主要的就是產(chǎn)品功能與消費者的需求相去甚遠。
　　從需求分析到原形設計再到編程、測試、應用維護，在軟件產(chǎn)品的全生命周期內(nèi)，需求作為根源和基礎，它的優(yōu)劣實際上決定了一個軟件產(chǎn)品或者軟件研發(fā)應用項目的成敗。
　　疲于應對總在變化的需求
　　“我是在需求報告上簽字確認了，可是我并沒有時間讀完這么厚的文檔，是你們要我簽字的?！辈簧匍_發(fā)團隊經(jīng)常聽到他們的客戶——業(yè)務部門說這樣的話，尤其是客戶對軟件感到不滿意，需要提修改意見的時候。
　　就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。需求是軟件項目的根源，對產(chǎn)品的影響最大。好的開始等于成功的一半。從軟件項目一開始，就要有正確的輸入，也就是正確的用戶需求。
　　如何才能做到呢?首先要討論的就是做需求的工具。當前在軟件項目的需求分析階段最常用的工具是什么呢?Word!對，就是Word文檔。技術人員通常是通過與業(yè)務人員交流等方式熟悉業(yè)務流程，根據(jù)自己頭腦中對某個業(yè)務的理解，按照自己的邏輯，用系列的Word文檔來描述業(yè)務需求。由于一個軟件開發(fā)項目都是要多人完成，在寫需求的時候，由于每個人的邏輯和習慣不一樣，以及在共享協(xié)同方面的不完善，往往導致無效需求，這是導致項目失敗的根源。
　　我們以銀行ATM機的程序為例，來說明無效需求是怎樣產(chǎn)生的。ATM機的需求怎么寫?一般來講，簡而言之，開發(fā)人員會按照業(yè)務流程來寫，第一步是讀卡;第二步是在讀卡的時候讀用戶身份信息，給客戶一個窗口輸入密碼;第三步驗證;第四步開始有分支，給客戶操作界面，往下再按照細化的業(yè)務流程繼續(xù)。但問題是項目合作中并不是每個開發(fā)人員都會嚴格按照這種順序來寫，并相互共享。某個開發(fā)人員他可能是按照自己想的業(yè)務邏輯先寫一遍，比如他本來已經(jīng)寫了16條需求，第8條到第10條是描寫查詢的，第10條到12條是描寫取款的，12條到16條是寫轉(zhuǎn)賬的，但該開發(fā)人員可能寫著寫著突然發(fā)現(xiàn)在取款方面應該讓客戶更方便一點，于是在16條之后又產(chǎn)生了一條有關取款的需求，這樣可能就會有重復，有遺漏，造成需求無效。
　　而且因為在一個軟件項目進行的過程中，普遍的是業(yè)務需求在不斷變化：一邊是業(yè)務需求本身就在不斷變化，一邊是需求和需求之間又互相關聯(lián)引導。這對項目團隊做出正確有效的需求提出了巨大的挑戰(zhàn)。
　　長篇累牘的Word文檔如何能做到有效的需求確認和變更管理呢?康普科緯迅公司(以下簡稱Compuware)中國區(qū)技術經(jīng)理馬怡驄的答案是將需求結構化，并定義好需求之間的約束關系，從而做好需求管理。這也正是Compuware日前發(fā)布的最新的業(yè)務需求管理解決方案Optimal Trace 5.1的核心所在。
　　微軟的Visual就是結構化。馬怡驄說，如果有人已經(jīng)用Visual來寫需求，那么說明他已經(jīng)比還在用Word的人進步了，因為他已經(jīng)開始使用結構化需求。但是很遺憾，Visual的結構化需求默認沒有約束關系，如果再請幾個需求管理的專家把約束關系寫進去，這就有了一半Optimal Trace的意思了。馬怡驄說，Optimal Trace不光描述需求，它還可以描述需求之間的關系和影響力，所以當需求變動的時候，開發(fā)人員可以輕易地追溯到還有哪幾個需求要重新查看編寫。另外，Optimal Trace還支持在需求定義完畢后，生成測試用例，有

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html