第2章IT項(xiàng)目管理之需求管理ppt課件

1、IT工程管理之需求為準(zhǔn)第二部分需求工程需求獲取需求分析文檔編寫需求形狀需求跟蹤版本控制需求開發(fā)需求管理需求驗(yàn)證需求變卦根底認(rèn)知需求相關(guān)概念分析需求的重要性需求是業(yè)務(wù)的根源，需求任務(wù)的優(yōu)劣對(duì)業(yè)務(wù)影響最大。就像一條河流，假設(shè)源頭被污染了，那么整條河流也就被污染了。需求是缺陷主要來(lái)源錯(cuò)誤定位費(fèi)用分析錯(cuò)誤引入階段分析James Martin：超越50%的缺陷由不完善的、不正確的、不準(zhǔn)確的和/或不明確的需求所引起James Martin：80%以上的用于定位業(yè)務(wù)錯(cuò)誤的費(fèi)用是基于業(yè)務(wù)系統(tǒng)需求定義的錯(cuò)誤一個(gè)小故事如何練就需求分析的火眼金晴？ 5W + 1H + 8C 5W就是 Who、When、Where、

2、What、WhyWhy是關(guān)鍵1H就是 How 需求本身的流程8C指的是8個(gè)約束和限制，即8個(gè)Constraints：包括性能Performance、本錢Cost、時(shí)間Time、可靠性Reliability、平安性Security、合規(guī)性Compliance、技術(shù)性Technology、兼容性Compatibility如何建立組織級(jí)需求工程？專業(yè)的角色做專業(yè)的事？專業(yè)的人做專業(yè)的事？需求工程貫穿開發(fā)全過程設(shè)計(jì)需求架構(gòu)設(shè)計(jì)系統(tǒng)規(guī)格軟件需求硬件需求質(zhì)量屬性DFX業(yè)務(wù)需求用戶需求內(nèi)部需求客戶要求功能需求非功能需求規(guī)范約束書面規(guī)范現(xiàn)實(shí)規(guī)范需求存在什么問題不是“大而全，而是“準(zhǔn)而精；鍍金.swf不是“熱點(diǎn)

3、組合，而是“關(guān)鍵點(diǎn)組合；不是“盲目跟風(fēng)，而是“為我所用；不是“構(gòu)成報(bào)告，而是“達(dá)成共識(shí)。CRUDLCreate-Read-Update-Delete-List1.可行性研討工程的時(shí)機(jī)選擇初步可行性研討詳細(xì)可行性研討1可行性分析報(bào)告模版2金蝶公司可行性分析報(bào)告2.工程立項(xiàng)立項(xiàng)管理過程建立方的立項(xiàng)管理承建方的立項(xiàng)管理1某大型集團(tuán)IT工程實(shí)施管理方法2校務(wù)通模型可研與立項(xiàng)合同工程立項(xiàng)過程1.甲方過程招標(biāo)書定義、乙方選擇、合同簽署2.乙方過程工程分析、競(jìng)標(biāo)、合同簽署3.相關(guān)文檔、 需求分析在工程中的位置用戶/系統(tǒng)業(yè)務(wù)管理者初始需求變卦的需求獲取,分析,定義,驗(yàn)證需求控制需求變卦需求規(guī)格闡明工程環(huán)境需求

4、開發(fā)需求管理需求工程活動(dòng)綜合關(guān)系包括：需求確認(rèn)、需求變卦控制、需求跟蹤1、需求確認(rèn)需求確認(rèn)是指開發(fā)方和用戶共同對(duì)需求文檔進(jìn)展評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后做出書面承諾，使需求文檔具有商業(yè)合同效果。需求管理的最終作用 需求管理的目的是在用戶與開發(fā)方之間建立對(duì)需求的共同了解，維護(hù)需求與任務(wù)成果的一致性，并控制需求的變卦。 一、需求確認(rèn)工程開發(fā)面臨的實(shí)踐問題工程開發(fā)面臨的實(shí)踐問題工程開發(fā)面臨的實(shí)踐問題需求驗(yàn)證的目的和義務(wù)需求驗(yàn)證的目的就是要確保軟件需求具有良好的特性如完好性，正確性等。需求驗(yàn)證包含的活動(dòng)滿足性功能需求能否滿足需求稱心性非功能需求能否稱心明確及含蓄的需求(失敗)、(勝利)共識(shí)行能否能共同了

