【正文】 – 文檔的語句是否含糊其詞 、 羅里羅嗦 ？ – 看了半天是否還不明白需求究竟是什么 ？ 無二義性 ? “ 無二義性 ” 是指每個(gè)需求只有唯一的含義。 “ 必要 ” 往前一步 ， 要么是 “ 畫蛇添足 ” 要么是 “ 錦上添花 ” 。 ? 不完備的《產(chǎn)品需求規(guī)格說明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時(shí)可能無法完成預(yù)期的任務(wù)。 如果需求是不可驗(yàn)證的 ， 那么用戶就無法驗(yàn)收軟件 ， 可能會發(fā)生商業(yè)糾紛 。 闡述 “ 做什么 ” 而不是 “ 怎么做 ” ? 《 產(chǎn)品需求規(guī)格說明書 》 的重點(diǎn)是闡述 “ 做什么 ” ， 而不是闡述 “ 怎么做 ” 。 ? 第二步：撰寫產(chǎn)品需求規(guī)格說明書 – 需求分析員按照指定的文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》。 剛開始評審時(shí) ， 大家都比較認(rèn)真 ， 越到后頭越馬虎 。適當(dāng)?shù)臓幾h有利于澄清問題，比什么東西都一致贊成要好。 我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本 、 資源和進(jìn)度等 。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。 ? 需求變更控制的目的： 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。例如建議在開發(fā)該產(chǎn)品新版本時(shí)修改需求。對項(xiàng)目開發(fā)小組而言， 變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)小組要為此付出較重的代價(jià) 。檢查設(shè)計(jì)文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。 ? 需求承諾的 “ 八股文 ” 如下： – 本 《 產(chǎn)品需求規(guī)格說明書 》 建立在雙方對需求的共同理解基礎(chǔ)之上 ， 我同意后續(xù)的開發(fā)工作根據(jù)該 《 產(chǎn)品需求規(guī)格說明書 》 開展 。主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無關(guān)的東西。 需求評審面臨的困難 ? 需求評審的一個(gè)通病是 “ 虎頭蛇尾 ” 。例如采用 Rational 的 Rose工具進(jìn)行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明書》的附件。 ? 需求的優(yōu)先級其實(shí)就是需求 “ 輕重緩急 ” 的分級表述，例如劃分為 “ 高、中、低 ” 三級。 ? 對于合同項(xiàng)目，如果開發(fā)方不能確信某些需求是否可實(shí)現(xiàn)，則應(yīng)事先與用戶協(xié)商，達(dá)成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。 完備 ? “ 完備 ” （ Complete） 是指《產(chǎn)品需求規(guī)格說明書》中沒有遺漏一些必要的需求。 必要 ? 《 產(chǎn)品需求規(guī)格說明書 》 中的各項(xiàng)需求對用戶而言應(yīng)當(dāng)都是必要的 。 清楚 ? 清楚的需求讓人易讀易懂 。此時(shí)對需求的決策應(yīng)當(dāng)以商業(yè)利益為導(dǎo)向， 即哪一類客戶出錢最多就先滿足他們的需求，以后再做那些獲利相對較少的需求。 需求建模不可能取代文字描述 。 ? 其它常見的問題有： – 需求存在二義性嗎？ – 需求文檔的上下文有矛盾嗎？ – 需求完備嗎？ – 需求是必要的嗎？ – 需求可實(shí)現(xiàn)嗎？ – 需求可驗(yàn)證嗎？ – 需求的優(yōu)先級確定了嗎？ Page 23 6. 如何進(jìn)行需求分析 建模分析法 ? 人們都有這樣地感受：有些時(shí)候用語言描述某個(gè)問題特別費(fèi)勁，而采用圖形則使人一目了然，所謂 “ 一圖低千言 ” 就是這個(gè)道理。前者就是一些常識而已，雖然寫不成文章，但是簡單易用（保你一學(xué)就會），很有實(shí)用價(jià)值。軟件開發(fā)人員應(yīng)當(dāng)依據(jù)《產(chǎn)品需求規(guī)格說明書》來開發(fā)當(dāng)前產(chǎn)品。 – 需求調(diào)查不象偵探推理那樣從蛛絲馬跡著手，應(yīng)該先了解宏觀問題，再了解細(xì)節(jié)問題。 Page 18 5. 如何開展需求調(diào)查 執(zhí)行調(diào)查 ? 準(zhǔn)備工作完畢后，需求分析員按照計(jì)劃執(zhí)行調(diào)查。向用戶群體發(fā)調(diào)查問卷。 正因?yàn)槭袌鲈谧兓?，才會產(chǎn)生更多商機(jī)，聰明的開發(fā)商才會有活干，有錢賺。 – 提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習(xí)寫文檔，熟能生巧?！? ? 不論是復(fù)雜的項(xiàng)目還是簡單的項(xiàng)目，需求分析員和用戶都有可能誤解需求。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。 – 比如說買鞋子。 – 3. 在不泄漏機(jī)密的前提下，盡可能地向需求分析員提供與需求相關(guān)的材料。 如果條件允許的話 ， 開發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn) ， 這樣的培訓(xùn)將 使用戶明白需求的重要性以及忽視需求的危害性 ， 從而促使他們積極友善地參加需求工程中的各項(xiàng)活動 。 ? 對于一些競標(biāo)項(xiàng)目 ， 在合同未簽訂之前的需求開發(fā)工作尤為困難 。 ? 用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設(shè)法解決的。人一生中會有許多充滿挫折的 “第一次 ” ，不可以逃避。他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé)，會想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責(zé)任。 ? 需求跟蹤 是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護(hù) “ 需求跟蹤矩陣 ” ，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。 ? 需求工程的結(jié)構(gòu)圖 Page 8 3. 需求工程基本概念 需求開發(fā)過程域 ? 需求開發(fā) 的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。午休時(shí)他們可以躺著睡，我們只能坐在位置上打個(gè)盹兒 …… .。客戶是把他的欲望帶給我們的人，因此我們的工作就是滿足這些欲望，從而使客戶和我們共同獲益。客戶與最終用戶可能是同一個(gè)人也可能不是同一個(gè)人。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。最困難的概念性工作是編寫出詳細(xì)的需求，包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。 ? 掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶。從未有人曾在與客戶的爭辯中獲勝。由于休息室空間有限，請大家自覺讓位。 ? 需求工程中的活動可分為兩大類，一類屬于需求開發(fā)，另一類屬于需求管理。 ? 需求確認(rèn) 是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。 – “ 主動型 ” 是指開發(fā)者積極地開展需求工程中的各項(xiàng)活動。一個(gè)企業(yè)要謀求發(fā)展，不能總在做老的業(yè)務(wù)。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應(yīng)當(dāng)開發(fā)什么嗎？如果用戶說不清楚需求，或者經(jīng)常變更需求，這類問題是用戶產(chǎn)生的，應(yīng)當(dāng)由他們自己負(fù)責(zé)。你們自己想辦法把活干好吧 …… 。 “ 好話 ” 和 “ 丑話 ” 都說在前頭 ， 這樣能減少今后的摩擦 。 – 2. 樂意接受需求分析員的采訪，在不泄漏機(jī)密的前提下盡可能地回答需求分析員的問題。 ? 有些用戶雖然心里明白想要什么，但卻說不清楚需求。最后，心動的用戶對軟件開發(fā)人員說：“好得很，就讓我們馬上行動起來吧。 …… 有趣的是，車?yán)镒≈环N叫作‘人’的寄生蟲，這些寄生蟲完全控制了車。