【正文】 這種“明哲保身”的做法很低俗：“身為軟件研發(fā)人員，怎么可以不堅(jiān)持真理呢？”唉，需求本來就不是真理，它來源于人們的欲望。大家值得為不是真理的需求爭得不可開交嗎？? 如果一個(gè)產(chǎn)品可以賣給幾類客戶，但是各類客戶都要求產(chǎn)品按照他們的喜好來開發(fā)。此時(shí)對(duì)需求的決策應(yīng)當(dāng)以商業(yè)利益為導(dǎo)向， 即哪一類客戶出錢最多就先滿足他們的需求，以后再做那些獲利相對(duì)較少的需求。? 當(dāng)開發(fā)者想象中的產(chǎn)品與客戶所提的需求有沖突時(shí)，一般應(yīng)當(dāng)尊重客戶的觀點(diǎn)。但是不要陷入“客戶總是對(duì)的”陷阱里，需求分析員應(yīng)當(dāng)糾正明顯不合理的客戶需求。如果產(chǎn)品很復(fù)雜，雙方都不太明白需求，此時(shí)最好請(qǐng)開發(fā)人員快速構(gòu)造軟件的原型，雙方看著軟件原型再分析需求。第 4 章 需求開發(fā)與需求管理Page 20 of 34 什么是好的產(chǎn)品需求規(guī)格說明書好的產(chǎn)品需求規(guī)格說明書有如下屬性：正確、清楚、無二義性、一致、必要、完備、可實(shí)現(xiàn)、可驗(yàn)證。 正確需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實(shí)意圖， “正確”是《產(chǎn)品需求規(guī)格說明書》最重要的屬性。如果“不正確”僅僅是由于錯(cuò)別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么” 。為確保需求是正確的，開發(fā)方和用戶必須對(duì)《需求規(guī)格說明書》進(jìn)行確認(rèn)。 清楚電影《新少林五祖》里有一段精彩的需求對(duì)話。綽號(hào)叫“日行一善”的財(cái)主想請(qǐng)武藝高強(qiáng)的洪熙官（李連杰演）做他的保鏢，他提出的需求只有四句話：（1） 如果有人欺負(fù)我，你幫我打他。（2） 如果有人搶我的東西，你幫我打他。（3） 如果我欺負(fù)別人，你幫我打他。（4） 如果我搶別人的東西，你幫我打他。清楚（Clarity ）的需求讓人易讀易懂，上例就是榜樣。清楚的反義詞是“難讀” 、 “難理解” 。你可以采用反問的方式來判斷需求文檔是否清楚：（1） 文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？（2） 文檔的語句是否含糊其詞、羅里羅嗦？（3） 看了半天是否還不明白需求究竟是什么？ 無二義性“無二義性” （Unambiguous）是指每個(gè)需求只有唯一的含義。如果一個(gè)人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會(huì)導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。80 年代中國老百姓致富的口號(hào)是“奔小康” ，這個(gè)口號(hào)聽起來“正確”并且“清楚” ，但不能當(dāng)成政策來推行。人們對(duì)“小康”的理解不盡相同，所以“小康”這詞存在二義性。例如阿富汗人民心目中的“小康”對(duì)美國人們而言簡直不如乞丐的生活水平。為了使需求無二義性，人們在寫《產(chǎn)品需求規(guī)格說明書》時(shí)措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。第 4 章 需求開發(fā)與需求管理Page 21 of 34 一致“一致” （Consistent）是指《產(chǎn)品需求規(guī)格說明書》中各個(gè)需求之間不會(huì)發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。地球上有個(gè)超級(jí)大國的“導(dǎo)彈發(fā)展計(jì)劃”是這樣寫的：我們要研制世界上最先進(jìn)的導(dǎo)彈，我們想打哪里就打哪里，任何防御系統(tǒng)都對(duì)它無可奈何。這段 “需求”很清楚，無二義性，總統(tǒng)和國會(huì)看了都很高興，于是批準(zhǔn)了改計(jì)劃，撥了很多經(jīng)費(fèi)。同時(shí)這個(gè)國家的“導(dǎo)彈防御系統(tǒng)發(fā)展計(jì)劃”是這樣寫的：我們要研制世界上最先進(jìn)的導(dǎo)彈防御系統(tǒng)，使得任何導(dǎo)彈來 襲都落得“ 肉包子打狗，有去無回”的下場。這段“需求”很清楚，無二義性，總統(tǒng)和國會(huì)看了都很高興，批準(zhǔn)了改計(jì)劃，又撥了很多經(jīng)費(fèi)。據(jù)說后來恐怖分子們利用了這兩個(gè)計(jì)劃之間的矛盾，用這種導(dǎo)彈打這種防御系統(tǒng)，給這個(gè)國家造成了很多麻煩。 必要《產(chǎn)品需求規(guī)格說明書》中的各項(xiàng)需求對(duì)用戶而言應(yīng)當(dāng)都是必要的。我們可以把“必要”比喻為“雪中送炭” 。 “必要”往前一步，要么是“畫蛇添足”要么是“錦上添花” 。據(jù)說基于 Windows 系統(tǒng)的汽車控制軟件有這么一項(xiàng)功能，當(dāng)汽車發(fā)生碰撞時(shí)該軟件會(huì)彈出一個(gè)對(duì)話框：您需要使用安全氣囊嗎？按 OK 鍵表示需要，按 Cancel 鍵表示不需要。“畫蛇添足”顯然是壞事，會(huì)導(dǎo)致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求?！板\上添花”是好事，可能會(huì)讓用戶獲得比期望更多的喜悅，但是眼前用戶不會(huì)為此多付錢。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應(yīng)當(dāng)在《產(chǎn)品需求規(guī)格說明書》中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級(jí)。 完備“完備” （Complete ）是指《 產(chǎn)品需求規(guī)格說明書》中沒有遺漏一些必要的需求。不完備的《產(chǎn)品需求規(guī)格說明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時(shí)可能無法完成預(yù)期的任務(wù)。人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。例如，在大城市的繁華街區(qū)往往找不到公共廁所，急得行人看到肯德基、麥當(dāng)勞就往里闖。消費(fèi)是人們的需求，但上廁所也是人們的需求。如果忽略了后者，高尚的社區(qū)遲早會(huì)被弄得臭氣熏天。第 4 章 需求開發(fā)與需求管理Page 22 of 34 可實(shí)現(xiàn)《產(chǎn)品需求規(guī)格說明書》中的各項(xiàng)需求對(duì)開發(fā)方而言應(yīng)當(dāng)都是可實(shí)現(xiàn)的（Attainable） ?！翱蓪?shí)現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時(shí)間、費(fèi)用、質(zhì)量等約束。營銷人員和用戶談生意時(shí)，為了能拿到“單子” ，他們往往對(duì)用戶提出的需求“來者不拒” 。吹牛皮雖然不犯法，但是《產(chǎn)品需求規(guī)格說明書》可是白紙黑字啊。經(jīng)過雙方確認(rèn)的《產(chǎn)品需求規(guī)格說明書》相當(dāng)于商業(yè)合同，如果開發(fā)方不能夠?qū)崿F(xiàn)《產(chǎn)品需求規(guī)格說明書》中的內(nèi)容，那就是違約，可能會(huì)被罰款的。對(duì)于合同項(xiàng)目，如果開發(fā)方不能確信某些需求是否可實(shí)現(xiàn)，則應(yīng)事先與用戶協(xié)商，達(dá)成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。 可驗(yàn)證《產(chǎn)品需求規(guī)格說明書》中的各項(xiàng)需求對(duì)用戶方而言應(yīng)當(dāng)都是可驗(yàn)證的（Verifiable） 。如果需求是不可驗(yàn)證的，那么用戶就無法驗(yàn)收軟件，可能會(huì)發(fā)生商業(yè)糾紛。例如，摩天大樓的一項(xiàng)需求是“抗十二級(jí)臺(tái)風(fēng)” ，這個(gè)需求看起來堂而皇之，但是如何驗(yàn)證呢？當(dāng)摩天大樓完工后驗(yàn)收時(shí)，用戶又不是巫師，他怎能造個(gè)十二級(jí)臺(tái)風(fēng)來試驗(yàn)？如果雙方都認(rèn)可“采用計(jì)算機(jī)模擬十二級(jí)臺(tái)風(fēng)”等效于實(shí)際測試，那么這項(xiàng)需求就是“可驗(yàn)證”的。 確定優(yōu)先級(jí)為什么要確定需求的“優(yōu)先級(jí)”？理論上講，軟件的所有需求都應(yīng)當(dāng)被實(shí)現(xiàn)。但是在現(xiàn)實(shí)之中，項(xiàng)目存在“進(jìn)度、費(fèi)用、人力資源”等限制。在項(xiàng)目剛開始的時(shí)候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會(huì)面臨“進(jìn)度延誤、費(fèi)用超支、人員不足”等問題，這時(shí)就亂套了。久病成醫(yī)那，人們想出了“取舍”辦法：先做優(yōu)先級(jí)高的需求，后做（甚至放棄）優(yōu)先級(jí)低的需求，這樣可以將風(fēng)險(xiǎn)降到最低。需求的優(yōu)先級(jí)其實(shí)就是需求“輕重緩急”的分級(jí)表述，例如劃分為“高、中、低”三級(jí)。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級(jí)。 闡述 “做什么 ”而不是“怎么做”《產(chǎn)品需求規(guī)格說明書》的重點(diǎn)是闡述“做什么” ，而不是闡述“怎么做” 。 “怎么做”是系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階段的事情。國內(nèi)的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計(jì)、編程等工作從頭做到尾。所以他們在調(diào)查、分析、定義需求時(shí)，自然會(huì)想到“怎么做” ，這并沒有第 4 章 需求開發(fā)與需求管理Page 23 of 34什么過錯(cuò)。如果在調(diào)查、定義需求時(shí)想好了“怎么做” ，當(dāng)然應(yīng)該寫下來，否則豈不浪費(fèi)！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。 如何定義產(chǎn)品需求 規(guī)程產(chǎn)品需求定義的一般規(guī)程如表 45 所示。目的 定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》 。角色與職責(zé) 需求分析員定義產(chǎn)品需求。客戶與最終用戶確認(rèn)產(chǎn)品需求。啟動(dòng)準(zhǔn)則 《用戶需求說明書》已經(jīng)撰寫完成。輸入 《用戶需求說明書》主要步驟 第一步：細(xì)化并分析用戶需求第二步：撰寫產(chǎn)品需求規(guī)格說明書第三步：需求確認(rèn)輸出 《產(chǎn)品需求規(guī)格說明書》結(jié)束準(zhǔn)則 《產(chǎn)品需求規(guī)格說明書》已經(jīng)撰寫完成。開發(fā)方和客戶方已經(jīng)對(duì)產(chǎn)品需求進(jìn)行了確認(rèn)（包括需求評(píng)審和承諾） 。度量 需求分析員統(tǒng)計(jì)工作量和上述文檔的規(guī)模，匯報(bào)給項(xiàng)目經(jīng)理。表 42 需求調(diào)查的規(guī)程定義產(chǎn)品需求的主要步驟如下：? 第一步：細(xì)化并分析用戶需求需求分析員首先對(duì)《用戶需求說明書》進(jìn)行細(xì)化，對(duì)比較復(fù)雜的用戶需求進(jìn)行建模分析，以幫助軟件開發(fā)人員更好地理解需求。例如采用 Rational 的 Rose 工具進(jìn)行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明書》的附件。補(bǔ)充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當(dāng)根據(jù)自身水平進(jìn)行取舍。? 第二步：撰寫產(chǎn)品需求規(guī)格說明書需求分析員按照指定的文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》 。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話，則應(yīng)當(dāng)分別撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》。? 第三步：進(jìn)行需求確認(rèn)項(xiàng)目經(jīng)理邀請(qǐng)同行專家和用戶（包括客戶和最終用戶）一起評(píng)審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實(shí)意愿。需求評(píng)審之后，開發(fā)方和客戶方的責(zé)任人對(duì)《產(chǎn)品需求規(guī)格說明書》作書面承諾。第 4 章 需求開發(fā)與需求管理Page 24 of 34 軟件需求規(guī)格說明書的模板軟件需求規(guī)格說明書應(yīng)當(dāng)按照指定的文檔模板來寫，這樣做至少有以下好處：（1）文檔模板已經(jīng)規(guī)定了書寫格式，降低了寫作難度，開發(fā)人員可以把精力集中在文檔的內(nèi)容上。（2）按照文檔模板寫出來的《軟件需求規(guī)格說明書》比較規(guī)范，容易被用戶和開發(fā)人員接受。好的文檔模板有如下特性：（1）貼切于該項(xiàng)目。關(guān)于軟件需求規(guī)格說明書的文檔模板非常多，目前國際上沒有（也不可能有）統(tǒng)一的標(biāo)準(zhǔn)。不要以為文檔模板“大而全”就越好，小規(guī)模的民用項(xiàng)目套用美國軍方“大而全”的文檔模板顯然是不合適的。所以開發(fā)人員應(yīng)當(dāng)根據(jù)項(xiàng)目的特征，定制最貼切于該項(xiàng)目的文檔模板。（2）結(jié)構(gòu)清晰。那怕是天下最無能的領(lǐng)導(dǎo)，都知道在作報(bào)告時(shí)要先從宏觀上講一、二、三、四、五，再從細(xì)節(jié)上講 A、B、C、D、E。如果文檔模板的結(jié)構(gòu)很清晰，那么作者和讀者都會(huì)比較輕松，有時(shí)候人們光看標(biāo)題就能了解文檔的大致內(nèi)容。（3）要點(diǎn)完備。人們在寫軟件需求規(guī)格說明書時(shí)，經(jīng)常會(huì)遺忘掉一些重要的內(nèi)容。例如人們通常著重于寫功能性需求，卻忘了或者壓根就沒有想到還要寫非功能性需求。要點(diǎn)完備的文檔模板有助于人們寫出完備的軟件需求規(guī)格說明書。表 46 是本書作者制定的《軟件需求規(guī)格說明書 》的文檔模板，供讀者參考。軟件需求規(guī)格說明書0. 文檔介紹 文檔目的 文檔范圍 讀者對(duì)象 參考文檔 術(shù)語與縮寫解釋1. 產(chǎn)品介紹提示：（ 1）說明產(chǎn)品是什么，什么用途。 （ 2）介紹產(chǎn)品的開發(fā)背景。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)品通常不太可能被接受。4. 產(chǎn)品范圍提示：闡述本產(chǎn)品 “適用的領(lǐng)域 ”和 “不適用的領(lǐng)域 ”，本產(chǎn)品 “應(yīng)當(dāng)包含的內(nèi)容 ”和 “不包含的內(nèi)容 ”。說清楚產(chǎn)品范圍的好處是：（ 1）有助于判斷什么是需求，什么不是需求；（ 2）可以將開發(fā)精力集中在產(chǎn)品范圍之內(nèi)，少干吃力不討好的事情；（ 3）有助于控制需求的變更。第 4 章 需求開發(fā)與需求管理Page 25 of 345. 產(chǎn)品中的角色提示：闡述本產(chǎn)品的各種角色及其職責(zé)。各種角色的具體行為將在功能性需求中描述。角色名稱 職責(zé)描述6. 產(chǎn)品的功能性需求 需求分類功能類別 功能名稱、標(biāo)識(shí)符 描述Function Feature A…Function Feature B…Function Feature C… Feature M Function 名稱、標(biāo)識(shí)符優(yōu)先級(jí)功能描述輸入、輸出操作序列等其它說明7. 產(chǎn)品的非功能性需求需求類別 需求名稱、標(biāo)識(shí)符 描述用戶界面需求軟硬件需求質(zhì)量需求8. 其它需求附錄 A：需求建模附錄 B：需求評(píng)審報(bào)告摘要附錄 C：需求承諾表 46 《軟件需求規(guī)格說明書》的文檔模板第 4 章 需求開發(fā)與需求管理Page 26 of 34 需求確認(rèn) 規(guī)程需求確認(rèn)是指開發(fā)方和客戶方共同對(duì)需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出承諾。 《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》可以分開也可以放在一起進(jìn)行需求確認(rèn)，視項(xiàng)目的具體情況而定。需求確認(rèn)包含兩個(gè)重要工作：“需求評(píng)審”和“需求承諾” ，一般規(guī)程如表 47 所示。目的 開發(fā)方和客戶對(duì)需求文檔進(jìn)行評(píng)審，并作書面承諾。角色與職責(zé) 開發(fā)方和客戶共同組織人員對(duì)需求文檔進(jìn)行評(píng)審。雙方負(fù)責(zé)人對(duì)需求文檔作書面承諾，使之具有商業(yè)合同效果。啟動(dòng)準(zhǔn)則 需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》已經(jīng)完成。輸入 需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》主要步驟 第一步：非正式需求評(píng)審第二步：正式需求評(píng)審第三步：獲取需求承諾輸出 《需求評(píng)審報(bào)告》和書面的需求承諾結(jié)束準(zhǔn)則 需求文檔通過了正式評(píng)審，并且獲得開發(fā)方和客戶的書面承諾。度量 項(xiàng)目經(jīng)理統(tǒng)計(jì)工作量和上述文檔的規(guī)模。表 47 需求確認(rèn)的規(guī)程 需求評(píng)審對(duì)工作成果的技術(shù)評(píng)審有兩類方式，一類是正式技術(shù)評(píng)審，另一類是非正式技術(shù)評(píng)審。對(duì)于任何重要的工作成果，都應(yīng)該至少執(zhí)行一次正式技術(shù)評(píng)審，建議在正