5、解可行性技術(shù)能否可行明晰性信息能否存在含混性1、為需求進(jìn)展正式評(píng)審正式的審查過程需求評(píng)審做不好的后果： 需求變卦 需求不明確 需求不可測(cè) 需求不可實(shí)現(xiàn) 導(dǎo)致后續(xù)任務(wù)難于開展或經(jīng)常出現(xiàn)變卦 由于需求未能得到有效管理， 在最終工程驗(yàn)收過程中出現(xiàn)了令人不愉快的情況，實(shí)踐開發(fā)的軟件沒能完全反映用戶的需求，導(dǎo)致用戶不稱心，工程延期。如何進(jìn)展需求評(píng)審 參與需求分析和評(píng)審的人員的管理 軟件需求文檔的管理 需求分析過程的管理 需求變卦的管理需求規(guī)格評(píng)審實(shí)例例1：“產(chǎn)品應(yīng)在不少于每秒的正常周期內(nèi)提供形狀信息。分析：這個(gè)需求是不完好的： 形狀信息是什么，如何顯示給用戶。這個(gè)需求有幾處模糊。我們?cè)谧h論產(chǎn)品的哪部分？

6、形狀信息間隔真的假定為不少于秒？，甚者每10年顯示一條新的形狀信息也可以？也許它的意圖是音訊間隔不應(yīng)超越秒，那么1毫秒是不是太短？“每這個(gè)詞導(dǎo)致了不確定性。問題的后果，就是需求的不可證明。需求規(guī)格評(píng)審實(shí)例例1需求：后臺(tái)義務(wù)管理器因以誤差上下不超越10秒的秒間隔，在用戶界面的指定位置顯示形狀信息；假設(shè)后臺(tái)進(jìn)程處置正常，那么應(yīng)該顯示義務(wù)已完成的百分?jǐn)?shù)/比；義務(wù)完成時(shí)，應(yīng)顯示相關(guān)的信息；后臺(tái)義務(wù)出錯(cuò)應(yīng)該顯示錯(cuò)誤信息；為了測(cè)試和追蹤，將需求分解多個(gè)子需求。使在構(gòu)造和測(cè)試時(shí)，被易于分別執(zhí)行。需求規(guī)格評(píng)審實(shí)例例2：“產(chǎn)品應(yīng)瞬間在文本中的顯示和隱藏不可打印字符間切換 計(jì)算機(jī)在瞬間不能做任何事，所以這個(gè)需求不

7、真實(shí)可行。它的不完好性表如今沒有聲明觸發(fā)形狀切換的條件。軟件要在某些條件下更改本人？或者用戶為了模擬更改要做一些什么動(dòng)作？而且，在文檔中改動(dòng)顯示的范圍是多大：選中的文本？整個(gè)的文檔，或其他的？這也是個(gè)模模糊的問題。不可打印字符和隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問題的后果，就是需求的不可證明。需求規(guī)格評(píng)審實(shí)例例2需求：用戶可以在一個(gè)由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏一切HTML標(biāo)志間切換。如今就很清楚，不可打印字符是HTML標(biāo)志。由于沒有定義觸發(fā)條件，需求對(duì)設(shè)計(jì)沒有約束力。只需設(shè)計(jì)人員選定了觸發(fā)條件后，他才干編寫測(cè)實(shí)驗(yàn)證觸發(fā)的正確操作。需求規(guī)格評(píng)審實(shí)例例3：“HTM

