【正文】 檔來。提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習(xí)寫文檔，熟能生巧嘛。 用戶經(jīng)常變更需求需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大的影響，這是開發(fā)商非常畏懼的問題。毫無疑問，這種需求變更將使項(xiàng)目付出額外的代價(jià)。如果由于市場變化而導(dǎo)致產(chǎn)品需求發(fā)生變更，開發(fā)商大可不必為此煩惱，應(yīng)當(dāng)高興才對(duì)。正因?yàn)槭袌鲈谧兓?，才?huì)產(chǎn)生更多商機(jī)，聰明的開發(fā)商才會(huì)有活干，有錢賺。所以需求變更控制是需求工程的重要活動(dòng)，詳見本章第 11 節(jié)的論述?！毙枨笳{(diào)查的一般規(guī)程如表 42 所示。角色與職責(zé) 需求分析員調(diào)查、分析用戶的需求，客戶與最終用戶提供必要的需求信息。度量 需求分析員統(tǒng)計(jì)工作量和上述文檔的規(guī)模，匯報(bào)給項(xiàng)目經(jīng)理。問題表可以有多份，隨著調(diào)查的深入，問題表將不斷地被細(xì)化。制定問題表最簡便的方法就是從《用戶需求說明書》的模板中提取需求問題。? 參觀用戶的工作流程，觀察用戶的操作。? 與同行、專家交談，聽取他們的意見。? 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。? 最后，需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時(shí)間、地點(diǎn)、人員等，撰寫需求調(diào)查計(jì)劃。 調(diào)查與記錄準(zhǔn)備工作完畢后，需求分析員按照計(jì)劃執(zhí)行調(diào)查。需求標(biāo)題 1調(diào)查方式調(diào)查人第 4 章 需求開發(fā)與需求管理Page 15 of 34調(diào)查對(duì)象時(shí)間、地點(diǎn)需求信息記錄基本要素如“是什么” 、 “為什么”等表 43 需求信息表格示例需求分析員與用戶面談時(shí)應(yīng)當(dāng)注意以下事項(xiàng)：? 如果與用戶約好了時(shí)間，切勿遲到或早退。? 需求分析員應(yīng)事先了解用戶的身份、背景，以便隨機(jī)應(yīng)變。如果你路上碰到他，以為是個(gè)勤雜工，說：“喂，老師傅，來幫我拎東西。? 需求調(diào)查不象偵探推理那樣從蛛絲馬跡著手，應(yīng)該先了解宏觀問題，再了解細(xì)節(jié)問題。當(dāng)雙方對(duì)某些問題的交流合乎邏輯地結(jié)束后，即可繼續(xù)討論問題表中的其它問題。? 避免片面地聽取某些用戶的需求而忽視其它用戶的需求。在調(diào)查需求的同時(shí)應(yīng)當(dāng)進(jìn)行必要的需求分析，建議采用“問答分析法” （詳見 節(jié)） ，盡可能確定每個(gè)需求的基本要素，如“是什么” 、 “為什么”等。然后按照指定的文檔模板（見表 43）撰寫《用戶需求說明書》 ，調(diào)查過程中獲取的需求信息（見表 42）可以作為《用戶需求說明書》的附件。之后才進(jìn)一步定義產(chǎn)品的需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》 。（2）后者是前者的細(xì)化，更多地采用計(jì)算機(jī)語言和圖形符號(hào)來刻畫需求，產(chǎn)品需求是軟件系統(tǒng)設(shè)計(jì)的直接依據(jù)。軟件開發(fā)人員應(yīng)當(dāng)依據(jù)《產(chǎn)品需求規(guī)格說明書》來開發(fā)當(dāng)前產(chǎn)品。用戶需求說明書0. 文檔介紹 文檔目的 文檔范圍 讀者對(duì)象 參考文檔 術(shù)語與縮寫解釋1. 產(chǎn)品介紹提示： （ 1）說明產(chǎn)品是什么，什么用途。2. 產(chǎn)品面向的用戶群體提示： （ 1）描述本產(chǎn)品面向的用戶（客戶、最終用戶）的特征， （ 2）說明本產(chǎn)品將給他們帶來什么好處？他們選擇本產(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)品通常不太可能被接受。誰都知道這不是真的。需求分析是指在需求開發(fā)過程中，對(duì)所獲取的需求信息進(jìn)行分析，及時(shí)排除錯(cuò)誤和彌補(bǔ)不足，確保需求文檔正確地反映用戶的真實(shí)意圖。分析方法大體有兩類：“問答分析法”和“建模分析法” 。前者就是一些常識(shí)而已，雖然寫不成文章，但是簡單易用（保你一學(xué)就會(huì)） ，很有實(shí)用價(jià)值。 問答分析法問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。問答分析最重要的問題是：“是什么”和“為什么” 。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么” ，以便加深讀者的理解。其它常見的問題有：? 需求存在二義性嗎？? 需求文檔的上下文有矛盾嗎？? 需求完備嗎？? 需求是必要的嗎？? 需求可實(shí)現(xiàn)嗎？? 需求可驗(yàn)證嗎？? 需求的優(yōu)先級(jí)確定了嗎？ 建模分析法人們都有這樣地感受：有些時(shí)候用語言描述某個(gè)問題特別費(fèi)勁，而采用圖形則使人一目了然，所謂“一圖低千言”就是這個(gè)道理。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā?。結(jié)構(gòu)化分析方法并不是由里程碑式的明確地涉及這個(gè)主題的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的單一方法。結(jié)構(gòu)化分析方法在 70年代和 80 年代非常流行，相關(guān)論著很多。文獻(xiàn)[Pressmen99, p206p214]對(duì)結(jié)構(gòu)化分析方法作了高度概括（如圖 44 所示） ，我們不妨稱之為“一個(gè)中心三種圖”：? “數(shù)據(jù)字典”是中心，它包含了軟件中所有數(shù)據(jù)對(duì)象的描述。? “數(shù)據(jù)流圖”指明了數(shù)據(jù)在系統(tǒng)中移動(dòng)時(shí)如何被變換。圖 44 結(jié)構(gòu)化分析方法示意圖 面向?qū)ο蠓治龇嫦驅(qū)ο蠓治鲈O(shè)計(jì)（OOAD）方法興起于 20 世紀(jì) 80 年代，從 90 年代起至今它已經(jīng)在分析設(shè)計(jì)領(lǐng)域占據(jù)了無可爭議的主流地位。關(guān)于“面向?qū)ο蟆钡恼n堂、學(xué)術(shù)報(bào)告常常人滿為患。面向?qū)ο蠓治鲈O(shè)計(jì)領(lǐng)域有一些比較著名的學(xué)派，如：? Coad 和 Yourdon 學(xué)派，其代表作為[Coad91]。? Jocobson 學(xué)派，其代表作為 [Jacobson92]。有趣的是，這些學(xué)派的掌門人就像上帝、真主、如來佛，他們用各自的方式定義了這個(gè)世界，并留下一堆經(jīng)書來解釋這個(gè)世界。叫苦的是軟件企業(yè)和開發(fā)人員：沒有統(tǒng)一的方法，不好干活??！數(shù)據(jù)字典實(shí)體－關(guān)系圖 數(shù)據(jù)流圖狀態(tài)－變遷圖第 4 章 需求開發(fā)與需求管理Page 19 of 34終于等到了那一天，Rational 公司招納了 Booch, Jocobson, Rumbaugh，這三位“面向?qū)ο蟆睒I(yè)界的老大強(qiáng)強(qiáng)聯(lián)手，制定了“統(tǒng)一建模語言” （UML） 。UML 吸取了各種 OOAD 方法的精髓，對(duì)于 OOAD 中的語義、圖形表示法和使用規(guī)則作了完整而詳細(xì)的定義。大多數(shù)軟件開發(fā)人員沒有興趣閱讀枯燥乏味的 UML 文檔（如[Rumbaugh99]） 。Rose 易學(xué)易用，它能交互式地構(gòu)建類圖、用例圖、構(gòu)件圖、部署圖、狀態(tài)圖、活動(dòng)圖、順序圖、協(xié)作圖等等，深得開發(fā)人員的喜愛。 恰當(dāng)?shù)厥褂脠D形符號(hào)現(xiàn)代建模工具如 Rose 有非常豐富的圖形符號(hào)和文字標(biāo)注，能很好地表達(dá)模型的細(xì)節(jié)。世上不存在一個(gè)包羅萬象的圖——它能完整地描述需求。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。 作出決策當(dāng)需求從四面八方收集來后，需求的沖突在所難免。那么需求分析員究竟應(yīng)該聽誰的呢？這個(gè)問題沒有標(biāo)準(zhǔn)答案。根據(jù)生活經(jīng)驗(yàn)，最保險(xiǎn)的辦法是：先聽官兒大的或者威望高的，如果大家的職位和威望都差不多，那么采用“少數(shù)服從大多數(shù)”的原則。讀者不要覺得這種“明哲保身”的做法很低俗：“身為軟件研發(fā)人員，怎么可以不堅(jiān)持真理呢？”唉，需求本來就不是真理，它來源于人們的欲望。此時(shí)對(duì)需求的決策應(yīng)當(dāng)以商業(yè)利益為導(dǎo)向， 即哪一類客戶出錢最多就先滿足他們的需求，以后再做那些獲利相對(duì)較少的需求。但是不要陷入“客戶總是對(duì)的”陷阱里，需求分析員應(yīng)當(dāng)糾正明顯不合理的客戶需求。第 4 章 需求開發(fā)與需求管理Page 20 of 34 什么是好的產(chǎn)品需求規(guī)格說明書好的產(chǎn)品需求規(guī)格說明書有如下屬性：正確、清楚、無二義性、一致、必要、完備、可實(shí)現(xiàn)、可驗(yàn)證。如果“不正確”僅僅是由于錯(cuò)別字造成的，那么多檢查幾遍文檔就能解決問題。為確保需求是正確的，開發(fā)方和用戶必須對(duì)《需求規(guī)格說明書》進(jìn)行確認(rèn)。綽號(hào)叫“日行一善”的財(cái)主想請(qǐng)武藝高強(qiáng)的洪熙官（李連杰演）做他的保鏢，他提出的需求只有四句話：（1） 如果有人欺負(fù)我，你幫我打他。（3） 如果我欺負(fù)別人，你幫我打他。清楚（Clarity ）的需求讓人易讀易懂，上例就是榜樣。你可以采用反問的方式來判斷需求文檔是否清楚：（1） 文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？（2） 文檔的語句是否含糊其詞、羅里羅嗦？（3） 看了半天是否還不明白需求究竟是什么？ 無二義性“無二義性” （Unambiguous）是指每個(gè)需求只有唯一的含義。如果需求存在二義性，將會(huì)導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。人們對(duì)“小康”的理解不盡相同，所以“小康”這詞存在二義性。為了使需求無二義性，人們?cè)趯憽懂a(chǎn)品需求規(guī)格說明書》時(shí)措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。矛盾常常潛伏在需求文檔的上下文中。這段 “需求”很清楚，無二義性，總統(tǒng)和國會(huì)看了都很高興，于是批準(zhǔn)了改計(jì)劃，撥了很多經(jīng)費(fèi)。這段“需求”很清楚，無二義性，總統(tǒng)和國會(huì)看了都很高興，批準(zhǔn)了改計(jì)劃，又撥了很多經(jīng)費(fèi)。 必要《產(chǎn)品需求規(guī)格說明書》中的各項(xiàng)需求對(duì)用戶而言應(yīng)當(dāng)都是必要的。 “必要”往前一步，要么是“畫蛇添足”要么是“錦上添花” 。“畫蛇添足”顯然是壞事，會(huì)導(dǎo)致開發(fā)人員多干一些吃力不討好的工作?！板\上添花”是好事，可能會(huì)讓用戶獲得比期望更多的喜悅，但是眼前用戶不會(huì)為此多付錢。為了避免主次顛倒，應(yīng)當(dāng)在《產(chǎn)品需求規(guī)格說明書》中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級(jí)。不完備的《產(chǎn)品需求規(guī)格說明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時(shí)可能無法完成預(yù)期的任務(wù)。例如，在大城市的繁華街區(qū)往往找不到公共廁所，急得行人看到肯德基、麥當(dāng)勞就往里闖。如果忽略了后者，高尚的社區(qū)遲早會(huì)被弄得臭氣熏天。“可實(shí)現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時(shí)間、費(fèi)用、質(zhì)量等約束。吹牛皮雖然不犯法，但是《產(chǎn)品需求規(guī)格說明書》可是白紙黑字啊。對(duì)于合同項(xiàng)目，如果開發(fā)方不能確信某些需求是否可實(shí)現(xiàn)，則應(yīng)事先與用戶協(xié)商，達(dá)成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。如果需求是不可驗(yàn)證的，那么用戶就無法驗(yàn)收軟件，可能會(huì)發(fā)生商業(yè)糾紛。 確定優(yōu)先級(jí)為什么要確定需求的“優(yōu)先級(jí)”？理論上講，軟件的所有需求都應(yīng)當(dāng)被實(shí)現(xiàn)。在項(xiàng)目剛開始的時(shí)候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會(huì)面臨“進(jìn)度延誤、費(fèi)用超支、人員不足”等問題，這時(shí)就亂套了。需求的優(yōu)先級(jí)其實(shí)就是需求“輕重緩急”的分級(jí)表述，例如劃分為“高、中、低”三級(jí)。 闡述 “做什么 ”而不是“怎么做”《產(chǎn)品需求規(guī)格說明書》的重點(diǎn)是闡述“做什么” ，而不是闡述“怎么做” 。國內(nèi)的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計(jì)、編程等工作從頭做到尾。如果在調(diào)查、定義需求時(shí)想好了“怎么做” ，當(dāng)然應(yīng)該寫下來，否則豈不浪費(fèi)！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。目的 定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》 。客戶與最終用戶確認(rèn)產(chǎn)品需求。輸入 《用戶需求說明書》主要步驟 第一步：細(xì)化并分析用戶需求第二步：撰寫產(chǎn)品需求規(guī)格說明書第三步：需求確認(rèn)輸出 《產(chǎn)品需求規(guī)格說明書》結(jié)束準(zhǔn)則 《產(chǎn)品需求規(guī)格說明書》已經(jīng)撰寫完成。度量 需求分析員統(tǒng)計(jì)工作量和上述文檔的規(guī)模，匯報(bào)給項(xiàng)目經(jīng)理。例如采用 Rational 的 Rose 工具進(jìn)行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明書》的附件。? 第二步：撰寫產(chǎn)品需求規(guī)格說明書需求分析員按照指定的文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》 。? 第三步：進(jìn)行需求確認(rèn)項(xiàng)目經(jīng)理邀請(qǐng)同行專家和用戶（包括客戶和最終用戶）一起評(píng)審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實(shí)意愿。第 4 章 需求開發(fā)與需求管理Page 24 of 34 軟件需求規(guī)格說明書的模板軟件需求規(guī)格說明書應(yīng)當(dāng)按照指定的文檔模板來寫，這樣做至少有以下好處：（1）文檔模板已經(jīng)規(guī)定了書寫格式，降低了寫作難度，開發(fā)人員可以把精力集中在文檔的內(nèi)容上。好的文檔模板有如下特性：（1）貼切于該項(xiàng)目。不要以為文檔模板“大而全”就越好，小規(guī)模的民用項(xiàng)目套用美國軍方“大而全”的文檔模板顯然是不合適的。（2）結(jié)構(gòu)清晰。如果文檔模板的結(jié)構(gòu)很清晰，那么作者和讀者都會(huì)比較輕松，有時(shí)候人們光看標(biāo)題就能了解文檔的大致內(nèi)容。人們?cè)趯戃浖枨笠?guī)格說明書時(shí)，經(jīng)常會(huì)遺忘掉一些重要的內(nèi)容。要點(diǎn)完備的文檔模板有助于人們寫出完備的軟件需求規(guī)格說明書。軟件需求規(guī)格說明書0. 文檔介紹 文檔目的 文檔范圍 讀者對(duì)象 參考文檔 術(shù)語與縮寫解釋1. 產(chǎn)品介紹提示：（ 1）說明產(chǎn)品是什么，什么用途。2. 產(chǎn)品面向的用戶群體提示：（ 1）描述本產(chǎn)品面向的用戶（客戶、最終用戶）的特征， （ 2）說明本產(chǎn)品將給他們帶來什么好處？他們選擇本產(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)品通常不太可能被接受。說清楚產(chǎn)品范圍的好處是：（ 1）有助于判斷什么是需求，什么不是需求；（ 2）可以將開發(fā)精力集中在產(chǎn)品范圍之內(nèi)，少干吃力不討好的事情；（ 3）有助于控制需求的變更。各種角色的具體行為將在功能性需求中描述。 《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》可以分開也可以放在一起進(jìn)行需求確認(rèn)，視項(xiàng)目的具體情況而定。目的 開發(fā)方和客戶對(duì)需求文檔進(jìn)行評(píng)審，并作書面承諾。雙方負(fù)責(zé)人對(duì)需求文檔作書面承諾，使之具有商業(yè)合同效果。輸入 需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》主要步驟 第一步：非正式需求評(píng)審第二步：正式需求評(píng)審第三步：獲取需求承諾輸出 《需求評(píng)審報(bào)告》和書面的需求承諾結(jié)束準(zhǔn)則 需求文檔通過了正式評(píng)審，并且獲得開發(fā)方和客戶的書面承諾。表 47 需求確認(rèn)的規(guī)程 需求評(píng)審對(duì)工作成果的技術(shù)評(píng)審有兩類方式，一類是正式技術(shù)評(píng)審，另一類是非正式技術(shù)評(píng)審