需求開發與需求管理精品資料網（）專業提供企管培訓資料目錄1.什么是需求2.了解客戶、最終用戶、間接用戶3.需求工程基本概念4.需求開發的主要困難與對策5.如何開展需求調查6.如何進行需求分析7.什么是好的需求規格說明書8.如何定義產品需求9.需求管理：確認、跟蹤、變更控制人們并不清楚應該做什么，卻一直忙碌不停地開發。1.什么是需求1.1需求的基本概念

寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。所以如果只有一些零碎的對話、資料或郵件，你就以為自己已經掌握了需求，那是自欺欺人。1.2需求的重要性FrederickBrooks在他1987年經典文章“NoSilverBullet”中闡述了需求的重要性：開發軟件系統最困難的部分就是準確說明開發什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統的接口。此工作一旦做錯，將會給系統帶來極大的損害，并且以后對它修改也極為困難。

需求是產品的根源，需求工作的優劣對產品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。

國內軟件業的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發。

1.什么是需求1.3需求開發失敗的案例

上海貝爾某事業部一群高智商的開發人員集體犯需求觀念錯誤的案例。故事是這樣的…需求問題有時如同愛情問題，真是“當局者迷，旁觀者清”啊。

2.了解客戶、最終用戶、間接用戶2.1基本概念“用戶”（user）是一種泛稱，它可細分為“客戶”（customer）、“最終用戶”（theenduser）和“間接用戶”（或稱為關系人）。掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶。客戶與最終用戶可能是同一個人也可能不是同一個人。2.2客戶是掏錢買軟件的人，所以他是“上帝”

某飯店經理在解釋“先有雞還是先有蛋”這個哲學問題時，精辟地闡述了客戶的地位：如果顧客先點雞，那么就先有雞；如果顧客先點蛋，那么就先有蛋。“現代營銷學之父”菲利普?科特勒所著的《市場營銷導論》是這樣描述客戶的：客戶永遠是本公司的座上客。客戶并不依賴我們，而我們卻依賴客戶。客戶不是我們工作的障礙，而是我們工作的目標。我們并不因為服務于他而對他有恩，他卻因為給予我們服務于他的機會而有恩于我們。客戶不是我們要與之爭辯和斗智的人。從未有人曾在與客戶的爭辯中獲勝。客戶是把他的欲望帶給我們的人，因此我們的工作就是滿足這些欲望，從而使客戶和我們共同獲益。與客戶打交道的主要目的是：一是獲取需求，二是簽合同。不要把錢仍到水里。精品資料網（）專業提供企管培訓資料2.了解客戶、最終用戶、間接用戶2.3即使最終用戶不是上帝，也算是“上帝”的“親戚”，同樣怠慢不得。如果項目規模比較大，那么開發方與最終用戶的來往就比較多。如從最終用戶那里獲取詳細的需求，請最終用戶試驗軟件，對最終用戶進行培訓等等。公司新員工上產品培訓課，有位小領導匆匆趕來作指示：“隔壁班正在給電信局的員工們進行培訓，他們都是上帝派來的，大家要注意形象。由于休息室空間有限，請大家自覺讓位。午休時他們可以躺著睡，我們只能坐在位置上打個盹兒…….。”

2.4重視“間接用戶”，千萬別“大意失荊州”

間接用戶既不掏錢買該軟件產品，也不使用該軟件，但是它可能對軟件產品有很大的影響。例如，財務軟件開發商在把“財務軟件”賣給客戶之前，這個“財務軟件”必須得到國家財政部的批準。否則即使該軟件的功能是完美的，但卻被政府認為是非法的。所以國家財政部就是所有財務軟件的間接用戶，它不僅不付錢給財務軟件開發商，反而要收取鑒定費、手續費等。同理，市面上流通的信息安全軟件、殺病毒軟件必須得到國家公安部的批準，否則軟件開發商被逮住后戴上“非法經營”的帽子就慘了。

3.需求工程基本概念3.1什么是需求工程把所有與需求直接相關的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬于需求開發，另一類屬于需求管理。需求工程的結構圖

3.需求工程基本概念3.2需求開發過程域

需求開發的目的是通過調查與分析，獲取用戶需求并定義產品需求。

需求調查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產生《用戶需求說明書》。

需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。

需求定義的目的是根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《產品需求規格說明書》。系統設計人員將依據《產品需求規格說明書》開展系統設計工作。3.3需求管理過程域

需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求確認是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。