8、L分析器可以產(chǎn)生HTML標(biāo)志錯(cuò)誤報(bào)告，協(xié)助HTML入門者快速處理錯(cuò)誤。單詞“快速使其模糊，沒有加進(jìn)錯(cuò)誤報(bào)告的定義也是不完好的。我不知道，他怎樣驗(yàn)證這個(gè)需求。找一個(gè)自稱為HTML的入門者，看看能不能根據(jù)錯(cuò)誤報(bào)告快速處理錯(cuò)誤？需求規(guī)格評(píng)審實(shí)例例3需求：“HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告，錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的HTML文本和行號(hào)以及錯(cuò)誤的描畫。假設(shè)沒有錯(cuò)誤，就不會(huì)產(chǎn)生錯(cuò)誤報(bào)告。如今我們知道了，什么會(huì)被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，那么留由設(shè)計(jì)人員決議。我們還指定了一個(gè)例外：假設(shè)沒有發(fā)現(xiàn)錯(cuò)誤，不產(chǎn)生錯(cuò)誤報(bào)告。需求規(guī)格評(píng)審實(shí)例 練習(xí)：以下描畫哪些屬于不準(zhǔn)確的用戶需求描畫？假設(shè)不

9、準(zhǔn)確，應(yīng)如何矯正？ 1系統(tǒng)應(yīng)表現(xiàn)出良好的呼應(yīng)速度。 不準(zhǔn)確，應(yīng)指出詳細(xì)工程和呼應(yīng)時(shí)間。 2系統(tǒng)必需用菜單驅(qū)動(dòng)。 “必需不準(zhǔn)確，因系統(tǒng)還可以用其他方式驅(qū)動(dòng)。 3在數(shù)據(jù)錄入界面，應(yīng)該有10個(gè)按鈕。 不準(zhǔn)確，因過于細(xì)致，限制了設(shè)計(jì)的自在度。 4系統(tǒng)運(yùn)轉(zhuǎn)時(shí)占用的內(nèi)存不得超越200M。 僅是一個(gè)約束條件。 5電梯應(yīng)平穩(wěn)運(yùn)轉(zhuǎn)。 不準(zhǔn)確，應(yīng)指出加速、減速、運(yùn)轉(zhuǎn)速度的大小。 6即使系統(tǒng)解體，也不能損壞用戶數(shù)據(jù)。 不準(zhǔn)確，因這是一個(gè)難以保證的“用戶需求。2、為需求寫測(cè)試用例目的是識(shí)別需求的含混性 以需求為根底，并視其為黑盒子，然后編寫測(cè)試用例。 要覆蓋需求常見的測(cè)試點(diǎn)入口條件出口條件主事件流可選事件流非功能需求

10、3、用檢查單識(shí)別常見問題4、為需求設(shè)定優(yōu)先級(jí)支持工程分期交付支持需求取舍之道支持需求的方式化 為什么要設(shè)定需求的優(yōu)先級(jí)軟件開發(fā)受時(shí)間、本錢、質(zhì)量等多種資源的限制，同時(shí)軟件開發(fā)的高不確定性，導(dǎo)致 需求在工程終了時(shí)往往難以被全部實(shí)現(xiàn)。因此需求在需求開發(fā)階段，對(duì)需求進(jìn)展分解，設(shè)定優(yōu)先級(jí)，先實(shí)現(xiàn)優(yōu)先級(jí)別較高的需求，有助于維護(hù)工程收益和提高工程勝利率。基于價(jià)值、費(fèi)用和風(fēng)險(xiǎn)的優(yōu)先級(jí)設(shè)定費(fèi)用方法Cost：價(jià)值方法Value：風(fēng)險(xiǎn)方法Risk：最小費(fèi)用優(yōu)先原那么最高價(jià)值優(yōu)先原那么最低風(fēng)險(xiǎn)優(yōu)先原那么 它們本質(zhì)上從單一視角探尋適用規(guī)范來(lái)評(píng)價(jià)每個(gè)需求，并且計(jì)算出一個(gè)分值用于編排需求的優(yōu)先級(jí)。 如何設(shè)定需求的優(yōu)先級(jí)基

