需求管理和需求分析課件

1、需求管理和需求分析,1,學習交流PPT,需求管理和需求分析,2,學習交流PPT,內(nèi)容,前言 需求工程簡介 需求開發(fā)的主要困難與對策 如何開展需求調(diào)查 如何進行需求分析 什么是好的需求規(guī)格說明書 形成需求規(guī)格說明書 需求管理：確認、跟蹤、變更控制 CMM2級KPA需求管理（RM）介紹,3,學習交流PPT,前言,泛泛地講，需求來源于客戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產(chǎn)品“必須或應當”做什么。 所以如果只有一些零碎的對話、資料或郵件，并沒有真正掌握需求 Frederick Brooks在他1987年經(jīng)典文章“No Silver Bullet”中闡述了需求

2、的重要性：開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。 需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。,4,學習交流PPT,前言, 定義（IEEE-STD-610） 用戶為解決某個問題、或為實現(xiàn)某一目標， 要求軟件必須滿足的條件或能力。 軟件需求的三個層次 業(yè)務需求 用戶需求 功能需求和非功能需求,5,學習交流PPT,前言,6,學習交流PPT,前言,7,學習交流PPT,前言,8,

3、學習交流PPT,前言,“用戶”（user）是一種泛稱，它可細分為“客戶”（customer）、“最終用戶”（the end user）和“間接用戶”（或稱為關系人）。掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶?？蛻襞c最終用戶可能是同一個人也可能不是同一個人。 客戶是掏錢買軟件的人，所以他是“上帝” 。某飯店經(jīng)理在解釋“先有雞還是先有蛋”這個哲學問題時，精辟地闡述了客戶的地位：如果顧客先點雞，那么就先有雞；如果顧客先點蛋，那么就先有蛋。 客戶的需要才是最準確需求之源,9,學習交流PPT,需求工程簡介,把所有與需求直接相關的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬于需

4、求開發(fā)，另一類屬于需求管理。 需求工程的結(jié)構(gòu)圖,10,學習交流PPT,需求工程簡介,11,學習交流PPT,需求工程簡介,需求開發(fā)過程 需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。 需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生用戶需求說明書。 需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生產(chǎn)品需求規(guī)格說明書。系統(tǒng)設計人員將依據(jù)產(chǎn)品需求規(guī)格說明書開展系統(tǒng)設計工作。,12,學習交流PPT,需求工程簡介,需求管理過

5、程 需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。 需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 需求變更控制是指依據(jù)“變更申請審批更改重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發(fā)生混亂。,13,學習交流PPT,需求工程簡介,不論是合同項目還是自主研發(fā)的產(chǎn)品，都必須開展需求開發(fā)和需求管理活動。開發(fā)者對待需求工程的態(tài)度可分“被動型”、“

6、主動型”和“領先型”三種。 “被動型”是指開發(fā)者被動地對待需求工程中的各項活動。他們認為需求是用戶的事情。開發(fā)過程中經(jīng)常發(fā)生需求變更，導致產(chǎn)品迷失方向，不是半途而廢就是陷入半死不活的狀態(tài)。 “主動型”是指開發(fā)者積極地開展需求工程中的各項活動。他們把獲取準確的需求當作自己的職責，會想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責任。俗話說“良好的開端是成功的一半”。 “領先型”是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識到的需求，導致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導消費。需求工程做到這個份上，才能使產(chǎn)品立于不敗之地，長盛不衰。,14,學習交流PPT,需

7、求工程簡介,需求工程很重要羅,15,學習交流PPT,需求開發(fā)的主要困難與對策,1 知識技能問題 應用域的知識是無邊無際的，任何人都不可能是“萬事通”。俗話說“隔行如隔山”，需求分析員可能是某一領域的專家，但當他接手陌生的業(yè)務時，他可能是個“無知”者。一個企業(yè)要謀求發(fā)展，不能總在做老的業(yè)務。人一生中會有許多充滿挫折的“第一次”，不可以逃避。 我們?nèi)狈糜蛑R，該怎么辦？ 首先要有勇氣做事，否則連實踐的機會都沒有。 其次他應當趕緊補習應用域知識，不論是通過自學還是培訓的方式，否則他很難與用戶交流。如果可能的話，最好請既懂軟件又懂應用域知識的行家來幫忙。 2 態(tài)度問題 我們習慣于被動地對待需求開發(fā)