需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產品依據需求文檔進行開發。需求變更控制是指依據“變更申請－審批－更改－重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂。

3.需求工程基本概念3.4需求工程的一些感悟不論是合同項目還是自主研發的產品，都必須開展需求開發和需求管理活動。

開發者對待需求工程的態度可分“被動型”、“主動型”和“領先型”三種，只有后兩種才有可能開發出成功的產品。“被動型”是指開發者被動地對待需求工程中的各項活動，能少干則少干，能偷懶則偷懶。他們認為需求是用戶的事情而不是自己的事情。開發過程中經常發生需求變更，導致產品迷失方向，不是半途而廢就是陷入半死不活的狀態。“主動型”是指開發者積極地開展需求工程中的各項活動。他們把獲取準確的需求當作自己的職責，會想盡一切辦法克服需求開發和需求管理過程中的困難，而不是找借口推卸責任。俗話說“良好的開端是成功的一半”，“主動型”需求工程是開發成功產品的必備條件。“領先型”是需求工程的最高境界。開發者發掘了連用戶自己都沒有意識到的需求，導致用戶跟著新產品跑而不是新產品圍著用戶轉，這叫引導消費。需求工程做到這個份上，才能使產品立于不敗之地，長盛不衰。4.需求開發的主要困難與對策4.1知識技能問題

應用域的知識是無邊無際的，任何人都不可能是“萬事通”。俗話說“隔行如隔山”，需求分析員可能是某一領域的專家，但當他接手陌生的業務時，他可能是個“無知”者。一個企業要謀求發展，不能總在做老的業務。人一生中會有許多充滿挫折的“第一次”，不可以逃避。當需求分析員缺乏應用域知識時，他該怎么辦？首先他要有勇氣做事，否則連實踐的機會都沒有。其次他應當趕緊補習應用域知識，不論是通過自學還是培訓的方式，否則他很難與用戶交流。如果可能的話，開發方最好請既懂軟件又懂應用域知識的行家來幫忙。4.2態度問題

相當多的開發人員習慣于被動地對待需求開發。每當遇到麻煩、挫折時，他們會發牢騷，找出一堆用戶的毛病。很多開發人員錯誤地以為：需求是用戶的事情，不是我們的事情。我們為用戶開發軟件，難道用戶不該告訴我們應當開發什么嗎？如果用戶說不清楚需求，或者經常變更需求，這類問題是用戶產生的，應當由他們自己負責。

用戶說不清楚需求或者需求發生變更，這些都是常見的問題，并不是絕癥，是人們可以設法解決的。可悲的是開發人員把這些問題當成了借口，不愿主動攻克問題，導致需求問題擴散到整個軟件開發過程，產生太多的后患。軟件企業的領導應當給具有錯誤觀念的開發人員們洗腦：需求分析員的天職就是在有限的時間內獲取準確而細致的用戶需求，如果做不到就是失職，不要找借口。

精品資料網（）專業提供企管培訓資料4.需求開發的主要困難與對策4.3合作關系如果需求分析員不能與用戶建立良好的合作關系，那么他們在需求開發過程中會很疲憊。倘若用戶不能很好地配合需求分析員，那并不表示他是個壞蛋。因為用戶有他自己的想法：我回答了你們的問題，講了該講的。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧

……。

對于一些競標項目，在合同未簽訂之前的需求開發工作尤為困難。用戶未必會買你的產品，他不會投入很多精力來協助你搞需求開發。需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡住用戶就能成功。出色的需求分析員不僅要有過硬的專業知識，還要具備較強的交流、溝通能力。開發方與用戶的合作關系對需求開發而言是至關重要的。對于重大的、復雜的項目，我們不能完全期望雙方能夠自發地建立起良好地合作關系，這樣風險太大。開發方和用戶方在開展需求開發之前，雙方協商并撰寫“用戶在需求工程中的權利與義務”，即以協議的方式確定合作關系。“好話”和“丑話”都說在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發方最好為用戶舉辦關于需求工程的培訓，這樣的培訓將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。4.需求開發的主要困難與對策用戶在需求工程中的“權利”

1.有權要求開發方派遣資質合格的需求分析員和相關人員。2.有權要求開發方采用用戶熟悉的語言來描述需求，即開發方必須提供用戶看得懂得需求文檔。3.有權審查需求文檔，并對有爭議的需求作出決策。如果認為需求文檔不能準確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。4.如果用戶想要變更需求，有權要求開發方對該變更將產生的影響作出真實可信的評估，以便用戶決定是否變更需求。用戶在需求工程中的“義務”