11、于價(jià)值、費(fèi)用和風(fēng)險(xiǎn)的優(yōu)先級(jí)設(shè)定XXXXX%XXX%XXX%XXXXn. XXXXX優(yōu)先級(jí) 風(fēng)險(xiǎn)% 相對(duì)風(fēng)險(xiǎn) 費(fèi)用% 相對(duì)費(fèi)用 價(jià)值% 總價(jià)值 相對(duì)損失 相對(duì)利潤(rùn) 需求/特性XXXXX%XXX%XXX%XXXX1. XXXXX總計(jì)XXXX相對(duì)權(quán)值在一個(gè)平面中列出要設(shè)定優(yōu)先級(jí)的一切需求、特性或運(yùn)用實(shí)例；在這個(gè)例子中，我們將運(yùn)用特性來(lái)設(shè)定優(yōu)先級(jí)。一切項(xiàng)都必需在同一籠統(tǒng)級(jí)別上；不要把個(gè)人需求與產(chǎn)品特性混合在一同。假設(shè)某些特性有邏輯上的聯(lián)絡(luò)例如，只需包括特性A的情況下才干實(shí)現(xiàn)特性B那么在分析中只需列出驅(qū)動(dòng)特性就可以了。這種模型在其有效范圍內(nèi)可以包容幾十種特性。假設(shè)他有更多的項(xiàng)，那么就把相關(guān)的特性歸成一類

12、，并建立一個(gè)可管理的初始化列表。假設(shè)他需求的話，可以在更詳細(xì)的級(jí)別上進(jìn)展第二輪分析。估計(jì)每一個(gè)特性提供應(yīng)客戶或業(yè)務(wù)的相關(guān)利益，并用1 9劃分等級(jí)，1代表可忽略的利益，9代表最大的價(jià)值。這些利益等級(jí)闡明了與產(chǎn)品的業(yè)務(wù)需求的一致性?？蛻舸硎桥袆e這些利益的最正確人選。在缺省情況下，利潤(rùn)和損失的權(quán)值是相等的，作為一種精化，他可以更改這兩個(gè)要素的相對(duì)權(quán)值。估計(jì)出假設(shè)沒有把應(yīng)該實(shí)現(xiàn)的特性包括到產(chǎn)品中，將會(huì)給客戶或業(yè)務(wù)上帶來(lái)的損失。運(yùn)用1 9劃分等級(jí)，這里1代表根本無(wú)損失， 9代表嚴(yán)重?fù)p失?？們r(jià)值相對(duì)利潤(rùn)相對(duì)損失價(jià)值%=總價(jià)值/總計(jì)價(jià)值100 根據(jù)需求的復(fù)雜度，所需求的用戶界面的實(shí)現(xiàn)情況、重用當(dāng)前代碼的潛

13、在才干、所需求的測(cè)試量和文檔等等，開發(fā)者可以估算出費(fèi)用。 估計(jì)實(shí)現(xiàn)每個(gè)特性的相對(duì)費(fèi)用，運(yùn)用1低 9高劃分等級(jí)。平面圖將計(jì)算出由每一個(gè)特性所構(gòu)成的總費(fèi)用的百分比。開發(fā)者應(yīng)該要估計(jì)出與每個(gè)特性相關(guān)的技術(shù)或風(fēng)險(xiǎn)相對(duì)程度，并利用1 9劃分等級(jí)。1級(jí)表示他可以輕而易舉地實(shí)現(xiàn)編程，而9級(jí)表示需求極大地關(guān)注其可行性、缺乏具有專門知識(shí)的人員，或者運(yùn)用不成熟或不熟習(xí)的工具和技術(shù)。平面圖將計(jì)算出每個(gè)特性所產(chǎn)生的風(fēng)險(xiǎn)百分比。在缺省情況下，利潤(rùn)損失，費(fèi)用和風(fēng)險(xiǎn)的權(quán)值是相等的，但是他可以在平面圖中調(diào)整其權(quán)值。假設(shè)他無(wú)需在模型中思索風(fēng)險(xiǎn)，就把風(fēng)險(xiǎn)的權(quán)值設(shè)為0。 價(jià)值%優(yōu)先級(jí)費(fèi)用%費(fèi)用權(quán)值風(fēng)險(xiǎn)%風(fēng)險(xiǎn)權(quán)值優(yōu)先級(jí)設(shè)定演示相對(duì)權(quán)