8、。每當遇到麻煩、挫折時，我們會發(fā)牢騷并錯誤地以為： 需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應當開發(fā)什么嗎？如果用戶說不清楚需求，或者經(jīng)常變更需求，這類問題是用戶產(chǎn)生的，應當由他們自己負責。 用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設法解決的。我們要主動攻克問題，導致需求問題擴散到整個軟件開發(fā)過程，產(chǎn)生太多的后患。 項目負責人應當給具有錯誤觀念的開發(fā)人員們洗腦：需求分析員的天職就是在有限的時間內(nèi)獲取準確而細致的用戶需求 。,16,學習交流PPT,需求開發(fā)的主要困難與對策,.3 合作關系 如果我們不能與用戶建立良好的合作關系，

9、那么我們在需求開發(fā)過程中會很疲憊。 倘若用戶不能很好地配合需求分析員，那并不表示他是個壞蛋。因為用戶有他自己的想法： 我回答了你們的問題，講了該講的。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧。 需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識，還要具備較強的交流、溝通能力，我們可以通過幫助用戶解決一些技術(shù)上的小問題和用戶拿攏關系。 對于一些競標項目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會買你的產(chǎn)品，他不會投入很多精力來協(xié)助你搞需求開發(fā)，我們積極主動找用戶了解

10、業(yè)務和需求。 開發(fā)方與用戶的合作關系對需求開發(fā)而言是至關重要的。對于重大的、復雜的項目，我們不能完全期望客戶能自發(fā)地和我們建立起良好地合作關系，這樣風險太大。 在開展需求開發(fā)之前，我們要“好話”和“丑話”都說在前頭，這樣能減少今后的摩擦?？赡茉?，以書面形式明確雙方的在需求工程方面的權(quán)利和義務。 當然，在進行需求調(diào)查時，我們應該有個具體的計劃供客戶確認。,17,學習交流PPT,需求開發(fā)的主要困難與對策,用戶在需求工程中的“權(quán)利” 有權(quán)要求開發(fā)方派遣資質(zhì)合格的需求分析員和相關人員。 有權(quán)要求開發(fā)方采用他們熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。 有權(quán)審查需求文檔，并對有爭議的需

11、求作出決策。如果認為需求文檔不能準確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。 如果用戶想要變更需求，有權(quán)要求開發(fā)方對該變更將產(chǎn)生的影響作出真實可信的評估，以便用戶決定是否變更需求。 用戶在需求工程中的“義務” 以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。 樂意接受需求分析員的采訪，在不泄漏機密的前提下盡可能地回答需求分析員的問題。 在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關的材料。 與需求分析員共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿。,18,學習交流PPT,需求開發(fā)的主要困難與對策,4 用戶說不清楚需求 用戶說不清楚

12、需求是普遍現(xiàn)象，這讓我們很頭痛。 有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當然說不清楚需求。 有些用戶雖然心里明白想要什么，但卻說不清楚需求。 好像說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試，試穿時感覺到舒服才會買鞋。 我們絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，這樣會連累整個開發(fā)團隊的。 對于不清楚需求的用戶，我們可以根據(jù)客戶的業(yè)務，按我們的理解提出用戶需求，然后再找用戶確認。事實上，作為系統(tǒng)分析人員，在做系統(tǒng)分析的時候，其實也是在為國家信息化建設做普及教育工作。 對于知道需求的用戶，我們可以根據(jù)用戶大概的描敘，在按照我

13、們的理解，再系統(tǒng)地地復述給用戶，讓用戶確認。,19,學習交流PPT,需求開發(fā)的主要困難與對策,5 雙方誤解需求 人們在交流的時候，經(jīng)常會發(fā)生“問非所求，答非所問”的事情。 有時用戶會把開發(fā)人員的建議或答復給想歪了： 而用戶表達的需求，不同的開發(fā)人員可能有不同的理解。如果需求分析員誤解了需求，那會導致后續(xù)的不少開發(fā)人員將錯就錯、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯誤連高智商的外星人都不能避免： 不論是復雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認工作（屬于需求管理）必不可少。,20,學習交流PPT,需求開發(fā)的主要困難與對策,6 開發(fā)人員寫不好需求文檔 需求調(diào)

14、查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。 古時候，一書生在考試前補習“寫文章”，成天愁眉苦臉。其夫人甚為不解，問：“相公，你寫文章比我生小孩還難嗎？”書生長嘆一聲：“娘子你哪里知道我的難處??！你生小孩時肚子里有東西，可我寫文章時肚子里沒東西啊?！?所以要想寫出好的需求文檔，前提條件是把需求調(diào)查工作做好。 開發(fā)人員寫作能力比較差，雖然在調(diào)查過程中已經(jīng)獲得了不少需求信息，卻寫不出好的需求文檔來。 可以毫不夸張地說，國內(nèi)90以上的軟件開發(fā)人員，他們的寫作能力遠不及開發(fā)能力。 提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習寫文檔，熟能生巧。 另外，公司應當提供合適的文檔模板以及