1.以積極友善的態度與開發方人員交流、協作，盡可能地為開發方人員提供工作和生活上的便利。2.樂意接受需求分析員的采訪，在不泄漏機密的前提下盡可能地回答需求分析員的問題。3.在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關的材料。4.與需求分析員共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿。4.需求開發的主要困難與對策4.4用戶說不清楚需求用戶說不清楚需求是普遍現象，這是讓開發人員頭痛的大問題。有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當然說不清楚需求。例如開發方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導用戶“消費”。例如前些年全國各地的很多政府機構大搞網絡建設。這些機構的領導和辦公人員大多數不清楚網絡干什么用，就讓開發人員替他們設想需求吧，反正是花公家的錢。有些用戶雖然心里明白想要什么，但卻說不清楚需求。

比如說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試，試穿時感覺到舒服才會買鞋。需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發工作，否則會連累整個開發團隊的。無論是什么原因導致用戶說不清楚需求，需求分析員必須設法搞清楚用戶真正的需求，這是需求分析員的職責，也是職業的挑戰。

4.需求開發的主要困難與對策4.5雙方誤解需求人們在交流的時候，經常會發生“問非所求，答非所問”的事情。有時用戶會把開發人員的建議或答復給想歪了：有一個軟件開發人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處，用戶聽得津津有味。最后，心動的用戶對軟件開發人員說：“好得很，就讓我們馬上行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。”而用戶表達的需求，不同的開發人員可能有不同的理解。如果需求分析員誤解了需求，那會導致后續的不少開發人員將錯就錯、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯誤連高智商的外星人都不能避免：有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜里雙眼能射出強光。……有趣的是，車里住著一種叫作‘人’的寄生蟲，這些寄生蟲完全控制了車。”不論是復雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認工作（屬于需求管理）必不可少。

精品資料網（）專業提供企管培訓資料4.需求開發的主要困難與對策4.6開發人員寫不好需求文檔需求調查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。古時候，一書生在考試前補習“寫文章”，成天愁眉苦臉。其夫人甚為不解，問：“相公，你寫文章比我生小孩還難嗎？”書生長嘆一聲：“娘子你哪里知道我的難處啊！你生小孩時肚子里有東西，可我寫文章時肚子里沒東西啊。”所以要想寫出好的需求文檔，前提條件是把需求調查工作做好。

開發人員寫作能力比較差，雖然在調查過程中已經獲得了不少需求信息，卻寫不出好的需求文檔來。可以毫不夸張地說，國內90％以上的軟件開發人員，他們的寫作能力遠不及開發能力。提高開發人員寫作能力的根本辦法就是讓他們多練習寫文檔，熟能生巧。另外，企業應當提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度。

4.需求開發的主要困難與對策4.7用戶經常變更需求需求變更通常會對項目的進度、人力資源、經費產生很大的影響，這是開發商非常畏懼的問題。如果在項目開發的初始階段，開發人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發后期才將需求糾正過來，導致產品的部分內容需要重新開發。毫無疑問，這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的，雙方應當好好反省，認真學習需求開發和管理的方法，避免再犯相似的錯誤。如果由于市場變化而導致產品需求發生變更，開發商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那么開發商吃了“上一頓”就沒有“下一頓”。正因為市場在變化，才會產生更多商機，聰明的開發商才會有活干，有錢賺。

其實需求變更并不可怕，可怕的是需求變更失去控制，導致項目混亂。所以需求變更控制是需求工程的重要活動。

5.如何開展需求調查5.1準備調查

首先，需求分析員應當起草需求調查問題表，將調查重點鎖定在該問題表內，否則調查工作將變得漫無邊際。問題表可以有多份，隨著調查的深入，問題表將不斷地被細化。根據經驗，用戶通常沒有耐心回答復雜的論述題，所以問題表應當以“選擇題”和“是非題”為主。制定問題表最簡便的方法就是從《用戶需求說明書》的模板中提取需求問題。

其次，需求分析員應當確定需求調查的方式，例如：與用戶交談，向用戶提問題。向用戶群體發調查問卷。參觀用戶的工作流程，觀察用戶的操作。與同行、專家交談，聽取他們的意見。分析已經存在的同類軟件產品，提取需求。從行業標準、規則中提取需求。從Internet上搜查相關資料。最后，需求分析員與被調查者建立聯系，確定調查的時間、地點、人員等，撰寫需求調查計劃。要特別留意的是不要漏掉典型的用戶。

