【正文】 估計(jì)類(lèi)似的事情還會(huì)繼續(xù)發(fā)生，每發(fā)生一次就損失成百上千萬(wàn)元。我也是在人家請(qǐng)我商量對(duì)策的時(shí)候，才知道有這樣的事情。 ”A 的那位項(xiàng)目經(jīng)理為此每天愁眉苦 臉，他的上司請(qǐng)來(lái)幾位參謀商量對(duì)策（包括我在內(nèi)），設(shè)法把事情搞定。E 把網(wǎng)管軟件交付給 A，A 付清了 E 的開(kāi)發(fā)費(fèi)用，再把網(wǎng)管軟件交付給 D，D 再賣(mài)給客戶第 4 章 需求開(kāi)發(fā)與需求管理Page 5 of 34F（某地電信局）。 ”A 想了想覺(jué)得機(jī)會(huì)難得，于是向 C 申請(qǐng)立項(xiàng)。D 是公司的一個(gè)銷(xiāo)售機(jī)構(gòu)。我就把它寫(xiě)成案例，現(xiàn)炒現(xiàn)賣(mài)。沒(méi)有軟件工程書(shū)籍不強(qiáng)調(diào)需求的重要性，也幾乎沒(méi)有軟件開(kāi)發(fā)人員不知道需求的重要性。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。人們常問(wèn)：“需求、設(shè)計(jì)、編程、測(cè)試四者究竟哪個(gè)重要？”這個(gè)問(wèn)題不好回答。有個(gè)射擊教練教出了不少神槍手，那些神槍手的槍法雖然很準(zhǔn)，但老是打錯(cuò)人，有的甚至拿槍來(lái)自殺。令人遺憾的是大多數(shù)軟件工程教科書(shū)喜歡以學(xué)術(shù)的形式論述需求，大講結(jié)構(gòu)化分析或面向?qū)ο蠓治?，并給出一堆模型和符號(hào)。這不是個(gè)別的荒唐現(xiàn)象，這差不多成了國(guó)內(nèi)軟件業(yè)的痼疾。需求工程是國(guó)內(nèi)大學(xué)軟件工程教育最薄弱的環(huán)節(jié)之一，這種教育模式下誕生的軟件工程師會(huì)有這樣的習(xí)慣：他們?cè)陂_(kāi)發(fā)產(chǎn)品時(shí)并不清楚究竟該做什么，但卻在一直忙碌不停地開(kāi)發(fā)。為了你的前途，你應(yīng)該認(rèn)真學(xué)習(xí)需求工程。可見(jiàn)需求工程的研究者似乎并不清楚實(shí)踐者的真正需求，真讓人哭笑不得。所以如果只有一些零碎的對(duì)話、資料或郵件，你就以為自己已經(jīng)掌握了需求，那是自欺欺人。因?yàn)樾枨笫钱a(chǎn)品的根源，需求工作的優(yōu)劣對(duì)產(chǎn)品影響最大。此工作一旦做錯(cuò)，將會(huì)給系統(tǒng)帶來(lái)極大的損害，并且以后對(duì) 它修改也極為困難。在我為本公司軟件開(kāi)發(fā)人員寫(xiě)需求工程培訓(xùn)教材時(shí)，恰好遇到公司里一群高智商的開(kāi)發(fā)人員集體犯需求觀念錯(cuò)誤的事情。C 是公司的 項(xiàng)目管理機(jī)構(gòu)，負(fù)責(zé)立項(xiàng)、結(jié)項(xiàng)和研發(fā)經(jīng)費(fèi)管理。 ”D 對(duì) B 和 A 講：“ 你們把接入服 務(wù)器和網(wǎng)管軟件做好，我們負(fù)責(zé)賣(mài)，掙了錢(qián)大家一起分。B 的接入服務(wù)器并不成熟，老在變，三方折騰了好久，最終 E 用了一年時(shí)間把接入服務(wù)器的網(wǎng)管軟件做出來(lái)了。 ”A 很憤怒，怨天不公：“我們辛苦了一年，又花了很多錢(qián)，可是產(chǎn)品做完了卻沒(méi)人要， 豈有此理！”禍不單行的是，C 來(lái)找 A 的麻煩：“ 你們的項(xiàng)目延期半年多了，經(jīng)費(fèi)也用光了， 請(qǐng)盡快結(jié)束項(xiàng)目。圖 41 本案例 6 個(gè)機(jī)構(gòu)的關(guān)系圖讀者聽(tīng)了這個(gè)故事肯定既迷糊又驚詫?zhuān)骸巴郏蠊臼沁@樣開(kāi)發(fā)產(chǎn)品的??？” 。最可悲的是，相關(guān)責(zé)任人關(guān)心的是如何把事情“搞定” ，而不是深刻反思。我自己也是這么過(guò)來(lái)的，但愿以后不再犯類(lèi)似的錯(cuò)誤。如果軟件是面向企業(yè)用戶的，那么客戶與最終用戶通常不是同一個(gè)人。客 戶并不依賴(lài)我們，而我 們卻依 賴(lài)客戶。從未有人曾在與客戶的爭(zhēng)辯中獲勝。客戶所說(shuō)的需求一般比較宏觀，更詳細(xì)的需求應(yīng)該從最終用戶那里獲取。這種做法差不多成了電信行業(yè)的“事實(shí)標(biāo)準(zhǔn)” 。跟這些客戶打交道，開(kāi)發(fā)方千萬(wàn)別派出只會(huì)吹牛皮的“酒囊飯袋”之輩。即使最終用戶不是上帝，也算是“上帝”的“親戚” ，同樣怠慢不得。 ”除了客戶和最終用戶之外，軟件開(kāi)發(fā)方不能疏忽另一類(lèi)用戶——“間接用戶” ，千萬(wàn)別“大意失荊州”啊。所以國(guó)家財(cái)政部就是所有財(cái)務(wù)軟件的間接用戶，它不僅不付錢(qián)給財(cái)務(wù)軟件開(kāi)發(fā)商，反而要收取鑒定費(fèi)、手續(xù)費(fèi)等。需求工程的結(jié)構(gòu)如圖 42 所示，需求開(kāi)發(fā)與需求管理的流程如圖 43 所示。? 需求分析。需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無(wú)誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》 。我們把從事需求開(kāi)發(fā)工作的人員稱(chēng)為需求分析員（也叫系統(tǒng)分析員） ，避免與其它開(kāi)發(fā)人員混淆。需求確認(rèn)是指開(kāi)發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出書(shū)面承諾，使需求文檔具有商業(yè)合同效果。需求變更控制是指依據(jù)“變更申請(qǐng)－審批－更改－重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。對(duì)于合同項(xiàng)目，由于客戶是已知的，需求開(kāi)發(fā)和需求管理的各項(xiàng)活動(dòng)可以有的放矢地開(kāi)展。相似慘痛的教訓(xùn)實(shí)在太多，人們一定要清醒啊。注意在扮演用戶這個(gè)角色時(shí)，應(yīng)當(dāng)忘記自己是開(kāi)發(fā)者，一定要真正地站在用戶的立場(chǎng)思考問(wèn)題。他們認(rèn)為需求是用戶的事情而不是自己的事情。俗話說(shuō)“良好的開(kāi)端是成功的一半” ， “主動(dòng)型”需求工程是開(kāi)發(fā)成功產(chǎn)品的必備條件。 需求開(kāi)發(fā)的主要困難與對(duì)策 知識(shí)技能問(wèn)題絕大多數(shù)軟件開(kāi)發(fā)人員在學(xué)生時(shí)期的學(xué)習(xí)重點(diǎn)是計(jì)算機(jī)技術(shù)，他們畢業(yè)后到企業(yè)工作，主要任務(wù)依然是技術(shù)開(kāi)發(fā)。最好最快的解決辦法是培訓(xùn)。俗話說(shuō)“隔行如隔山” ，需求分析員可能是某一領(lǐng)域的專(zhuān)家，但當(dāng)他接手陌生的業(yè)務(wù)時(shí)，他可能是個(gè)“無(wú)知”者。其次他應(yīng)當(dāng)趕緊補(bǔ)習(xí)應(yīng)用域知識(shí)，不第 4 章 需求開(kāi)發(fā)與需求管理Page 10 of 34論是通過(guò)自學(xué)還是培訓(xùn)的方式，否則他很難與用戶交流。 態(tài)度問(wèn)題相當(dāng)多的開(kāi)發(fā)人員習(xí)慣于被動(dòng)地對(duì)待需求開(kāi)發(fā)。用戶說(shuō)不清楚需求或者需求發(fā)生變更，這些都是常見(jiàn)的問(wèn)題，并不是絕癥，是人們可以設(shè)法解決的。倘若用戶不能很好地配合需求分析員，那并不表示他是個(gè)壞蛋。對(duì)于一些競(jìng)標(biāo)項(xiàng)目，在合同未簽訂之前的需求開(kāi)發(fā)工作尤為困難。公司曾有一個(gè)關(guān)于企業(yè)管理的項(xiàng)目要外包，項(xiàng)目金額不小，有數(shù)家軟件公司來(lái)競(jìng)標(biāo)。然而將心比心（或者說(shuō)同病相憐吧） ，我也是開(kāi)發(fā)人員，知道吃這碗飯不容易，我理應(yīng)幫他們一把。 ”需求分析員不是銷(xiāo)售人員，他們不可能象銷(xiāo)售人員那樣通過(guò)某些手段籠絡(luò)住用戶就能成功。有些調(diào)查人員為了討好我，不停地說(shuō)好話、套近乎。有太多的開(kāi)發(fā)人員不懂得“如何做好”需求開(kāi)發(fā)，這并不有趣，組建優(yōu)秀的開(kāi)發(fā)團(tuán)隊(duì)談何容易??！開(kāi)發(fā)方與用戶的合作關(guān)系對(duì)需求開(kāi)發(fā)而言是至關(guān)重要的。如果條件允許的話，開(kāi)發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn)，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項(xiàng)活動(dòng)。3. 有權(quán)審查需求文檔，并對(duì)有爭(zhēng)議的需求作出決策。2. 樂(lè)意接受需求分析員的采訪，在不泄漏機(jī)密的前提下，盡可能地回答需求分析員的問(wèn)題。如果需要變更需求的話，按照“需求變更控制規(guī)程”執(zhí)行，而非強(qiáng)迫開(kāi)發(fā)方接受。也有不正常的現(xiàn)象，例如前些年全國(guó)各地的很多政府機(jī)構(gòu)大搞網(wǎng)絡(luò)建設(shè)。舉個(gè)日常生活的事例，比如說(shuō)買(mǎi)鞋子。明可明，非常明。有時(shí)用戶會(huì)把開(kāi)發(fā)人員的建議或答復(fù)給想歪了：有一個(gè)軟件開(kāi)發(fā)人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處，用戶聽(tīng)得津津有味。如果需求分析員誤解了需求，那會(huì)導(dǎo)致后續(xù)的不少開(kāi)發(fā)人員將錯(cuò)就錯(cuò)、白干活。嗓門(mén)極大，在夜里雙眼能射出強(qiáng)光。 開(kāi)發(fā)人員寫(xiě)不好需求文檔開(kāi)發(fā)人員寫(xiě)不好需求文檔的主要原因如下：第 4 章 需求開(kāi)發(fā)與需求管理Page 13 of 34? 需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫(xiě)不成需求文檔。? 開(kāi)發(fā)人員寫(xiě)作能力比較差，雖然在調(diào)查過(guò)程中已經(jīng)獲得了不少需求信息，卻寫(xiě)不出好的需求文檔來(lái)。 用戶經(jīng)常變更需求需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大的影響，這是開(kāi)發(fā)商非常畏懼的問(wèn)題。如果由于市場(chǎng)變化而導(dǎo)致產(chǎn)品需求發(fā)生變更，開(kāi)發(fā)商大可不必為此煩惱，應(yīng)當(dāng)高興才對(duì)。所以需求變更控制是需求工程的重要活動(dòng)，詳見(jiàn)本章第 11 節(jié)的論述。角色與職責(zé) 需求分析員調(diào)查、分析用戶的需求，客戶與最終用戶提供必要的需求信息。問(wèn)題表可以有多份，隨著調(diào)查的深入，問(wèn)題表將不斷地被細(xì)化。? 參觀用戶的工作流程，觀察用戶的操作。? 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。 調(diào)查與記錄準(zhǔn)備工作完畢后，需求分析員按照計(jì)劃執(zhí)行調(diào)查。? 需求分析員應(yīng)事先了解用戶的身份、背景，以便隨機(jī)應(yīng)變。? 需求調(diào)查不象偵探推理那樣從蛛絲馬跡著手，應(yīng)該先了解宏觀問(wèn)題，再了解細(xì)節(jié)問(wèn)題。? 避免片面地聽(tīng)取某些用戶的需求而忽視其它用戶的需求。然后按照指定的文檔模板（見(jiàn)表 43）撰寫(xiě)《用戶需求說(shuō)明書(shū)》 ，調(diào)查過(guò)程中獲取的需求信息（見(jiàn)表 42）可以作為《用戶需求說(shuō)明書(shū)》的附件。（2）后者是前者的細(xì)化，更多地采用計(jì)算機(jī)語(yǔ)言和圖形符號(hào)來(lái)刻畫(huà)需求，產(chǎn)品需求是軟件系統(tǒng)設(shè)計(jì)的直接依據(jù)。用戶需求說(shuō)明書(shū)0. 文檔介紹 文檔目的 文檔范圍 讀者對(duì)象 參考文檔 術(shù)語(yǔ)與縮寫(xiě)解釋1. 產(chǎn)品介紹提示： （ 1）說(shuō)明產(chǎn)品是什么，什么用途。誰(shuí)都知道這不是真的。分析方法大體有兩類(lèi)：“問(wèn)答分析法”和“建模分析法” 。 問(wèn)答分析法問(wèn)答分析方法很簡(jiǎn)單：刨根究底地問(wèn)，如果問(wèn)題都被解答了，那么需求也就分析清楚了。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么” ，以便加深讀者的理解。所以將圖形與文本結(jié)合起來(lái)描述需求是很自然的方法。結(jié)構(gòu)化分析方法并不是由里程碑式的明確地涉及這個(gè)主題的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的單一方法。文獻(xiàn)[Pressmen99, p206p214]對(duì)結(jié)構(gòu)化分析方法作了高度概括（如圖 44 所示） ，我們不妨稱(chēng)之為“一個(gè)中心三種圖”：? “數(shù)據(jù)字典”是中心，它包含了軟件中所有數(shù)據(jù)對(duì)象的描述。圖 44 結(jié)構(gòu)化分析方法示意圖 面向?qū)ο蠓治龇嫦驅(qū)ο蠓治鲈O(shè)計(jì)（OOAD）方法興起于 20 世紀(jì) 80 年代，從 90 年代起至今它已經(jīng)在分析設(shè)計(jì)領(lǐng)域占據(jù)了無(wú)可爭(zhēng)議的主流地位。面向?qū)ο蠓治鲈O(shè)計(jì)領(lǐng)域有一些比較著名的學(xué)派，如：? Coad 和 Yourdon 學(xué)派，其代表作為[Coad91]。有趣的是，這些學(xué)派的掌門(mén)人就像上帝、真主、如來(lái)佛，他們用各自的方式定義了這個(gè)世界，并留下一堆經(jīng)書(shū)來(lái)解釋這個(gè)世界。UML 吸取了各種 OOAD 方法的精髓，對(duì)于 OOAD 中的語(yǔ)義、圖形表示法和使用規(guī)則作了完整而詳細(xì)的定義。Rose 易學(xué)易用，它能交互式地構(gòu)建類(lèi)圖、用例圖、構(gòu)件圖、部署圖、狀態(tài)圖、活動(dòng)圖、順序圖、協(xié)作圖等等，深得開(kāi)發(fā)人員的喜愛(ài)。世上不存在一個(gè)包羅萬(wàn)象的圖——它能完整地描述需求。 作出決策當(dāng)需求從四面八方收集來(lái)后，需求的沖突在所難免。根據(jù)生活經(jīng)驗(yàn)，最保險(xiǎn)的辦法是：先聽(tīng)官兒大的或者威望高的，如果大家的職位和威望都差不多，那么采用“少數(shù)服從大多數(shù)”的原則。此時(shí)對(duì)需求的決策應(yīng)當(dāng)以商業(yè)利益為導(dǎo)向， 即哪一類(lèi)客戶出錢(qián)最多就先滿足他們的需求，以后再做那些獲利相對(duì)較少的需求。第 4 章 需求開(kāi)發(fā)與需求管理Page 20 of 34 什么是好的產(chǎn)品需求規(guī)格說(shuō)明書(shū)好的產(chǎn)品需求規(guī)格說(shuō)明書(shū)有如下屬性：正確、清楚、無(wú)二義性、一致、必要、完備、可實(shí)現(xiàn)、可驗(yàn)證。為確保需求是正確的，開(kāi)發(fā)方和用戶必須對(duì)《需求規(guī)格說(shuō)明書(shū)》進(jìn)行確認(rèn)。（3） 如果我欺負(fù)別人，你幫我打他。你可以采用反問(wèn)的方式來(lái)判斷需求文檔是否清楚：（1） 文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？（2） 文檔的語(yǔ)句是否含糊其詞、羅里羅嗦？（3） 看了半天是否還不明白需求究竟是什么？ 無(wú)二義性“無(wú)二義性” （Unambiguous）是指每個(gè)需求只有唯一的含義。人們對(duì)“小康”的理解不盡相同，所以“小康”這詞存在二義性。矛盾常常潛伏在需求文檔的上下文中。這段“需求”很清楚，無(wú)二義性，總統(tǒng)和國(guó)會(huì)看了都很高興，批準(zhǔn)了改計(jì)劃，又撥了很多經(jīng)費(fèi)。 “必要”往前一步，要么是“畫(huà)蛇添足”要么是“錦上添花” ?！板\上添花”是好事，可能會(huì)讓用戶獲得比期望更多的喜悅，但是眼前用戶不會(huì)為此多付錢(qián)。不完備的《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時(shí)可能無(wú)法完成預(yù)期的任務(wù)。如果忽略了后者，高尚的社區(qū)遲早會(huì)被弄得臭氣熏天。吹牛皮雖然不犯法，但是《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》可是白紙黑字啊。如果需求是不可驗(yàn)證的，那么用戶就無(wú)法驗(yàn)收軟件，可能會(huì)發(fā)生商業(yè)糾紛。在項(xiàng)目剛開(kāi)始的時(shí)候，開(kāi)發(fā)方和客戶比較樂(lè)觀，什么都要做，可是做著做著，人們常常會(huì)面臨“進(jìn)度延誤、費(fèi)用超支、人員不足”等問(wèn)題，這時(shí)就亂套了。 闡述 “做什么 ”而不是“怎么做”《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》的重點(diǎn)是闡述“做什么” ，而不是闡述“怎么做” 。如果在調(diào)查、定義需求時(shí)想好了“怎么做” ，當(dāng)然應(yīng)該寫(xiě)下來(lái)，否則豈不浪費(fèi)！關(guān)鍵是不要將“怎么做”寫(xiě)到需求規(guī)格說(shuō)明書(shū)里面，記錄在其它文檔里就行了?？蛻襞c最終用戶確認(rèn)產(chǎn)品需求。度量 需求分析員統(tǒng)計(jì)工作量和上述文檔的規(guī)模，匯報(bào)給項(xiàng)目經(jīng)理。? 第二步：撰寫(xiě)產(chǎn)品需求規(guī)格說(shuō)明書(shū)需求分析員按照指定的文檔模板撰寫(xiě)《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》 。第 4 章 需求開(kāi)發(fā)與需求管理Page 24 of 34 軟件需求規(guī)格說(shuō)明書(shū)的模板軟件需求規(guī)格說(shuō)明書(shū)應(yīng)當(dāng)按照指定的文檔模板來(lái)寫(xiě)，這樣做至少有以下好處：（1）文檔模板已經(jīng)規(guī)定了書(shū)寫(xiě)格式，降低了寫(xiě)作難度，開(kāi)發(fā)人員可以把精力集中在文檔的內(nèi)容上。不要以為文檔模板“大而全”就越好，小規(guī)模的民用項(xiàng)目套用美國(guó)軍方“大而全”的文檔模板顯然是不合適的。如果文檔模板的結(jié)構(gòu)很清晰，那么作者和讀者都會(huì)比較輕松，有時(shí)候人們光看標(biāo)題就能了解文檔的大致內(nèi)容。要點(diǎn)完備的文檔模板有助于人們寫(xiě)出完備的軟件需求規(guī)格說(shuō)明書(shū)。2. 產(chǎn)品面向的用戶群體提示：（ 1）描述本產(chǎn)品面向的用戶（客戶、最終用戶）的特征， （ 2）說(shuō)明本產(chǎn)品將給他們帶來(lái)什么好處？他們選擇本產(chǎn)品的可能性有多大？3. 產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范提示：闡述本產(chǎn)品應(yīng)當(dāng)遵循什么標(biāo)準(zhǔn)、規(guī)范或業(yè)務(wù)規(guī)則（ Business Rules） ，違反標(biāo)準(zhǔn)、規(guī)范或業(yè)務(wù)規(guī)則的產(chǎn)品通常不太可能被接受。各種角色的具體行為將在功能性需求中描述。目的 開(kāi)發(fā)方和客戶對(duì)需求文檔進(jìn)行評(píng)審，并作書(shū)面承諾。輸入 需求文檔如《用戶需求說(shuō)明書(shū)》和《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》主要步驟 第一步：非正式需求評(píng)審第二步：正式需求評(píng)審第三步：獲取需求承諾輸出 《需求評(píng)審報(bào)告》和書(shū)面的需求承諾結(jié)束準(zhǔn)則 需求文檔通過(guò)了正式評(píng)審，并且獲得開(kāi)發(fā)方和客戶的書(shū)面承諾