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