5.如何開展需求調查5.2執行調查準備工作完畢后，需求分析員按照計劃執行調查。在調查過程中隨時記錄（或存儲）需求信息。需求分析員與用戶面談時應當注意以下事項：如果與用戶約好了時間，切勿遲到或早退。要注意禮節，盡可能獲得用戶的好感，并為下次打擾他們埋下伏筆。需求分析員應事先了解用戶的身份、背景，以便隨機應變。IT人士不可貌相，有些大企業的領導其外表很土氣，象農民。如果你路上碰到他，以為是個勤雜工，說：“喂，老師傅，來幫我拎東西。”也許這筆生意就泡湯了。需求調查不象偵探推理那樣從蛛絲馬跡著手，應該先了解宏觀問題，再了解細節問題。如果雙方氣氛融洽，可以采用靈活的訪談形式，輕易不要打斷用戶的談話。當雙方對某些問題的交流合乎邏輯地結束后，即可繼續討論問題表中的其它問題。盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調查的力度。避免片面地聽取某些用戶的需求而忽視其它用戶的需求。精品資料網（）專業提供企管培訓資料5.如何開展需求調查5.3《用戶需求說明書》與《產品需求規格說明書》的主要區別與聯系前者主要采用自然語言（和應用域術語）來表達用戶需求，其內容相對于后者而言比較粗略，不夠詳細。后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，產品需求是軟件系統設計的直接依據。兩者之間可能并不存在一一影射關系，因為軟件開發商會根據產品發展戰略、企業當前狀況適當地調整產品需求，例如用戶需求可能被分配到軟件的數個版本中。軟件開發人員應當依據《產品需求規格說明書》來開發當前產品。5.4撰寫《用戶需求說明書》用戶需求說明書的參考模板6.如何進行需求分析6.1基本概念

為了得到用戶的金錢，企業不得不鼓吹：用戶就是上帝，用戶永遠是正確的。誰都知道這不是真的。事實上，很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現的需求。需求分析是指在需求開發過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。

需求分析是需求開發過程中最費腦子的工作。分析方法大體有兩類：“問答分析法”和“建模分析法”。后者技術性比較強，寫出來有學術味，故大多數軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用（保你一學就會），很有實用價值。“問答分析法”比較適合于用戶需求調查階段“建模分析法”比較適合于產品需求定義階段。

6.如何進行需求分析6.2問答分析方法問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”。問答分析最重要的問題是：“是什么”和“為什么”。每個需求都應當用陳述句說明“是什么”，如果“是什么”的內涵不夠清晰，則應補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當然”的，那么應當解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。

其它常見的問題有：

需求存在二義性嗎？

需求文檔的上下文有矛盾嗎？

需求完備嗎？

需求是必要的嗎？

需求可實現嗎？

需求可驗證嗎？

需求的優先級確定了嗎？

精品資料網（）專業提供企管培訓資料6.如何進行需求分析6.3建模分析法人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然，所謂“一圖低千言”就是這個道理。在需求開發過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結構化分析法”和“面向對象分析法”。

恰當地使用圖形符號：現代建模工具如Rose有非常豐富的圖形符號和文字標注，能很好地表達模型的細節。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復雜化，將使開發人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。

6.如何進行需求分析6.4作出決策當需求從四面八方收集來后，需求的沖突在所難免。對于那些難以達成共識的需求而言，經常會發生“公說公有理，婆說婆有理”的現象。那么需求分析員究竟應該聽誰的呢？如果一群人對需求有爭議，并不是誰聲音最響就聽誰的。根據生活經驗，最保險的辦法是：先聽官兒大的或者威望高的，如果大家的職位和威望都差不多，那么采用“少數服從大多數”的原則。如果一個產品可以賣給幾類客戶，但是各類客戶都要求產品按照他們的喜好來開發。此時對需求的決策應當以商業利益為導向，即哪一類客戶出錢最多就先滿足他們的需求，以后再做那些獲利相對較少的需求。當開發者想象中的產品與客戶所提的需求有沖突時，一般應當尊重客戶的觀點。但是不要陷入“客戶總是對的”陷阱里，需求分析員應當糾正明顯不合理的客戶需求。如果產品很復雜，雙方都不太明白需求，此時最好請開發人員快速構造軟件的原型，雙方看著軟件原型再分析需求。7.什么是好的需求規格說明書7.1正確

