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

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

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