14、值2110.5 需求/ 特性相對(duì)利潤(rùn) 相對(duì)損失 總價(jià)值 價(jià)值% 相對(duì)費(fèi)用 費(fèi)用% 相對(duì)風(fēng)險(xiǎn) 風(fēng)險(xiǎn)% 優(yōu)先級(jí) UC153138.42813.01.345UC2972516.2511.939.10.987UC355159.737.126.10.957UC42153.212.413.00.833UC5491711.049.5412.10.708UC643117.137.126.10.702UC762149.149.539.10.646UC8982616.9716.78220.586UC934106.549.526.10.517UC1074811.7921.4721.20.365總計(jì)544615410

15、04210033100迭代1 BaseLine=UC1-3迭代2BaseLine=UC4-6迭代3 BaseLine=UC7-95、最后：構(gòu)成總體共識(shí) 本需求文檔建立在雙方對(duì)需求的共同了解根底上，我贊同后續(xù)的開發(fā)任務(wù)根據(jù)該需求文檔開展。假設(shè)需求發(fā)生變化，我們將按照“需求變卦控制規(guī)程執(zhí)行。我明白，需求的變卦將導(dǎo)致雙方重新協(xié)商本錢、資源和進(jìn)度等。 甲方擔(dān)任人簽字 乙方擔(dān)任人簽字什么是需求變卦？工程實(shí)現(xiàn)需求的程度(失敗)、勝利初始需求變卦的需求對(duì)問題的初始了解對(duì)問題的新了解時(shí)間二、控制需求變卦受控的需求需求文檔V1系統(tǒng)實(shí)現(xiàn)V1系統(tǒng)實(shí)現(xiàn)V2需求變卦受控的需求變卦需求文檔V1需求文檔V2系統(tǒng)實(shí)現(xiàn)V1系統(tǒng)

16、實(shí)現(xiàn)V2需求變卦由CCB委員會(huì)裁定CCB的解釋CCB 變卦控制委員會(huì)(Change Control Board)CCB 是系統(tǒng)集成工程的一切者權(quán)益代表，負(fù)載裁定接受那些變卦。CCB由工程所涉及的多方成員共同組成，通常包括用戶和實(shí)施方的決策人員。CCB是決策機(jī)構(gòu)，不是作業(yè)機(jī)構(gòu)，通常CCB的任務(wù)是經(jīng)過評(píng)審手段來(lái)決議工程能否能變卦，不提出變卦方案。 同意提出變卦懇求變卦影響評(píng)價(jià)評(píng)審評(píng)價(jià)報(bào)告審批用戶認(rèn)可修訂工程方案實(shí)施變卦驗(yàn)證變卦終了回絕修正需求變卦控制流程需求變卦懇求單我國(guó)變卦管理五級(jí)成熟度模型需求變卦案例分析面對(duì)客戶的需求變卦，接受還是回絕？在某公司的工程管理課堂上，小李，小王、小林等人正在七嘴八

17、舌地議論紛紛。原來(lái)，大家正在討論公司最近遇到的兩個(gè)頗為有趣的工程。情況1：盡量滿足用戶需求據(jù)小王引見，這兩個(gè)工程分別由兩個(gè)工程經(jīng)理來(lái)?yè)?dān)任。其中，工程經(jīng)理A屬于“謙虛型，對(duì)于客戶提出的問題，無(wú)論大小都給與處理，客戶對(duì)此非常稱心，然而，工程進(jìn)度卻拖得比較長(zhǎng)，而且，客戶總想把一切的問題都改完再說(shuō)，工程曾經(jīng)一再延期。情況2：嚴(yán)厲執(zhí)行工程方案相比之下，工程經(jīng)理B顯得稍有些“盛氣凌人，對(duì)于客戶提出的問題，大多都不予理睬，客戶對(duì)此不是很稱心，不過，該工程的進(jìn)度控制得比較好，根本可以按期完成工程。分析1 不太遷就用戶小王：“對(duì)工程經(jīng)理來(lái)說(shuō)，本錢、質(zhì)量和時(shí)間是最為重要的三要素。與客戶的關(guān)系當(dāng)然很重要，但也要全盤