需求規格說明書應當正確地反映用戶的真實意圖，“正確”是《產品需求規格說明書》最重要的屬性。如果“不正確”僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發方和用戶必須對《需求規格說明書》進行確認。7.2清楚

清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚：文檔的結構、段落是否亂七八糟？上下文是否不連貫？文檔的語句是否含糊其詞、羅里羅嗦？看了半天是否還不明白需求究竟是什么？7.3無二義性

“無二義性”是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導致人們誤解需求而開發出偏離需求的產品。為了使需求無二義性，人們在寫《產品需求規格說明書》時措詞應當準確，切勿模棱兩可。7.什么是好的需求規格說明書7.4一致

“一致”（Consistent）是指《產品需求規格說明書》中各個需求之間不會發生矛盾。矛盾常常潛伏在需求文檔的上下文中。7.5必要

《產品需求規格說明書》中的各項需求對用戶而言應當都是必要的。可以把“必要”比喻為“雪中送炭”。“必要”往前一步，要么是“畫蛇添足”要么是“錦上添花”。“畫蛇添足”顯然是壞事，會導致開發人員多干一些吃力不討好的工作。所以要盡量剔除需求規格說明書中“畫蛇添足”的那些需求。“錦上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發者應當集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在《產品需求規格說明書》中將那些“錦上添花”的需求設置為較低的優先級。7.6完備“完備”（Complete）是指《產品需求規格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關注系統的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產品需求規格說明書》將導致產生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。7.什么是好的需求規格說明書7.7可實現

《產品需求規格說明書》中的各項需求對開發方而言應當都是可實現的（Attainable）。“可實現”意味著在技術上是可行的，并且滿足時間、費用、質量等約束。營銷人員和用戶談生意時，為了能拿到“單子”，他們往往對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《產品需求規格說明書》可是白紙黑字啊。經過雙方確認的《產品需求規格說明書》相當于商業合同，如果開發方不能夠實現《產品需求規格說明書》中的內容，那就是違約，可能會被罰款的。對于合同項目，如果開發方不能確信某些需求是否可實現，則應事先與用戶協商，達成一致的處理意見，避免將來發生商業糾紛。7.8可驗證

《產品需求規格說明書》中的各項需求對用戶方而言應當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發生商業糾紛。例如，摩天大樓的一項需求是“抗十二級臺風”，這個需求看起來堂而皇之，但是如何驗證呢？當摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風來試驗？如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試，那么這項需求就是“可驗證”的。精品資料網（）專業提供企管培訓資料7.什么是好的需求規格說明書7.9確定優先級為什么要確定需求的“優先級”？理論上講，軟件的所有需求都應當被實現。但是在現實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。人們想出了“取舍”辦法：先做優先級高的需求，后做（甚至放棄）優先級低的需求，這樣可以將風險降到最低。需求的優先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發方共同確定需求的優先級。7.10闡述“做什么”而不是“怎么做”

《產品需求規格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”。“怎么做”是系統設計和實現階段的事情。國內的很多軟件公司里，開發人員常常身兼數職，可能把需求開發、系統設計、編程等工作從頭做到尾。所以他們在調查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調查、定義需求時想好了“怎么做”，當然應該寫下來，否則豈不浪費！關鍵是不要將“怎么做”寫到需求規格說明書里面，記錄在其它文檔里就行了。8.如何定義產品需求8.1規程第一步：細化并分析用戶需求

需求分析員首先對《用戶需求說明書》進行細化，對比較復雜的用戶需求進行建模分析，以幫助軟件開發人員更好地理解需求。例如采用Rational的Rose工具進行需求的建模分析，建模分析產生的文檔可以作為《產品需求規格說明書》的附件。補充說明：建模分析的技術難度比較高，需求分析員應當根據自身水平進行取舍。第二步：撰寫產品需求規格說明書

需求分析員按照指定的文檔模板撰寫《產品需求規格說明書》。如果待開發的產品分為軟件和硬件兩部分的話，則應當撰寫《軟件需求規格說明書》和《硬件需求規格說明書》。第三步：進行需求確認項目經理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《產品需求規格說明書》，盡最大努力使《產品需求規格說明書》能夠正確無誤地反映用戶的真實意愿。需求評審之后，開發方和客戶方的責任人對《產品需求規格說明書》作書面承諾。8.2軟件需求規格說明書的參考模板軟件需求說明書的參考模板9.需求管理：確認、跟蹤、變更控制9.1需求確認（評審和承諾）需求確認是指開發方和客戶方共同對《產品需求規格說明書》進行評審，雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。