15、比較好的示例文檔，盡可能地降低寫作難度。,21,學習交流PPT,需求開發(fā)的主要困難與對策,7 用戶經(jīng)常變更需求 需求變更通常會對項目的進度、人力資源、經(jīng)費產(chǎn)生很大的影響，這是開發(fā)商非常畏懼的問題。 如果在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，導致產(chǎn)品的部分內(nèi)容需要重新開發(fā)。毫無疑問，這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的，雙方應當好好反省，認真學習需求開發(fā)和管理的方法，避免再犯相似的錯誤。 如果由于市場變化而導致產(chǎn)品需求發(fā)生變更，開發(fā)商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那么開發(fā)商吃了“上一

16、頓”就沒有“下一頓”。正因為市場在變化，才會產(chǎn)生更多商機。 其實需求變更并不可怕，可怕的是需求變更失去控制，導致項目混亂。所以需求變更控制是需求工程的重要活動。,22,學習交流PPT,如何開展需求調(diào)查,1 準備調(diào)查 首先，需求分析員應當起草需求調(diào)查問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。 問題表可以有多份，隨著調(diào)查的深入，問題表將不斷地被細化。 根據(jù)經(jīng)驗，用戶通常沒有耐心回答復雜的論述題，所以問題表應當以“選擇題”和“是非題”為主。 制定問題表最簡便的方法就是從用戶需求說明書的模板中提取需求問題。 其次，需求分析員應當確定需求調(diào)查的方式，例如： 與用戶交談，向用戶提問題

17、。向用戶群體發(fā)調(diào)查問卷。 參觀用戶的工作流程，觀察用戶的操作。 與同行、專家交談，聽取他們的意見。 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。 從行業(yè)標準、規(guī)則中提取需求。 從Internet上搜查相關資料。 最后，需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員，所需資料等，撰寫需求調(diào)查計劃。要特別留意的是不要漏掉典型的用戶。,23,學習交流PPT,如何開展需求調(diào)查,2 執(zhí)行調(diào)查 按照計劃執(zhí)行調(diào)查。在調(diào)查過程中隨時記錄（或存儲）需求信息 。 與用戶面談時應當注意以下事項： 如果與用戶約好了時間，切勿遲到或早退。 我們應事先了解用戶的身份、背景，以便隨機應變。 需求調(diào)查不象偵探推理那樣從蛛

18、絲馬跡著手，應該先了解宏觀問題，再了解細節(jié)問題。 如果雙方氣氛融洽，可以采用靈活的訪談形式，輕易不要打斷用戶的談話。當雙方對某些問題的交流合乎邏輯地結(jié)束后，即可繼續(xù)討論問題表中的其它問題。 在自由聊天中了解用戶需求，比正式面談效果好。 盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調(diào)查的力度。 避免片面地聽取某些用戶的需求而忽視其它用戶的需求。 事實上，需求調(diào)查除了面談外，還可以查閱用戶的資料，在查閱資料的過程中，有問題再向用戶詢問。讓用戶邊工作，氣氛會顯得更加輕松。,24,學習交流PPT,如何開展需求調(diào)查,3撰寫或修改用戶需求說明書 用戶需求說明書與產(chǎn)品需求規(guī)格說明書的主要區(qū)別與聯(lián)

