【文章內(nèi)容簡介】 分析法”兩類。? 需求定義。需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》 。系統(tǒng)設(shè)計人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。需求開發(fā)過程域可分為兩個階段：“用戶需求調(diào)查階段”和“產(chǎn)品需求定義階段” 。兩者在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進(jìn)行的。我們把從事需求開發(fā)工作的人員稱為需求分析員（也叫系統(tǒng)分析員） ，避免與其它開發(fā)人員混淆。 “需求分析”活動貫穿于“用戶需求調(diào)查”和“產(chǎn)品需求定義”兩個階段。需求開發(fā)過程域產(chǎn)生的主要文檔有：? 《用戶需求說明書》? 《產(chǎn)品需求規(guī)格說明書》 （對于軟件產(chǎn)品而言就是《軟件需求規(guī)格說明書》 ）需求工程需求開發(fā)需求變更控制需求管理需求確認(rèn)需求跟蹤需求調(diào)查需求分析需求定義第 4 章 需求開發(fā)與需求管理Page 8 of 34需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。需求管理過程域有 3 個主要活動：? 需求確認(rèn)。需求確認(rèn)是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。? 需求跟蹤。需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣” ，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。? 需求變更控制。需求變更控制是指依據(jù)“變更申請－審批－更改－重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項目發(fā)生混亂。需求管理過程域產(chǎn)生的主要文檔有：? 《需求評審報告》? 《需求跟蹤報告》? 《需求變更控制報告》圖 43 需求開發(fā)與需求管理流程圖 一些感悟本章通篇都在講解需求工程的方法與技術(shù)，但是我擔(dān)心讀者辛苦地學(xué)習(xí)了，卻可能在實踐時用歪了。因此我要先談?wù)勛约簩π枨蠊こ痰囊恍└形?。需求工程感悟之一：不論是合同項目還是自主研發(fā)的產(chǎn)品，都必須開展需求開發(fā)和需求管理活動。對于合同項目，由于客戶是已知的，需求開發(fā)和需求管理的各項活動可以有的放矢地開展。但是對于自主研發(fā)的產(chǎn)品而言，在產(chǎn)品沒有賣出之前，并不存在真正的用戶。由于用戶是未知的，這就產(chǎn)生了令人困惑的問題：究竟該向誰調(diào)查需求？由誰來確認(rèn)需求？需求分析用戶需求說明書產(chǎn)品需求規(guī)格說明書用戶需求調(diào)查輸出輸出產(chǎn)品需求定義需求變更控制需求確認(rèn)需求跟蹤需求開發(fā)過程域需求管理過程域第 4 章 需求開發(fā)與需求管理Page 9 of 34很多開發(fā)人員不知不覺落入陷阱：既然產(chǎn)品是自主研發(fā)的，反正目前沒有用戶，那么就讓我們自己設(shè)想需求、自己確認(rèn)需求吧！此念一起，禍根埋下。如此開發(fā)的產(chǎn)品十有八九會落得前述案例的下場。相似慘痛的教訓(xùn)實在太多，人們一定要清醒啊。即便待開發(fā)的產(chǎn)品尚未有真正的用戶，但必定有潛在的用戶（如果連潛在的用戶都沒有，那么就不要開發(fā)這樣的產(chǎn)品，否則開發(fā)出來賣給誰？） 。開發(fā)人員可以向潛在的用戶們調(diào)查需求，請他們來確認(rèn)需求。如果因條件限制，實在請不到潛在的用戶，那么開發(fā)者可以把自己一分為二，既當(dāng)用戶又當(dāng)分析員。注意在扮演用戶這個角色時，應(yīng)當(dāng)忘記自己是開發(fā)者，一定要真正地站在用戶的立場思考問題。一旦混淆角色，就會犯錯誤。需求工程感悟之二： 開發(fā)者對待需求工程的態(tài)度可分“被動型” 、 “主動型”和“領(lǐng)先型”三種，只有后兩種才有可能開發(fā)出成功的產(chǎn)品。“被動型”是指開發(fā)者被動地對待需求工程中的各項活動，能少干則少干，能偷懶則偷懶。他們認(rèn)為需求是用戶的事情而不是自己的事情。開發(fā)過程中經(jīng)常發(fā)生需求變更，導(dǎo)致產(chǎn)品迷失方向，不是半途而廢就是陷入半死不活的狀態(tài)?！爸鲃有汀笔侵搁_發(fā)者積極地開展需求工程中的各項活動。他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé)，會想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責(zé)任。俗話說“良好的開端是成功的一半” ， “主動型”需求工程是開發(fā)成功產(chǎn)品的必備條件?！邦I(lǐng)先型”是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識到的需求，導(dǎo)致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導(dǎo)消費。需求工程做到這個份上，才能使產(chǎn)品立于不敗之地，長盛不衰。 需求開發(fā)的主要困難與對策 知識技能問題絕大多數(shù)軟件開發(fā)人員在學(xué)生時期的學(xué)習(xí)重點是計算機技術(shù)，他們畢業(yè)后到企業(yè)工作，主要任務(wù)依然是技術(shù)開發(fā)。由于專業(yè)和職業(yè)的原因，多數(shù)軟件開發(fā)人員不擅長與用戶交流。有些人技術(shù)很出色，但與用戶在一起時顯得很木訥，有勁使不出。所以企業(yè)不能期望他們能夠無師自通地把需求開發(fā)工作做好。最好最快的解決辦法是培訓(xùn)。如果你是項目的領(lǐng)導(dǎo)，既然你要把那么重要的工作（需求開發(fā)）交給他們?nèi)プ?，你就要舍得花錢對他們進(jìn)行需求開發(fā)培訓(xùn)，幫助他們把需求開發(fā)工作做好。即使需求分析員對需求調(diào)查、需求分析、需求定義已經(jīng)有了豐富的經(jīng)驗，但他們的知識仍然可能不夠用。應(yīng)用域的知識是無邊無際的，任何人都不可能是“萬事通” 。俗話說“隔行如隔山” ，需求分析員可能是某一領(lǐng)域的專家，但當(dāng)他接手陌生的業(yè)務(wù)時，他可能是個“無知”者。一個企業(yè)要謀求發(fā)展，不能總在做老的業(yè)務(wù)。人一生中會有許多充滿挫折的“第一次” ，不可以逃避。當(dāng)需求分析員缺乏應(yīng)用域知識時，他該怎么辦？首先他要有勇氣做事，否則連實踐的機會都沒有。其次他應(yīng)當(dāng)趕緊補習(xí)應(yīng)用域知識，不第 4 章 需求開發(fā)與需求管理Page 10 of 34論是通過自學(xué)還是培訓(xùn)的方式，否則他很難與用戶交流。如果可能的話，開發(fā)方最好請既懂軟件又懂應(yīng)用域知識的行家來幫忙。如果需求分析員完全不了解應(yīng)用域，而用戶幾乎是個計算機盲，并且雙方都不愿意主動了解對方領(lǐng)域的事情，這種狀況下的需求開發(fā)很難成功。這世上沒有人能夠在知識面前?；ㄕ?， “不懂裝懂，永遠(yuǎn)飯桶” 。 態(tài)度問題相當(dāng)多的開發(fā)人員習(xí)慣于被動地對待需求開發(fā)。每當(dāng)遇到麻煩、挫折時，他們會發(fā)牢騷，找出一堆用戶的毛病。這是普遍現(xiàn)象，并不是開發(fā)人員懶惰所造成的，而是不正確的觀念誤導(dǎo)了他們！很多開發(fā)人員錯誤地以為：需求是用戶的事情，不是我 們 的事情。我 們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應(yīng)當(dāng)開發(fā)什么嗎？如果用戶說不清楚需求，或者經(jīng)常變更需求， 這類問題是用戶產(chǎn)生的，應(yīng)當(dāng)由他們 自己負(fù)責(zé)。用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設(shè)法解決的?？杀氖情_發(fā)人員把這些問題當(dāng)成了借口，不愿主動攻克問題，導(dǎo)致需求問題擴散到整個軟件開發(fā)過程，產(chǎn)生太多的后患。軟件企業(yè)的領(lǐng)導(dǎo)應(yīng)當(dāng)給具有錯誤觀念的開發(fā)人員們洗腦：需求分析員的天職就是在有限的時間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶需求，如果做不到就是失職，不要找借口。 合作關(guān)系如果需求分析員不能與用戶建立良好的合作關(guān)系，那么他們在需求開發(fā)過程中會很疲憊。倘若用戶不能很好地配合需求分析員，那并不表示他是個壞蛋。因為用戶有他自己的想法：我回答了你們的問題，講了該講 的。我 們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧 ……。對于一些競標(biāo)項目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會買你的產(chǎn)品，他不會投入很多精力來協(xié)助你搞需求開發(fā)。我是個軟件開發(fā)人員，有時我又成為別的軟件公司的用戶，需求開發(fā)過程中的兩類角色我都經(jīng)歷過，很有感受。舉一例談?wù)?。公司曾有一個關(guān)于企業(yè)管理的項目要外包，項目金額不小，有數(shù)家軟件公司來競標(biāo)。他們在做方案時，我是被訪問的主要“用戶”之一。我雖然是個用戶，但真的不清楚這個項目的需求，說不出長篇大論，只能人家問什么我回答什么。由于我有重要的研發(fā)、管理工作要做（每個人都會覺得自己的工作很重要） ，不愿意老被別人的訪問打擾，有時想回避。然而將心比心（或者說同病相憐吧） ，我也是開發(fā)人員，知道吃這碗飯不容易，我理應(yīng)幫他們一把。第 4 章 需求開發(fā)與需求管理Page 11 of 34我想了一個辦法：請我的幾位小組成員輪流代我參加需求調(diào)查會議。我提醒組員：“我們要熱情地為調(diào)查者解答疑問，同時要觀察、體會他們的調(diào)查方法，學(xué)習(xí)好的、屏棄差的。因為我們以后也要向別人調(diào)查需求。 ”需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡(luò)住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識，還要具備較強的交流、溝通能力，否則會把事情搞砸的。在上例中，有些調(diào)查人員和我談方案時，結(jié)果我發(fā)現(xiàn)他們的水平還不及我們小組的高，真不知道是誰給誰做方案。把他們一送出大門，我就打了“小報告” ，他們的機會變得很渺茫。有些調(diào)查人員為了討好我，不停地說好話、套近乎。說好話當(dāng)然讓我高興，但是聽多了，讓我感覺此人很圓滑，反而印象不好，于是應(yīng)付了事。有些調(diào)查人員倒是很務(wù)實，一上來就問問題、填寫調(diào)查報告，一點好話都不會說，讓我提不起興趣，我也不想多談。有些感受挺有趣，每當(dāng)我認(rèn)真思考這些事情時，不禁心事重重。有太多的開發(fā)人員不懂得“如何做好”需求開發(fā)，這并不有趣，組建優(yōu)秀的開發(fā)團(tuán)隊談何容易?。￠_發(fā)方與用戶的合作關(guān)系對需求開發(fā)而言是至關(guān)重要的。對于重大的、復(fù)雜的項目，我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關(guān)系，這樣風(fēng)險太大。文獻(xiàn) [Wiegers2022, p12p16] 給出了一種好方法：開發(fā)方和用戶方在開展需求開發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權(quán)利與義務(wù)” ，即以協(xié)議的方式確定合作關(guān)系。 “好話”和“丑話”都說在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn)，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。表 41 列舉了用戶在需求工程中的“權(quán)利與義務(wù)” ，讀者可以根據(jù)實際情況適當(dāng)?shù)匦薷?。用戶的?quán)利1. 有權(quán)要求開發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員。2. 有權(quán)要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。3. 有權(quán)審查需求文檔，并對有爭議的需求作出決策。如果認(rèn)為需求文檔不能準(zhǔn)確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。4. 如果用戶想要變更需求，有權(quán)要求開發(fā)方對該變更將產(chǎn)生的影響作出真實可信的評估，以便用戶決定是否變更需求。用戶的義務(wù)1. 以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。2. 樂意接受需求分析員的采訪，在不泄漏機密的前提下，盡可能地回答需求分析員的問題。3. 在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關(guān)的材料。4. 與需求分析員共同評審需求文檔，確保需求文檔準(zhǔn)確地反映用戶真實的意愿。5. 不輕易變更需求。如果需要變更需求的話，按照“需求變更控制規(guī)程”執(zhí)行，而非強迫開發(fā)方接受。表 41 用戶在需求工程中的“權(quán)利與義務(wù) ”第 4 章 需求開發(fā)與需求管理Page 12 of 34 用戶說不清楚需求用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)人員頭痛的大問題。有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當(dāng)然說不清楚需求。開發(fā)人員可能覺得奇怪：用戶自己都不知道要什么，為什么還要我們開發(fā)軟件？這種現(xiàn)象有些時候是正常的，例如開發(fā)方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導(dǎo)用戶“消費” 。也有不正常的現(xiàn)象，例如前些年全國各地的很多政府機構(gòu)大搞網(wǎng)絡(luò)建設(shè)。這些機構(gòu)的領(lǐng)導(dǎo)和辦公人員大多數(shù)不清楚網(wǎng)絡(luò)干什么用，就讓開發(fā)人員替他們設(shè)想需求吧，反正是花公家的錢。有些用戶雖然心里明白想要什么，但卻說不清楚需求。讀者可能很不以為然，用戶不致于笨到這個地步吧？這不是聰明或笨的問題，是表達(dá)能力問題。舉個日常生活的事例，比如說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試，試穿時感覺到舒服才會買鞋（居然也有神通廣大的售貨員，看一眼用戶的手，就知道應(yīng)該穿什么樣的鞋） 。真所謂“道可道，非常道。明可明，非常明。 ”需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，否則會連累整個開發(fā)團(tuán)隊的。無論是什么原因?qū)е掠脩粽f不清楚需求，需求分析員必須設(shè)法搞清楚用戶真正的需求，這是需求分析員的職責(zé)，也是職業(yè)的挑戰(zhàn)。 雙方誤解需求人們在交流的時候，經(jīng)常會發(fā)生“問非所求，答非所問”的事情。有時用戶會把開發(fā)人員的建議或答復(fù)給想歪了：有一個軟件開發(fā)人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處，用戶聽得津津有味。最后，心動 的用戶對軟件開發(fā)人員說：“ 好得很，就讓我們馬上行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。 ”而用戶表達(dá)的需求，不同的開發(fā)人員可能有不同的理解。如果需求分析員誤解了需求，那會導(dǎo)致后續(xù)的不少開發(fā)人員將錯就錯、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯誤連高智商的外星人都不能避免：有個外星人間諜潛伏到地球刺探情報，它 給上司寫了一份 報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進(jìn)。嗓門極大，在夜里雙眼能射出強光。……有趣的是，車?yán)镒≈环N叫作‘ 人 ’的寄生蟲， 這些寄生蟲完全控制了 車。 ”不論是復(fù)雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認(rèn)工作（屬于需求管理）必不可少。 開發(fā)人員寫不好需求文檔開發(fā)人員寫不好需求文檔的主要原因如下：第 4 章 需求開發(fā)與需求管理Page 13 of 34? 需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。古時候，一書生在考試前補習(xí)“寫文章” ，成天愁眉苦臉。其夫人甚為不解，問：“相公，你寫文章比我生小孩還難嗎？”書生長嘆一聲：“娘子你哪里知道我的難處??！你生小孩時肚子里有東西，可我寫文章時肚子里沒東西啊