18、思索工程的各要素。對(duì)于用戶的要求，應(yīng)該在有限的范圍內(nèi)給與處理，但不可以做出太大的犧牲。一味的遷就用戶將會(huì)使整個(gè)工程失敗。分析2 堅(jiān)持原那么，適當(dāng)調(diào)理用戶關(guān)系小林：“當(dāng)前，國(guó)內(nèi)的工程普通情況下是由銷售處面簽單，再由工程經(jīng)理接手后續(xù)的任務(wù)，因此客戶關(guān)系多在事前曾經(jīng)搞定。發(fā)生新的情況后，可以由公司的公關(guān)部出面與客戶進(jìn)展協(xié)調(diào)，工程經(jīng)理可以在此過程中堅(jiān)持一下原那么，與公司的公關(guān)部一個(gè)紅臉，一個(gè)白臉，唱出一出好戲。分析3 用戶就是上帝小李：“不論怎樣，客戶才是第一位的?？蛻艨梢越o他帶來(lái)收入，也可以給他帶來(lái)更多的客戶和任務(wù)，有什么道理不多配合一下他們呢？說(shuō)實(shí)話我對(duì)B的做法蠻欣賞的，惋惜行不通。由于客戶是上帝

19、，假設(shè)照B的做法，后果會(huì)呵斥做一次工程丟掉一個(gè)客戶，太不劃算了。 問題： 1、假設(shè)他的工程遇到需求變卦問題，他會(huì)采用哪種方式去應(yīng)對(duì)？ 2、分析這兩種應(yīng)對(duì)需求變卦方式的優(yōu)缺陷。指點(diǎn)戰(zhàn)略：合理控制1、根據(jù)客戶提出需求的實(shí)踐情況而定對(duì)于客戶的需求，如何是合理的，在本人的范圍之內(nèi)，是可以變卦的，但是假設(shè)在對(duì)前面的主體框架是做以否認(rèn)的話，那就斷然回絕！指點(diǎn)戰(zhàn)略：合理控制2、把握好度工程的目的是在規(guī)定的時(shí)間內(nèi)完成規(guī)定的內(nèi)容。工程范圍在工程啟動(dòng)階段就曾經(jīng)確定下來(lái)了，絕對(duì)不能更改的。假設(shè)經(jīng)常更改，工程經(jīng)理需求分析一下緣由。假設(shè)是客戶緣由需求更改，工程經(jīng)理需求分析任務(wù)量，盡量少做改動(dòng)，但是不能完全回絕客戶。假設(shè)

20、全盤接受，客戶會(huì)毫無(wú)顧及的更改；假設(shè)全然回絕，就沒做好溝通管理。隨著開發(fā)任務(wù)的進(jìn)展需求將逐漸擴(kuò)展和演化各個(gè)開發(fā)階段的任務(wù)業(yè)務(wù)之間存在的承繼關(guān)系使每一項(xiàng)需求均能追溯到前后承繼關(guān)系的脈絡(luò)明晰可見三、需求跟蹤開發(fā)階段需求形狀需求建議設(shè)計(jì)編碼測(cè)試獲取定義承諾設(shè)計(jì)實(shí)現(xiàn)完成生存期各階段需求形狀的演化需求的類型及其追蹤性問題處理方案領(lǐng)域業(yè)務(wù)領(lǐng)域業(yè)務(wù)需求用戶需求軟件需求測(cè)試規(guī)約設(shè)計(jì)或代碼用戶手冊(cè)所要構(gòu)建的系統(tǒng)追蹤性需求跟蹤歸納如下：1、建立和維護(hù)需求跟蹤矩陣正向跟蹤逆向跟蹤當(dāng)需求文檔或后續(xù)任務(wù)成果發(fā)生變卦時(shí)，要及時(shí)更新需求跟蹤矩陣2、查找不一致后續(xù)任務(wù)成果沒有實(shí)現(xiàn)需求文檔中的某些需求后續(xù)任務(wù)成果實(shí)現(xiàn)了需求文檔中不存在的需求后續(xù)任務(wù)成果沒有正確實(shí)現(xiàn)需求文檔中的需求3、消除不一