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