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