【正文】 對(duì)于任何重要的工作成果，都應(yīng)該至少執(zhí)行一次正式技術(shù)評(píng)審，建議在正。度量 項(xiàng)目經(jīng)理統(tǒng)計(jì)工作量和上述文檔的規(guī)模。啟動(dòng)準(zhǔn)則 需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》已經(jīng)完成。角色與職責(zé) 開發(fā)方和客戶共同組織人員對(duì)需求文檔進(jìn)行評(píng)審。需求確認(rèn)包含兩個(gè)重要工作：“需求評(píng)審”和“需求承諾” ，一般規(guī)程如表 47 所示。角色名稱 職責(zé)描述6. 產(chǎn)品的功能性需求 需求分類功能類別 功能名稱、標(biāo)識(shí)符 描述Function Feature A…Function Feature B…Function Feature C… Feature M Function 名稱、標(biāo)識(shí)符優(yōu)先級(jí)功能描述輸入、輸出操作序列等其它說明7. 產(chǎn)品的非功能性需求需求類別 需求名稱、標(biāo)識(shí)符 描述用戶界面需求軟硬件需求質(zhì)量需求8. 其它需求附錄 A：需求建模附錄 B：需求評(píng)審報(bào)告摘要附錄 C：需求承諾表 46 《軟件需求規(guī)格說明書》的文檔模板第 4 章 需求開發(fā)與需求管理Page 26 of 34 需求確認(rèn) 規(guī)程需求確認(rèn)是指開發(fā)方和客戶方共同對(duì)需求文檔如《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出承諾。第 4 章 需求開發(fā)與需求管理Page 25 of 345. 產(chǎn)品中的角色提示：闡述本產(chǎn)品的各種角色及其職責(zé)。4. 產(chǎn)品范圍提示：闡述本產(chǎn)品 “適用的領(lǐng)域 ”和 “不適用的領(lǐng)域 ”，本產(chǎn)品 “應(yīng)當(dāng)包含的內(nèi)容 ”和 “不包含的內(nèi)容 ”。 （ 2）介紹產(chǎn)品的開發(fā)背景。表 46 是本書作者制定的《軟件需求規(guī)格說明書 》的文檔模板，供讀者參考。例如人們通常著重于寫功能性需求，卻忘了或者壓根就沒有想到還要寫非功能性需求。（3）要點(diǎn)完備。那怕是天下最無能的領(lǐng)導(dǎo)，都知道在作報(bào)告時(shí)要先從宏觀上講一、二、三、四、五，再?gòu)募?xì)節(jié)上講 A、B、C、D、E。所以開發(fā)人員應(yīng)當(dāng)根據(jù)項(xiàng)目的特征，定制最貼切于該項(xiàng)目的文檔模板。關(guān)于軟件需求規(guī)格說明書的文檔模板非常多，目前國(guó)際上沒有（也不可能有）統(tǒng)一的標(biāo)準(zhǔn)。（2）按照文檔模板寫出來的《軟件需求規(guī)格說明書》比較規(guī)范，容易被用戶和開發(fā)人員接受。需求評(píng)審之后，開發(fā)方和客戶方的責(zé)任人對(duì)《產(chǎn)品需求規(guī)格說明書》作書面承諾。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話，則應(yīng)當(dāng)分別撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》。補(bǔ)充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當(dāng)根據(jù)自身水平進(jìn)行取舍。表 42 需求調(diào)查的規(guī)程定義產(chǎn)品需求的主要步驟如下：? 第一步：細(xì)化并分析用戶需求需求分析員首先對(duì)《用戶需求說明書》進(jìn)行細(xì)化，對(duì)比較復(fù)雜的用戶需求進(jìn)行建模分析，以幫助軟件開發(fā)人員更好地理解需求。開發(fā)方和客戶方已經(jīng)對(duì)產(chǎn)品需求進(jìn)行了確認(rèn)（包括需求評(píng)審和承諾） 。啟動(dòng)準(zhǔn)則 《用戶需求說明書》已經(jīng)撰寫完成。角色與職責(zé) 需求分析員定義產(chǎn)品需求。 如何定義產(chǎn)品需求 規(guī)程產(chǎn)品需求定義的一般規(guī)程如表 45 所示。所以他們?cè)谡{(diào)查、分析、定義需求時(shí)，自然會(huì)想到“怎么做” ，這并沒有第 4 章 需求開發(fā)與需求管理Page 23 of 34什么過錯(cuò)。 “怎么做”是系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階段的事情。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級(jí)。久病成醫(yī)那，人們想出了“取舍”辦法：先做優(yōu)先級(jí)高的需求，后做（甚至放棄）優(yōu)先級(jí)低的需求，這樣可以將風(fēng)險(xiǎn)降到最低。但是在現(xiàn)實(shí)之中，項(xiàng)目存在“進(jìn)度、費(fèi)用、人力資源”等限制。例如，摩天大樓的一項(xiàng)需求是“抗十二級(jí)臺(tái)風(fēng)” ，這個(gè)需求看起來堂而皇之，但是如何驗(yàn)證呢？當(dāng)摩天大樓完工后驗(yàn)收時(shí)，用戶又不是巫師，他怎能造個(gè)十二級(jí)臺(tái)風(fēng)來試驗(yàn)？如果雙方都認(rèn)可“采用計(jì)算機(jī)模擬十二級(jí)臺(tái)風(fēng)”等效于實(shí)際測(cè)試，那么這項(xiàng)需求就是“可驗(yàn)證”的。 可驗(yàn)證《產(chǎn)品需求規(guī)格說明書》中的各項(xiàng)需求對(duì)用戶方而言應(yīng)當(dāng)都是可驗(yàn)證的（Verifiable） 。經(jīng)過雙方確認(rèn)的《產(chǎn)品需求規(guī)格說明書》相當(dāng)于商業(yè)合同，如果開發(fā)方不能夠?qū)崿F(xiàn)《產(chǎn)品需求規(guī)格說明書》中的內(nèi)容，那就是違約，可能會(huì)被罰款的。營(yíng)銷人員和用戶談生意時(shí)，為了能拿到“單子” ，他們往往對(duì)用戶提出的需求“來者不拒” 。第 4 章 需求開發(fā)與需求管理Page 22 of 34 可實(shí)現(xiàn)《產(chǎn)品需求規(guī)格說明書》中的各項(xiàng)需求對(duì)開發(fā)方而言應(yīng)當(dāng)都是可實(shí)現(xiàn)的（Attainable） 。消費(fèi)是人們的需求，但上廁所也是人們的需求。人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。 完備“完備” （Complete ）是指《 產(chǎn)品需求規(guī)格說明書》中沒有遺漏一些必要的需求。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求。據(jù)說基于 Windows 系統(tǒng)的汽車控制軟件有這么一項(xiàng)功能，當(dāng)汽車發(fā)生碰撞時(shí)該軟件會(huì)彈出一個(gè)對(duì)話框：您需要使用安全氣囊嗎？按 OK 鍵表示需要，按 Cancel 鍵表示不需要。我們可以把“必要”比喻為“雪中送炭” 。據(jù)說后來恐怖分子們利用了這兩個(gè)計(jì)劃之間的矛盾，用這種導(dǎo)彈打這種防御系統(tǒng)，給這個(gè)國(guó)家造成了很多麻煩。同時(shí)這個(gè)國(guó)家的“導(dǎo)彈防御系統(tǒng)發(fā)展計(jì)劃”是這樣寫的：我們要研制世界上最先進(jìn)的導(dǎo)彈防御系統(tǒng)，使得任何導(dǎo)彈來 襲都落得“ 肉包子打狗，有去無回”的下場(chǎng)。地球上有個(gè)超級(jí)大國(guó)的“導(dǎo)彈發(fā)展計(jì)劃”是這樣寫的：我們要研制世界上最先進(jìn)的導(dǎo)彈，我們想打哪里就打哪里，任何防御系統(tǒng)都對(duì)它無可奈何。第 4 章 需求開發(fā)與需求管理Page 21 of 34 一致“一致” （Consistent）是指《產(chǎn)品需求規(guī)格說明書》中各個(gè)需求之間不會(huì)發(fā)生矛盾。例如阿富汗人民心目中的“小康”對(duì)美國(guó)人們而言簡(jiǎn)直不如乞丐的生活水平。80 年代中國(guó)老百姓致富的口號(hào)是“奔小康” ，這個(gè)口號(hào)聽起來“正確”并且“清楚” ，但不能當(dāng)成政策來推行。如果一個(gè)人說的話，不同的人可能有不同的理解，那么這句話就有二義性。清楚的反義詞是“難讀” 、 “難理解” 。（4） 如果我搶別人的東西，你幫我打他。（2） 如果有人搶我的東西，你幫我打他。 清楚電影《新少林五祖》里有一段精彩的需求對(duì)話。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么” 。 正確需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實(shí)意圖， “正確”是《產(chǎn)品需求規(guī)格說明書》最重要的屬性。如果產(chǎn)品很復(fù)雜，雙方都不太明白需求，此時(shí)最好請(qǐng)開發(fā)人員快速構(gòu)造軟件的原型，雙方看著軟件原型再分析需求。? 當(dāng)開發(fā)者想象中的產(chǎn)品與客戶所提的需求有沖突時(shí)，一般應(yīng)當(dāng)尊重客戶的觀點(diǎn)。大家值得為不是真理的需求爭(zhēng)得不可開交嗎？? 如果一個(gè)產(chǎn)品可以賣給幾類客戶，但是各類客戶都要求產(chǎn)品按照他們的喜好來開發(fā)。這樣做的好處是當(dāng)出了差錯(cuò)時(shí)，需求分析員就有理由為自己辯護(hù)，從而保護(hù)自身利益。以下是一些經(jīng)驗(yàn)之談：? 如果一群人對(duì)需求有爭(zhēng)議，并不是誰聲音最響就聽誰的。對(duì)于那些難以達(dá)成共識(shí)的需求而言，經(jīng)常會(huì)發(fā)生“公說公有理，婆說婆有理”的現(xiàn)象。建議將模型存放在需求文檔的附錄中，便于正文引用。需求建模不可能取代文字描述。要注意的是：在建模時(shí)使用花樣過多的圖形符號(hào)或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。介紹 UML 和 Rose 的書籍非常多，讀者自己選擇、學(xué)習(xí)，這里不再論述。真正使 UML 流行的是 Rational 公司基于 UML 的建模工具 Rose。UML 的建模能力超過了以往任何一種 OOAD 方法，當(dāng)然其復(fù)雜性也隨之膨脹。1997 年 11 月，UML 被國(guó)際對(duì)象管理組織（OMG）采納，此后 UML 成為 OOAD 建模語言的國(guó)際標(biāo)準(zhǔn)。這種混亂的局面被學(xué)術(shù)界稱為百家爭(zhēng)鳴，每年誕生了許多論著和教授。? Rumbaugh 學(xué)派，其代表作為[Rumbaugh91]。? Booch 學(xué)派，其代表作為[Booch94] 。搞軟件研發(fā)的人都“言必談對(duì)象” ，并引以為榮。我在讀本科（90 年至 94 年）時(shí)就充分地感受到了人們對(duì)“面向?qū)ο蟆钡目駸帷? “狀態(tài)－變遷圖”表示了系統(tǒng)存在的各種狀態(tài)以及它們之間的變遷方式。? “實(shí)體－關(guān)系圖”是用圖形符號(hào)來標(biāo)識(shí)數(shù)據(jù)對(duì)象以及它們之間的關(guān)系。對(duì)結(jié)構(gòu)化分析方法有較大貢獻(xiàn)的學(xué)者有 DeMarco, Gane, Sarsen, Yourdon, Constantine, Ward, Mellor, Hatly, Pirbhai 等人。相反地，它是幾乎發(fā)展了 20 多年的一個(gè)混合物。 結(jié)構(gòu)化分析法軟件的建模分析興起于 20 世紀(jì) 60 年代末期和 70 年代初期。需求建模就是指用圖形符號(hào)來表示、刻畫需第 4 章 需求開發(fā)與需求管理Page 18 of 34求。在需求開發(fā)過程中，對(duì)于某些類型的信息，用圖形表示要比文本表示更加有效。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。每個(gè)需求都應(yīng)當(dāng)用陳述句說明“是什么” ，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補(bǔ)充說明“不是什么” 。一個(gè)人可以“自問自答”地分析需求，幾個(gè)人分析需求則稱為“研討” 。根據(jù)作者的經(jīng)驗(yàn)， “問答分析法”比較適合于用戶需求調(diào)查階段，而“建模分析法”比較適合于產(chǎn)品需求定義階段。后者技術(shù)性比較強(qiáng)，寫出來有學(xué)術(shù)味，故大多數(shù)軟件工程書籍都有論述。需求分析是需求開發(fā)過程中最費(fèi)腦子的工作。事實(shí)上，很多時(shí)候用戶說不清楚需求、會(huì)說錯(cuò)需求或者提出一些無法實(shí)現(xiàn)的需求。4. 產(chǎn)品的功能性需求功能類別 功能名稱、標(biāo)識(shí)符 描述Function Feature A…Function Feature B…Function Feature C…5. 產(chǎn)品的非功能性需求需求類別 需求名稱、標(biāo)識(shí)符 描述用戶界面需求軟硬件需求質(zhì)量需求6. 其它需求附錄：用戶需求調(diào)查報(bào)告表 44 《用戶需求說明書》的參考模板第 4 章 需求開發(fā)與需求管理Page 17 of 34 如何進(jìn)行需求分析為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是上帝，用戶永遠(yuǎn)是正確的。 （ 2）介紹產(chǎn)品的開發(fā)背景。第 4 章 需求開發(fā)與需求管理Page 16 of 34《用戶需求說明書》的參考模板見表 44。（3）兩者之間可能并不存在一一影射關(guān)系，因?yàn)檐浖_發(fā)商會(huì)根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當(dāng)前狀況適當(dāng)?shù)卣{(diào)整產(chǎn)品需求，例如用戶需求可能被分配到軟件的數(shù)個(gè)版本中?！队脩粜枨笳f明書》與《產(chǎn)品需求規(guī)格說明書》的主要區(qū)別與聯(lián)系是：（1）前者主要采用自然語言（和應(yīng)用域術(shù)語）來表達(dá)用戶需求，其內(nèi)容相對(duì)于后者而言比較粗略，不夠詳細(xì)。《用戶需求說明書》撰寫完畢之后，需求分析員應(yīng)當(dāng)邀請(qǐng)同行專家和用戶（包括客戶和最終用戶）一起評(píng)審《用戶需求說明書》 ，盡最大努力使《用戶需求說明書》能夠正確無誤地反映用戶的真實(shí)意愿。 撰寫用戶需求說明書需求分析員對(duì)收集到的所有需求信息進(jìn)行分析（方法詳見 節(jié)） ，消除錯(cuò)誤，歸納與總結(jié)共性的用戶需求。如果有些事情現(xiàn)場(chǎng)就能分析清楚，那么不要拖延到以后做。? 盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調(diào)查的力度。? 如果雙方氣氛融洽，可以采用靈活的訪談形式，輕易不要打斷用戶的談話。 ”也許這筆生意就泡湯了。IT 人士不可貌相，有些大企業(yè)的領(lǐng)導(dǎo)其外表很土氣，象農(nóng)民。要注意禮節(jié)，盡可能獲得用戶的好感，并為下次打擾他們埋下伏筆。在調(diào)查過程中隨時(shí)記錄（或存儲(chǔ)）需求信息，建議采用表格的形式，如表 43 所示。要特別留意的是不要漏掉典型的用戶。? 從 Inter 上搜查相關(guān)資料。? 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。? 向用戶群體發(fā)調(diào)查問卷。? 其次，需求分析員應(yīng)當(dāng)確定需求調(diào)查的方式，例如：? 與用戶交談，向用戶提問題。根據(jù)經(jīng)驗(yàn)，用戶通常沒有耐心回答復(fù)雜的“論述題” ，所以問題表應(yīng)當(dāng)以“選擇題”和“是非題”為主。表 42 需求調(diào)查的規(guī)程 準(zhǔn)備調(diào)查需求調(diào)查準(zhǔn)備工作圍繞三項(xiàng)展開：（1）調(diào)查什么？（2）通過什么方式去調(diào)查？（3）“何人”在“何時(shí)”調(diào)查？? 首先，需求分析員應(yīng)當(dāng)起草需求調(diào)查問題表，將調(diào)查重點(diǎn)鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。啟動(dòng)準(zhǔn)則 需求分析員已經(jīng)確定輸入 任何與用戶需求相關(guān)的材料主要步驟 第一步：準(zhǔn)備調(diào)查第 4 章 需求開發(fā)與需求管理Page 14 of 34第二步：調(diào)查與記錄第三步：分析需求信息第四步：撰寫《用戶需求說明書》第五步：需求確認(rèn)輸出 《用戶需求說明書》結(jié)束準(zhǔn)則 需求分析員已經(jīng)撰寫完成《用戶需求說明書》 ，確保無拼寫、排版等錯(cuò)誤。目的 獲取用戶（客戶與最終用戶）的需求信息，經(jīng)過分析后產(chǎn)生《用戶需求說明書》 。 如何開展需求調(diào)查 需求調(diào)查規(guī)程開展需求調(diào)查不能學(xué)情人之間的浪漫做法——“讓我摸摸你的頭發(fā)，感覺它是什么顏色。其實(shí)需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項(xiàng)目混亂。倘若市場(chǎng)靜如死水，那么開發(fā)商吃了“上一頓”就沒有“下一頓” 。這種損失是由于雙方工作失誤造成的，雙方應(yīng)當(dāng)好好反省，認(rèn)真學(xué)習(xí)需求開發(fā)和管理的方法，避免再犯相似的錯(cuò)誤。如果在項(xiàng)目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開發(fā)后期才將需求糾正過來，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開發(fā)。另外，企業(yè)應(yīng)當(dāng)提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度。我可以毫不夸張地說，國(guó)內(nèi) 90％以上的軟件開發(fā)人員，他們的寫作能力遠(yuǎn)不及開發(fā)能力。 ”所以要想寫出好的需求文檔，前提條件是把需求調(diào)查工作做好。古時(shí)候，一書生在考試前補(bǔ)習(xí)“寫文章” ，成天愁眉苦臉。所以需求確認(rèn)工作（屬于需求管理）必