19、系 前者主要采用自然語言（和應用域術(shù)語）來表達用戶需求，其內(nèi)容相對于后者而言比較粗略，不夠詳細。 后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，產(chǎn)品需求是軟件系統(tǒng)設計的直接依據(jù)。 兩者之間可能并不存在一一影射關系，因為軟件開發(fā)商會根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當前狀況適當?shù)卣{(diào)整產(chǎn)品需求，例如用戶需求可能被分配到軟件的數(shù)個版本中。軟件開發(fā)人員應當依據(jù)產(chǎn)品需求規(guī)格說明書來開發(fā)當前產(chǎn)品。,25,學習交流PPT,26,學習交流PPT,如何進行需求分析,1 基本概念 有時候我們不得不鼓吹：用戶就是上帝，用戶永遠是正確的。 但事實上，很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現(xiàn)的需求。

20、需求分析是旨在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。 需求分析是需求開發(fā)過程中最費腦子的工作。分析方法大體有兩類：“問答分析法”和“建模分析法”。后者技術(shù)性比較強，寫出來有學術(shù)味，故大多數(shù)軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用（保你一學就會），很有實用價值。 “問答分析法”比較適合于用戶需求調(diào)查階段 “建模分析法”比較適合于產(chǎn)品需求定義階段。,27,學習交流PPT,如何進行需求分析,2 問答分析方法 問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問

21、自答”地分析需求，幾個人分析需求則稱為“研討”。 問答分析最重要的問題是：“是什么”和“為什么”。 每個需求都應當用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應補充說明“不是什么”。 如果“是什么”和“不是什么”并不是“理所當然”的，那么應當解釋“為什么”，以便加深讀者的理解。 追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。 其它常見的問題有： 需求存在二義性嗎？ 需求文檔的上下文有矛盾嗎？ 需求完備嗎？ 需求是必要的嗎？ 需求可實現(xiàn)嗎？ 需求可驗證嗎？ 需求的優(yōu)先級確定了嗎？,28,學習交流PPT,如何進行需求分析,3 建模分析法 人們都有這樣地感受：有些時候用語言描述

22、某個問題特別費勁，而采用圖形則使人一目了然，所謂“一圖低千言”就是這個道理。 在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。 需求建模就是指用圖形符號來表示、刻畫需求。 建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?恰當?shù)厥褂脠D形符號： 現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。 世上不存在一個包羅萬象的圖它能完整地描述需求。需求建模不可能取代文字描述

23、。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。,29,學習交流PPT,如何進行需求分析,4 作出決策 當需求從四面八方收集來后，需求的沖突在所難免。對于那些難以達成共識的需求而言，經(jīng)常會發(fā)生“公說公有理，婆說婆有理”的現(xiàn)象。那么需求分析員究竟應該聽誰的呢？ 如果一群人對需求有爭議，并不是誰聲音最響就聽誰的。根據(jù)生活經(jīng)驗，最保險的辦法是：先聽官兒大的或者威望高的，如果大家的職位和威望都差不多，那么采用“少數(shù)服從大多數(shù)”的原則。 如果一個產(chǎn)品可以賣給幾類客戶，但是各類客戶都要求產(chǎn)品按照他們的喜好來開發(fā)。此時對需求的決策應當以商業(yè)利

24、益為導向， 即哪一類客戶出錢最多就先滿足他們的需求，以后再做那些獲利相對較少的需求。 當開發(fā)者想象中的產(chǎn)品與客戶所提的需求有沖突時，一般應當尊重客戶的觀點。但是不要陷入“客戶總是對的”陷阱里，需求分析員應當糾正明顯不合理的客戶需求。如果產(chǎn)品很復雜，雙方都不太明白需求，此時最好請開發(fā)人員快速構(gòu)造軟件的原型，雙方看著軟件原型再分析需求。,30,學習交流PPT,什么是好的需求規(guī)格說明書,1 正確 需求規(guī)格說明書應當正確地反映用戶的真實意圖，“正確”是產(chǎn)品需求規(guī)格說明書最重要的屬性。如果“不正確”僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要

25、什么”和“不要什么”。為確保需求是正確的，開發(fā)方和用戶必須對需求規(guī)格說明書進行確認。 2 清楚 清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚： 文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？ 文檔的語句是否含糊其詞、羅里羅嗦？ 看了半天是否還不明白需求究竟是什么？ 3 無二義性 “無二義性” 是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。,31,學習交流PPT,什么是好的需求規(guī)格說明書,4 一致 “一致”（Consisten

26、t）是指產(chǎn)品需求規(guī)格說明書中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。 5 必要 產(chǎn)品需求規(guī)格說明書中的各項需求對用戶而言應當都是必要的。 可以把“必要”比喻為“雪中送炭”。但要把握好度，“必要”往前一步，要么是“畫蛇添足”要么是“錦上添花”。 6 完備 “完備”（Complete）是指產(chǎn)品需求規(guī)格說明書中沒有遺漏一些必要的需求。 人們往往傾向于關注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。 不完備的產(chǎn)品需求規(guī)格說明書將導致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。,32,學習交流PPT,什么是好的需求規(guī)格說明書,7 可實現(xiàn) 產(chǎn)品需求規(guī)格

