【文章內(nèi)容簡介】 可能 性有多大？ 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ī)則。 4. 產(chǎn)品的功能需求 … … Function Feature C … … Function Feature B … … Function Feature A 描述 功能名稱、標(biāo)識符 功能類別 5. 產(chǎn)品的非功能需求 質(zhì)量需求 軟硬件需求 用戶界面需求 描述 需求名稱、標(biāo)識符 需求類別 6. 其他需求 軟件需求規(guī)格說明書 需求確認(rèn) 為什么需要需求評審？ 在哪個階段發(fā)現(xiàn) 成本 率 需求 1 設(shè)計 36 編碼 10 功能測試 1540 驗收測試 3070 發(fā)布之后 401000 修訂一個缺陷的相關(guān)成本 需求確認(rèn) 如何進行需求評審？ （ 1）分層次評審 ? 目標(biāo)性評審 ? 功能性評審 ? 操作性評審 （ 2）分階段評審 2 需求評審面臨的困難 ? 需求評審的一個通病是 “ 虎頭蛇尾 ” 。 需求評審的確乏味 ， 也比較費腦子 。 剛開始評審時 ， 大家都比較認(rèn)真 ， 越到后頭越馬虎 。 ? 需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。 ? 開評審會議時經(jīng)常會 “ 跑題 ” ，導(dǎo)致評審效率很低。有時話匣子一打開后關(guān)不上，大家越扯越遠(yuǎn)，結(jié)果評審會議變成了聊天會議。主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無關(guān)的東西。 ? 開評審會議時經(jīng)常會發(fā)生爭議。適當(dāng)?shù)臓幾h有利于澄清問題，比什么東西都一致贊成要好。然而當(dāng)爭議變?yōu)闋幊硶r就壞事了， 爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。 ? 人們在很多時候分不清楚自己究竟是 “ 堅持真理 ” 還是 “ 固執(zhí)己見 ” 。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。 需求確認(rèn) 如何保證需求規(guī)格說明書的質(zhì)量？ ? 正確性 ? 完備性 ? 易理解性 ? 一致性 ? 可行性 ? 健壯性 ? 易修改性 ? 易測試性和可修改性 ? 易追溯性 ? 兼容性 . 什么是好的需求規(guī)格說明書 .1 正確 ? 需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實意圖， “ 正確 ” 是 《 產(chǎn)品需求規(guī)格說明書 》 最重要的屬性。如果 “ 不正確 ” 僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟 “ 想要什么 ”和 “ 不要什么 ” 。為確保需求是正確的，開發(fā)方和用戶必須對 《 需求規(guī)格說明書 》進行確認(rèn)。 .2 清楚 ? 清楚的需求讓人易讀易懂 。 清楚的反義詞是 “ 難讀 ” 、 “ 難理解 ” 。 你可以采用反問的方式來判斷需求文檔是否清楚： – 文檔的結(jié)構(gòu) 、 段落是否亂七八糟 ？ 上下文是否不連貫 ？ – 文檔的語句是否含糊其詞 、 羅里羅嗦 ？ – 看了半天是否還不明白需求究竟是什么 ？ .3 無二義性 ? “ 無二義性 ” 是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。 ? 為了使需求無二義性，人們在寫 《 產(chǎn)品需求規(guī)格說明書 》 時措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。 什么是好的需求規(guī)格說明書 .4 一致 ? “ 一致 ” （ Consistent）是指 《 產(chǎn)品需求規(guī)格說明書 》 中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。 .5 必要 ? 《 產(chǎn)品需求規(guī)格說明書 》 中的各項需求對用戶而言應(yīng)當(dāng)都是必要的 。 ? 可以把 “ 必要 ” 比喻為 “ 雪中送炭 ” 。 “ 必要 ” 往前一步 ， 要么是 “ 畫蛇添足 ” 要么是 “ 錦上添花 ” 。 ? “ 畫蛇添足 ” 顯然是壞事 ， 會導(dǎo)致開發(fā)人員多干一些吃力不討好的工作 。 所以要盡量剔除需求規(guī)格說明書中 “ 畫蛇添足 ” 的那些需求 。 ? “ 錦上添花 ” 是好事 ， 可能會讓用戶獲得比期望更多的喜悅 ， 但是眼前用戶不會為此多付錢 。 開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求 ， 如果條件允許則再做 “ 錦上添花 ” 的需求 。 為了避免主次顛倒 ， 應(yīng)當(dāng)在 《 產(chǎn)品需求規(guī)格說明書 》 中將那些 “ 錦上添花 ” 的需求設(shè)置為較低的優(yōu)先級 。 .6 完備 ? “ 完備 ” （ Complete）是指 《 產(chǎn)品需求規(guī)格說明書 》 中沒有遺漏一些必要的需求。 ? 人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。 ? 不完備的 《 產(chǎn)品需求規(guī)格說明書 》 將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時可能無法完成預(yù)期的任務(wù)。 . 什么是好的需求規(guī)格說明書 7 可實現(xiàn) ? 《 產(chǎn)品需求規(guī)格說明書 》 中的各項需求對 開發(fā)方 而言應(yīng)當(dāng)都是可實現(xiàn)的（ Attainable）。 ? “ 可實現(xiàn) ” 意味著在技術(shù)上是可行的，并且滿足時間、費用、質(zhì)量等約束。 ? 營銷人員和用戶談生意時，為了能拿到 “ 單子 ” ，他們往往對用戶提出的需求 “ 來者不拒 ” 。吹牛皮雖然不犯法，但是 《 產(chǎn)品需求規(guī)格說明書 》 可是白紙黑字啊。經(jīng)過雙方確認(rèn)的 《 產(chǎn)品需求規(guī)格說明書 》 相當(dāng)于商業(yè)合同，如果開發(fā)方不能夠?qū)崿F(xiàn)《 產(chǎn)品需求規(guī)格說明書 》 中的內(nèi)容，那就是違約，可能會被罰款的。 ? 對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應(yīng)事先與用戶協(xié)商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。 .8 可驗證 ? 《 產(chǎn)品需求規(guī)格說明書 》 中的各項需求對 用戶方 而言應(yīng)當(dāng)都是可驗證的（ Verifiable） 。 如果需求是不可驗證的 ， 那么用戶就無法驗收軟件 ， 可能會發(fā)生商業(yè)糾紛 。 ? 例如 ， 摩天大樓的一項需求是 “ 抗十二級臺風(fēng) ” ， 這個需求看起來堂而皇之 ， 但是如何驗證呢 ？ 當(dāng)摩天大樓完工后驗收時 ， 用戶又不是巫師 ， 他怎能造個十二級臺風(fēng)來試驗 ？ 如果雙方都認(rèn)可 “ 采用計算機模擬十二級臺風(fēng) ” 等效于實際測試 ， 那么這項需求就是 “ 可驗證 ” 的 。 . 什么是好的需求規(guī)格說明書 .9 確定優(yōu)先級 ? 為什么要確定需求的 “ 優(yōu)先級 ” ？ – 理論上講，軟件的所有需求都應(yīng)當(dāng)被實現(xiàn)。但是在現(xiàn)實之中，項目存在 “ 進度、費用、人力資源 ” 等限制。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨 “ 進度延誤、費用超支、人員不足 ”等問題，這時就亂套了。 – 人們想出了 “ 取舍 ” 辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風(fēng)險降到最低。 ? 需求的優(yōu)先級其實就是需求 “ 輕重緩急 ” 的分級表述，例如劃分為 “ 高、中、低 ”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。 10 闡述 “ 做什么 ” 而不是 “ 怎么做 ” ? 《 產(chǎn)品需求規(guī)格說明書 》 的重點是闡述 “ 做什么 ” ， 而不是闡述 “ 怎么做 ” 。 “ 怎么做 ” 是系統(tǒng)設(shè)計和實現(xiàn)階段的事情 。 ? 國內(nèi)的很多軟件公司里 ， 開發(fā)人員常常身兼數(shù)職 ， 可能把需求開發(fā) 、 系統(tǒng)設(shè)計 、 編程等工作從頭做到尾 。 所以他們在調(diào)查 、 分析 、 定義需求時 ， 自然會想到 “ 怎么做 ” ， 這并沒有什么過錯 。 如果在調(diào)查 、 定義需求時想好了 “ 怎么做 ” ， 當(dāng)然應(yīng)該寫下來 ， 否則豈不浪費 ！ 關(guān)鍵是不要將 “ 怎么做 ” 寫到需求規(guī)格說明書里面 ， 記錄在其它文檔里就行了 。 良好的需求規(guī)格說明的例子 1 例子： “ 產(chǎn)品應(yīng)在不少于每 60秒的正常周期內(nèi)提供狀態(tài)信息 ” 分析：這個需求是不完整的： 狀態(tài)信息是什么 ， 如何顯示給用戶 。 這個需求有幾處含糊 。 我們在談?wù)摦a(chǎn)品的哪部分 ？ 狀態(tài)信息間隔真的假定為不少于 60秒 ？ ， 甚者每 10年顯示一條新的狀態(tài)信息也可以 ？ 也許它的意圖是消息間隔不應(yīng)超過 60秒 ， 那么 1毫秒是不是太短 ？ “ 每 ” 這個詞導(dǎo)致了不確定性 。 問題的后果 ， 就是需求的不可證實 。 彌補缺陷 ， 重寫需求的一種方法： ?后臺任務(wù)管理器因以誤差上下不超過 10秒的 60秒間隔 ， 在用戶界面的指定位置顯示狀態(tài)信息； ?如果后臺進程處理正常 ， 那么應(yīng)該顯示任務(wù)已完成的百分?jǐn)?shù) /比；