9.2需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到后頭越馬虎。需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務纏身）。沒有必要把所有事情擠在一塊做，需求開發是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。開評審會議時經常會“跑題”，導致評審效率很低。有時話匣子一打開后關不上，大家越扯越遠，結果評審會議變成了聊天會議。主持人應當控制話題，避免大家討論與主題無關的東西。

開評審會議時經常會發生爭議。適當的爭議有利于澄清問題，比什么東西都一致贊成要好。然而當爭議變為爭吵時就壞事了，爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執己見”。毫不妥協或者輕易妥協都不是好辦法。我們應當養成良好的習慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。

9.需求管理：確認、跟蹤、變更控制9.3需求承諾需求承諾是指開發方和客戶方的責任人對通過了正式技術評審的《產品需求規格說明書》作出承諾，該承諾具有商業合同的效果。需求承諾的“八股文”如下：本《產品需求規格說明書》建立在雙方對需求的共同理解基礎之上，我同意后續的開發工作根據該《產品需求規格說明書》開展。如果需求發生變化，我們將按照“變更控制規程”執行。我明白需求的變更將導致雙方重新協商成本、資源和進度等。甲方簽字

乙方簽字人們在作出承諾之前務必要認真閱讀文檔，一定要明白簽字意味著什么。

精品資料網（）專業提供企管培訓資料9.需求管理：確認、跟蹤、變更控制9.4需求跟蹤需求跟蹤的目的是建立與維護“需求－設計－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。

需求跟蹤有兩種方式：

正向跟蹤。檢查《產品需求規格說明書》中的每個需求是否都能在后繼工作成果中找到對應點。

逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在《產品需求規格說明書》中找到出處。

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對應關系。

9.需求管理：確認、跟蹤、變更控制9.5需求變更控制

需求發生變更的起因主要有：隨著項目的進展，人們（包括開發方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。市場發生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。提出需求變更的動機是好的，目的是希望產品更加符合用戶的需求。對項目開發小組而言，變更需求意味著要調整資源、重新分配任務、修改前期工作成果等，開發小組要為此付出較重的代價。如果每次需求變更請求都被采納的話，這個項目也許永遠不能按時完成。需求變更控制的目的：如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。如果需求變更帶來的壞處大于好處，那么拒絕變更。需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發方是不敢得罪客戶的，但是無原則地退讓將使開發小組陷入困境。解決這個問題最好的辦法是事先建立“游戲規則”：開發方與客戶方達成“事不過三”的約定（符合中國人的習慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開發方有權拒絕，除非客戶愿意補償開發方的損失。如果事先沒有“游戲規則”的話，開發方需要一些社交技巧來減緩矛盾。例如建議在開發該產品新版本時修改需求。精品資料網（）專業提供企管培訓資料百萬客戶大拜訪35一、課程目的

1、持續推動主顧300（讓業務員有機會做）

2、每天完成7+3拜訪（讓業務員愿意做）

3、熟練掌握拜訪技巧（讓業務員會做）二、過程：三、內容1、理念篇--知道和不知道？2、拜訪篇--心動不如行動3、話術篇--完美的拜訪是設計出來的36

理念篇知道和不知道？37猜中彩38人類最大的恐懼來自于未知世界的無知不知道是一種危機，一種威脅，一種恐懼。理念之一：

39不知道的兩種表現形式？？40（1）你曾拜訪過的客戶中，是否有各種不同的客戶性格類型？（2）你是否經常變換不同的推銷策略？（3）你的推銷模式的成交率是多少？（4）失敗的原因是客戶？你？還是推銷方式？你知道還是不知道？業務員的不知道41愛人同志42理念之二：

不知道是客觀存在的，是認識事物的開始43

生活中對待不知道的幾種態度：（1）不知道等于不存在；（沒市場，沒客戶）（2）不知道等于無所謂；（沒問題，沒關系，沒辦法）（3）不知道等于想知道，好奇并積極的探索！44理念之三：

人的進步就在于不斷的減少不知道業務員的進步就在于將自己和對客戶的不知道變成知道45

理念之四：

傭金的兌現來自于拜訪46理念之五心動不如行動47結論：除非你去做拜訪，否則永遠你都處在不知道的狀態當中煩惱、恐懼和壓力皆因此而生。48

拜訪篇心動不如行動49丑媳婦怕見公婆一、沒信心（1）對自己沒信心信心是拜訪出來的恐