27、說明書中的各項需求對我們而言應當都是可實現(xiàn)的（Attainable）。 “可實現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時間、費用、質(zhì)量等約束。 營銷人員和用戶談生意時，為了能拿到“單子”，他們往往對用戶提出的需求“來者不拒”。 所以，一般經(jīng)過雙方確認的產(chǎn)品需求規(guī)格說明書會作為商業(yè)合同附件，所以我們要把握好產(chǎn)品需求規(guī)格說明書中的內(nèi)容，盡量在合同范圍內(nèi)滿足客戶得需求，但一定要在時間、費用、質(zhì)量，技術(shù)內(nèi)能實現(xiàn)得，不能實現(xiàn)一定要和客戶進行接受說明，實在不行的可以進行業(yè)務裁決，由公司營銷人員人員搞定。 對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應事先與用戶協(xié)商，達成一致的處理意見，避免將來發(fā)生商

28、業(yè)糾紛。 8 可驗證 產(chǎn)品需求規(guī)格說明書中的各項需求對用戶方而言應當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。 例如，摩天大樓的一項需求是“抗十二級臺風”，,33,學習交流PPT,什么是好的需求規(guī)格說明書,9 確定優(yōu)先級 為什么要確定需求的“優(yōu)先級”？ 理論上講，軟件的所有需求都應當被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。 人們想出了“取舍”辦法：先做優(yōu)先級高的需求，后做（甚

29、至放棄）優(yōu)先級低的需求，這樣可以將風險降到最低。 需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。 10 闡述“做什么”而不是“怎么做” 產(chǎn)品需求規(guī)格說明書的重點是闡述“做什么”，而不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設計和實現(xiàn)階段的事情。 我們經(jīng)常把系統(tǒng)設計甚至編程的變量聲明等寫到 產(chǎn)品需求規(guī)格說明書中，讓用戶看不明白，也就無法簽字確認。,34,學習交流PPT,形成需求規(guī)格說明書,1 規(guī)程 第一步：細化并分析用戶需求 需求分析員首先對用戶需求說明書進行細化，對比較復雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解

30、需求。例如采用Rational 的Rose工具進行需求的建模分析，建模分析產(chǎn)生的文檔可以作為產(chǎn)品需求規(guī)格說明書的附件。補充說明：建模分析的技術(shù)難度比較高，需求分析員應當根據(jù)自身水平進行取舍。 第二步：撰寫產(chǎn)品需求規(guī)格說明書 需求分析員按照指定的文檔模板撰寫產(chǎn)品需求規(guī)格說明書。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話，則應當撰寫軟件需求規(guī)格說明書和硬件需求規(guī)格說明書。 第三步：進行需求確認 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審產(chǎn)品需求規(guī)格說明書，盡最大努力使產(chǎn)品需求規(guī)格說明書能夠正確無誤地反映用戶的真實意愿。 需求評審之后，開發(fā)方和客戶方的責任人對產(chǎn)品需求規(guī)格說明書作書面承諾

31、。 2 軟件需求規(guī)格說明書的參考模板,35,學習交流PPT,什么是好的需求規(guī)格說明書,36,學習交流PPT,需求管理：確認、跟蹤、變更控制,1 需求確認（評審和承諾） 需求確認是指開發(fā)方和客戶方共同對產(chǎn)品需求規(guī)格說明書進行評審，雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。 2 需求評審面臨的困難 需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到后頭越馬虎。 需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起并不容易，沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這

32、樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。 開評審會議時經(jīng)常會“跑題”，導致評審效率很低。有時話匣子一打開后關不上，大家越扯越遠，結(jié)果評審會議變成了聊天會議。主持人應當控制話題，避免大家討論與主題無關的東西。 開評審會議時經(jīng)常會發(fā)生爭議。適當?shù)臓幾h有利于澄清問題，比什么東西都一致贊成要好。然而當爭議變?yōu)闋幊硶r就壞事了，爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。 人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執(zhí)己見”。 不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。,37,學習交流PPT,需求管理：確認、跟蹤、變更控制,3 需求承諾 需求承諾是指開發(fā)方和客戶方的責任人對通過了正式技術(shù)評審的產(chǎn)品需求規(guī)格說明書作出承諾，該承諾具有商業(yè)合同的效果。 需求承諾的“八股文”如下： 本產(chǎn)品需求規(guī)格說明書建立在雙方對需求的共同理解基礎之上，我同意后續(xù)的開發(fā)工作根據(jù)該產(chǎn)品需求規(guī)格說明書開展。如果需求發(fā)生變化，我們將按照“變更控制規(guī)程”執(zhí)行。我明白需求的變更將導致雙方重新協(xié)商成本、資源和進度等。 甲方簽字 乙方簽字 人們在作出承諾之前務必要認真閱讀文檔，一定要明白簽字意味著什么。,38,學習交流PPT,需求管理