【正文】 ，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨 “ 進(jìn)度延誤、費(fèi)用超支、人員不足 ” 等問題，這時(shí)就亂套了。 – 人們想出了 “ 取舍 ” 辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風(fēng)險(xiǎn)降到最低。 ? 需求的優(yōu)先級其實(shí)就是需求 “ 輕重緩急 ” 的分級表述，例如劃分為 “ 高、中、低 ” 三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。 闡述 “ 做什么 ” 而不是 “ 怎么做 ” ? 《 產(chǎn)品需求規(guī)格說明書 》 的重點(diǎn)是闡述 “ 做什么 ” ， 而不是闡述 “ 怎么做 ” 。 “ 怎么做 ” 是系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階段的事情 。 ? 國內(nèi)的很多軟件公司里 ， 開發(fā)人員常常身兼數(shù)職 ， 可能把需求開發(fā) 、 系統(tǒng)設(shè)計(jì) 、 編程等工作從頭做到尾 。 所以他們在調(diào)查 、 分析 、 定義需求時(shí) ， 自然會想到 “ 怎么做 ” ， 這并沒有什么過錯(cuò) 。 如果在調(diào)查 、 定義需求時(shí)想好了 “ 怎么做 ” ， 當(dāng)然應(yīng)該寫下來 ， 否則豈不浪費(fèi) ！ 關(guān)鍵是不要將 “ 怎么做 ” 寫到需求規(guī)格說明書里面 ， 記錄在其它文檔里就行了 。 Page 30 8. 如何定義產(chǎn)品需求 規(guī)程 ? 第一步：細(xì)化并分析用戶需求 – 需求分析員首先對《用戶需求說明書》進(jìn)行細(xì)化，對比較復(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)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實(shí)意愿。 – 需求評審之后，開發(fā)方和客戶方的責(zé)任人對《產(chǎn)品需求規(guī)格說明書》作書面承諾。 軟件需求規(guī)格說明書的參考模板 Page 31 軟件需求說明書的參考模板 Page 32 9. 需求管理：確認(rèn)、跟蹤、變更控制 需求 確認(rèn)（評審和承諾） ? 需求確認(rèn)是指開發(fā)方和客戶方共同對《產(chǎn)品需求規(guī)格說明書》進(jìn)行評審，雙方對需求達(dá)成共識后作出承諾。需求確認(rèn)包含兩個(gè)重要工作： “ 需求評審 ” 和 “ 需求承諾 ” 。 需求評審面臨的困難 ? 需求評審的一個(gè)通病是 “ 虎頭蛇尾 ” 。 需求評審的確乏味 ， 也比較費(fèi)腦子 。 剛開始評審時(shí) ， 大家都比較認(rèn)真 ， 越到后頭越馬虎 。 ? 需求評審涉及的人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長的時(shí)間開會并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進(jìn)的過程，需求評審也可以分段進(jìn)行。這樣每次評審的時(shí)間比較短，參加評審的人員也少一些，組織會議就比較容易。 ? 開評審會議時(shí)經(jīng)常會 “ 跑題 ” ，導(dǎo)致評審效率很低。有時(shí)話匣子一打開后關(guān)不上，大家越扯越遠(yuǎn)，結(jié)果評審會議變成了聊天會議。主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無關(guān)的東西。 ? 開評審會議時(shí)經(jīng)常會發(fā)生爭議。適當(dāng)?shù)臓幾h有利于澄清問題，比什么東西都一致贊成要好。然而當(dāng)爭議變?yōu)闋幊硶r(shí)就壞事了， 爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。 ? 人們在很多時(shí)候分不清楚自己究竟是 “ 堅(jiān)持真理 ” 還是 “ 固執(zhí)己見 ” 。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點(diǎn)，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。 Page 33 9. 需求管理：確認(rèn)、跟蹤、變更控制 需求 承諾 ? 需求承諾是指開發(fā)方和客戶方的責(zé)任人對通過了正式技術(shù)評審的《產(chǎn)品需求規(guī)格說明書》作出承諾，該承諾具有商業(yè)合同的效果。 ? 需求承諾的 “ 八股文 ” 如下： – 本 《 產(chǎn)品需求規(guī)格說明書 》 建立在雙方對需求的共同理解基礎(chǔ)之上 ， 我同意后續(xù)的開發(fā)工作根據(jù)該 《 產(chǎn)品需求規(guī)格說明書 》 開展 。 如果需求發(fā)生變化 ， 我們將按照 “ 變更控制規(guī)程” 執(zhí)行 。 我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本 、 資源和進(jìn)度等 。 – 甲方簽字 乙方簽字 ? 人們在作出承諾之前務(wù)必要認(rèn)真閱讀文檔 ， 一定要明白簽字意味著什么 。 Page 34 9. 需求管理：確認(rèn)、跟蹤、變更控制 需求 跟蹤 ? 需求跟蹤的目的是建立與維護(hù)“需求－設(shè)計(jì)－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。 ? 需求跟蹤有兩種方式： – 正向跟蹤。檢查《產(chǎn)品需求規(guī)格說明書》中的每個(gè)需求是否都能在后繼工作成果中找到對應(yīng)點(diǎn)。 – 逆向跟蹤。檢查設(shè)計(jì)文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。 ? 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對應(yīng)關(guān)系。 Page 35 9. 需求管理：確認(rèn)、跟蹤、變更控制 需求變更控制 ? 需求發(fā)生變更的起因主要有： – 隨著項(xiàng)目的進(jìn)展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯(cuò)誤或不足，因此要變更需求。 – 市場發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前的市場需求，因此要變更需求。 ? 提出需求變更的動機(jī)是好的，目的是希望產(chǎn)品更加符合用戶的需求。對項(xiàng)目開發(fā)小組而言， 變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)小組要為此付出較重的代價(jià)。如果每次需求變更請求都被采納的話，這個(gè)項(xiàng)目也許永遠(yuǎn)不能按時(shí)完成。 ? 需求變更控制的目的： 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。 ? 需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個(gè)問題最好的辦法是事先建立“游戲規(guī)則”： – 開發(fā)方與客戶方達(dá)成“事不過三”的約定（符合中國人的習(xí)慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開發(fā)方有權(quán)拒絕，除非客戶愿意補(bǔ)償開發(fā)方的損失。 ? 如果事先沒有“游戲規(guī)則”的話，開發(fā)方需要一些社交技巧來減緩矛盾。例如建議在開發(fā)該產(chǎn)品新版本時(shí)修改需求。