項目管理之需求管理課件

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

5W就是Who、When、Where、What、WhyWhy是關(guān)鍵1H就是How–需求本身的流程8C指的是8個約束和限制，即8個Constraints：包括性能Performance、成本Cost、時間Time、可靠性Reliability、安全性Security、合規(guī)性Compliance、技術(shù)性Technology、兼容性Compatibility如何練就需求分析的火眼金晴？5W+1H+8C如何建立組織級需求工程？專業(yè)的角色做專業(yè)的事？專業(yè)的人做專業(yè)的事？如何建立組織級需求工程？專業(yè)的角色做專業(yè)的事？專業(yè)的人做專業(yè)需求工程貫穿開發(fā)全過程設(shè)計需求架構(gòu)設(shè)計系統(tǒng)規(guī)格軟件需求硬件需求質(zhì)量屬性DFX業(yè)務(wù)需求用戶需求內(nèi)部需求客戶要求功能需求非功能需求標(biāo)準(zhǔn)約束書面標(biāo)準(zhǔn)事實標(biāo)準(zhǔn)需求工程貫穿開發(fā)全過程設(shè)計需求架構(gòu)設(shè)計系統(tǒng)規(guī)格軟件需求硬件需需求存在什么問題不是“大而全”，而是“準(zhǔn)而精”；鍍金.swf不是“熱點組合”，而是“關(guān)鍵點組合”；不是“盲目跟風(fēng)”，而是“為我所用”；不是“形成報告”，而是“達成共識”。CRUDLCreate-Read-Update-Delete-List需求存在什么問題不是“大而全”，而是“準(zhǔn)而精”；鍍金.swf1.可行性研究項目的機會選擇初步可行性研究詳細可行性研究（1）可行性分析報告模版（2）金蝶公司可行性分析報告2.項目立項立項管理過程建設(shè)方的立項管理承建方的立項管理（1）某大型集團IT項目實施管理方法（2）校務(wù)通模型可研與立項1.可行性研究2.項目立項可研與立項第2章IT項目管理之需求管理合同項目立項過程1.甲方過程招標(biāo)書定義、乙方選擇、合同簽署2.乙方過程項目分析、競標(biāo)、合同簽署3.相關(guān)文檔《立項報告》、《可行性分析報告》、《標(biāo)書》合同項目立項過程1.甲方過程需求分析在工程中的位置用戶業(yè)務(wù)模型需求分析師抽象、提煉需求模型開發(fā)團隊設(shè)計依據(jù)軟件模型需求分析在工程中的位置用戶業(yè)務(wù)模型需求分析師抽象、提煉需求用戶/系統(tǒng)業(yè)務(wù)管理者初始需求變更的需求獲取,分析,定義,驗證需求控制需求變更需求規(guī)格說明項目環(huán)境需求開發(fā)需求管理需求工程活動綜合關(guān)系用戶/系統(tǒng)業(yè)務(wù)管理者初始需求變更的需求獲取,分析,定義,驗證包括：需求確認、需求變更控制、需求跟蹤1、需求確認需求確認是指開發(fā)方和用戶共同對需求文檔進行評審，雙方對需求達成共識后做出書面承諾，使需求文檔具有商業(yè)合同效果。需求管理的最終作用需求管理的目的是在用戶與開發(fā)方之間建立對需求的共同理解，維護需求與工作成果的一致性，并控制需求的變更。

包括：需求確認、需求變更控制、需求跟蹤需求管理的最終作用一、需求確認項目開發(fā)面臨的實際問題一、需求確認項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題需求驗證的目的和任務(wù)需求驗證的目的就是要確保軟件需求具有良好的特性（如完整性，正確性等）。需求驗證包含的活動滿足性（功能需求是否滿足需要）滿意性（非功能需求是否滿意）明確及含蓄的需求(失敗)、(成功)共識行（是否能共同理解）可行性（技術(shù)是否可行）明晰性（信息是否存在含混性）需求驗證的目的和任務(wù)需求驗證的目的就是要確保軟件需求具有良好1、為需求進行正式評審正式的審查過程1、為需求進行正式評審正式的審查過程需求評審做不好的后果：?需求變更?需求不明確?需求不可測?需求不可實現(xiàn)?導(dǎo)致后續(xù)工作難于開展或經(jīng)常出現(xiàn)變更

由于需求未能得到有效管理，在最終項目驗收過程中出現(xiàn)了令人不愉快的情況，實際開發(fā)的軟件沒能完全反映用戶的需求，導(dǎo)致用戶不滿意，項目延期。需求評審做不好的后果：?需求變更如何進行需求評審?參與需求分析和評審的人員的管理?軟件需求文檔的管理?需求分析過程的管理?需求變更的管理如何進行需求評審?參與需求分析和評審的人員的管理需求規(guī)格評審實例例1：“產(chǎn)品應(yīng)在不少于每秒的正常周期內(nèi)提供狀態(tài)信息?！狈治觯哼@個需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個需求有幾處含糊。我們在談?wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超過秒，那么1毫秒是不是太短？“每”這個詞導(dǎo)致了不確定性。問題的后果，就是需求的不可證實。需求規(guī)格評審實例例1：“產(chǎn)品應(yīng)在不少于每秒的正常周期內(nèi)提供狀需求規(guī)格評審實例例1需求：后臺任務(wù)管理器因以誤差上下不超過10秒的秒間隔，在用戶界面的指定位置顯示狀態(tài)信息；如果后臺進程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分數(shù)/比；任務(wù)完成時，應(yīng)顯示相關(guān)的信息；后臺任務(wù)出錯應(yīng)該顯示錯誤信息；為了測試和追蹤，將需求分解多個子需求。使在構(gòu)造和測試時，被易于分別執(zhí)行。需求規(guī)格評審實例例1需求：需求規(guī)格評審實例例2：“產(chǎn)品應(yīng)瞬間在文本中的顯示和隱藏不可打印字符間切換”

計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些什么動作？而且，在文檔中改變顯示的范圍是多大：選中的文本？整個的文檔，或其他的？這也是個模模糊的問題。不可打印字符和隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問題的后果，就是需求的不可證實。需求規(guī)格評審實例例2：“產(chǎn)品應(yīng)瞬間在文本中的顯示和隱藏不可打需求規(guī)格評審實例例2需求：用戶能夠在一個由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標(biāo)記間切換。現(xiàn)在就很清楚，不可打印字符是HTML標(biāo)記。由于沒有定義觸發(fā)條件，需求對設(shè)計沒有約束力。只有設(shè)計人員選定了觸發(fā)條件后，你才能編寫測試驗證觸發(fā)的正確操作。需求規(guī)格評審實例例2需求：需求規(guī)格評審實例例3：“HTML分析器可以產(chǎn)生HTML標(biāo)記錯誤報告，幫助HTML入門者快速解決錯誤”。單詞“快速”使其模糊，沒有加進錯誤報告的定義也是不完整的。我不知道，你怎么驗證這個需求。找一個自稱為HTML的入門者，看看能不能根據(jù)錯誤報告快速解決錯誤？需求規(guī)格評審實例例3：“HTML分析器可以產(chǎn)生HTML標(biāo)記錯需求規(guī)格評審實例例3需求：“HTML分析器可以產(chǎn)生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，就不會產(chǎn)生錯誤報告”?，F(xiàn)在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設(shè)計人員決定。我們還指定了一個例外：如果沒有發(fā)現(xiàn)錯誤，不產(chǎn)生錯誤報告。需求規(guī)格評審實例例3需求：需求規(guī)格評審實例練習(xí)：以下描述哪些屬于不精確的用戶需求描述？如果不精確，應(yīng)如何改正？

1）系統(tǒng)應(yīng)表現(xiàn)出良好的響應(yīng)速度。

不精確，應(yīng)指出具體項目和響應(yīng)時間。

2）系統(tǒng)必須用菜單驅(qū)動。

“必須”不精確，因系統(tǒng)還可以用其他方式驅(qū)動。

3）在數(shù)據(jù)錄入界面，應(yīng)該有10個按鈕。

不精確，因過于細致，限制了設(shè)計的自由度。

4）系統(tǒng)運行時占用的內(nèi)存不得超過200M。

僅是一個約束條件。

5）電梯應(yīng)平穩(wěn)運行。

不精確，應(yīng)指出加速、減速、運行速度的大小。

6）即使系統(tǒng)崩潰，也不能損壞用戶數(shù)據(jù)。

不精確，因這是一個難以保證的“用戶需求”。需求規(guī)格評審實例練習(xí)：以下描述哪些屬于不精確的用戶需求描2、為需求寫測試用例目標(biāo)是識別需求的含混性以需求為基礎(chǔ)，并視其為黑盒子，然后編寫測試用例。要覆蓋需求常見的測試點入口條件出口條件主事件流可選事件流非功能需求2、為需求寫測試用例目標(biāo)是識別需求的含混性3、用檢查單識別常見問題3、用檢查單識別常見問題4、為需求設(shè)定優(yōu)先級支持項目分期交付支持需求取舍之道支持需求的模式化4、為需求設(shè)定優(yōu)先級支持項目分期交付為什么要設(shè)定需求的優(yōu)先級軟件開發(fā)受時間、成本、質(zhì)量等多種資源的限制，同時軟件開發(fā)的高不確定性，導(dǎo)致需求在項目結(jié)束時往往難以被全部實現(xiàn)。因此需要在需求開發(fā)階段，對需求進行分解，設(shè)定優(yōu)先級，先實現(xiàn)優(yōu)先級別較高的需求，有助于維護項目收益和提高項目成功率。為什么要設(shè)定需求的優(yōu)先級軟件開發(fā)受時間、成本、質(zhì)量等多種資基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定費用方法（Cost）：價值方法（Value）：風(fēng)險方法（Risk）：最小費用優(yōu)先原則最高價值優(yōu)先原則最低風(fēng)險優(yōu)先原則它們本質(zhì)上從單一視角探尋適用標(biāo)準(zhǔn)來評價每個需求，并且計算出一個分值用于編排需求的優(yōu)先級。如何設(shè)定需求的優(yōu)先級基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定費用方法（Cost）：最小費基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定XXXXX%XXX%XXX%XXXXn.XXXXX優(yōu)先級風(fēng)險%相對風(fēng)險費用%相對費用價值%總價值相對損失相對利潤需求/特性XXXXX%XXX%XXX%XXXX1.XXXXX總計XXXX相對權(quán)值在一個平面中列出要設(shè)定優(yōu)先級的所有需求、特性或使用實例；在這個例子中，我們將使用特性來設(shè)定優(yōu)先級。所有項都必須在同一抽象級別上；不要把個人需求與產(chǎn)品特性混合在一起。如果某些特性有邏輯上的聯(lián)系（例如，只有包括特性A的情況下才能實現(xiàn)特性B）那么在分析中只要列出驅(qū)動特性就可以了。這種模型在其有效范圍內(nèi)可以容納幾十種特性。如果你有更多的項，那么就把相關(guān)的特性歸成一類，并建立一個可管理的初始化列表。如果你需要的話，可以在更詳細的級別上進行第二輪分析。估計每一個特性提供給客戶或業(yè)務(wù)的相關(guān)利益，并用1~9劃分等級，1代表可忽略的利益，9代表最大的價值。這些利益等級表明了與產(chǎn)品的業(yè)務(wù)需求的一致性?？蛻舸硎桥袛噙@些利益的最佳人選。在缺省情況下，利潤和損失的權(quán)值是相等的，作為一種精化，你可以更改這兩個因素的相對權(quán)值。估計出如果沒有把應(yīng)該實現(xiàn)的特性包括到產(chǎn)品中，將會給客戶或業(yè)務(wù)上帶來的損失。使用1~9劃分等級，這里1代表基本無損失，9代表嚴(yán)重損失?？們r值＝相對利潤＋相對損失價值%=總價值/總計價值×100

根據(jù)需求的復(fù)雜度，所需求的用戶界面的實現(xiàn)情況、重用當(dāng)前代碼的潛在能力、所需要的測試量和文檔等等，開發(fā)者可以估算出費用。估計實現(xiàn)每個特性的相對費用，使用1（低）~9（高）劃分等級。平面圖將計算出由每一個特性所構(gòu)成的總費用的百分比。開發(fā)者應(yīng)該要估計出與每個特性相關(guān)的技術(shù)或風(fēng)險相對程度，并利用1~9劃分等級。1級表示你可以輕而易舉地實現(xiàn)編程，而9級表示需要極大地關(guān)注其可行性、缺乏具有專門知識的人員，或者使用不成熟或不熟悉的工具和技術(shù)。平面圖將計算出每個特性所產(chǎn)生的風(fēng)險百分比。在缺省情況下，利潤損失，費用和風(fēng)險的權(quán)值是相等的，但是你可以在平面圖中調(diào)整其權(quán)值。如果你無需在模型中考慮風(fēng)險，就把風(fēng)險的權(quán)值設(shè)為0。價值%優(yōu)先級＝（費用%×費用權(quán)值）＋（風(fēng)險%×風(fēng)險權(quán)值）基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定XXXXX%XXX%XXX%優(yōu)先級設(shè)定演示相對權(quán)值2110.5需求/特性相對利潤相對損失總價值價值%相對費用費用%相對風(fēng)險風(fēng)險%優(yōu)先級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總計54461541004210033100迭代1BaseLine=UC1-3迭代2BaseLine=UC4-6迭代3BaseLine=UC7-9優(yōu)先級設(shè)定演示相對權(quán)值2110.5需求/特性相對相對總5、最后：形成總體共識

本需求文檔建立在雙方對需求的共同理解基礎(chǔ)上，我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白，需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進度等。甲方負責(zé)人簽字乙方負責(zé)人簽字5、最后：形成總體共識什么是需求變更？項目實現(xiàn)需求的程度(失敗)、（成功）初始需求變更的需求對問題的初始理解對問題的新理解時間二、控制需求變更什么是需求變更？初始需求變更的需求對問題的對問題的時間二、控受控的需求需求文檔V1系統(tǒng)實現(xiàn)V1系統(tǒng)實現(xiàn)V2需求變更受控的需求需求文檔V1系統(tǒng)實現(xiàn)系統(tǒng)實現(xiàn)需求變更受控的需求變更需求文檔V1需求文檔V2系統(tǒng)實現(xiàn)V1系統(tǒng)實現(xiàn)V2需求變更由CCB委員會裁定受控的需求變更需求文檔V1需求文檔V2系統(tǒng)實現(xiàn)系統(tǒng)實現(xiàn)需求變CCB的解釋CCB變更控制委員會(ChangeControlBoard)CCB是系統(tǒng)集成項目的所有者權(quán)益代表，負載裁定接受那些變更。CCB由項目所涉及的多方成員共同組成，通常包括用戶和實施方的決策人員。CCB是決策機構(gòu)，不是作業(yè)機構(gòu)，通常CCB的工作是通過評審手段來決定項目是否能變更，不提出變更方案。CCB的解釋CCB變更控制委員會(ChangeContr批準(zhǔn)提出變更請求變更影響評估評審評估報告審批用戶認可修訂項目計劃實施變更驗證變更結(jié)束拒絕修正需求變更控制流程批準(zhǔn)提出變更請求變更影響評估評審評估報告審批用戶認可修訂項目需求變更申請單（我國）需求變更申請單（我國）變更管理五級成熟度模型第五級統(tǒng)一平臺（建立變更管理工作流系統(tǒng)）第四級統(tǒng)一流程（為了協(xié)商小組高效工作而設(shè)定）第三級統(tǒng)一協(xié)商（批處理、根據(jù)項目設(shè)定變更批處理周期）第二級統(tǒng)一接口（協(xié)商改動的人應(yīng)少而精、項目層）第一級統(tǒng)一描述（變更單標(biāo)準(zhǔn)化）變更管理五級成熟度模型第五級統(tǒng)一平臺（建立變更管理工作流系需求變更案例分析面對客戶的需求變更，接受還是拒絕？在某公司的項目管理課堂上，小李，小王、小林等人正在七嘴八舌地議論紛紛。原來，大家正在討論公司最近遇到的兩個頗為有趣的項目。

需求變更案例分析面對客戶的需求變更，接受還是拒絕？情況1：盡量滿足用戶需要據(jù)小王介紹，這兩個項目分別由兩個項目經(jīng)理來擔(dān)任。其中，項目經(jīng)理A屬于“謙虛”型，對于客戶提出的問題，無論大小都給與解決，客戶對此非常滿意，然而，項目進度卻拖得比較長，而且，客戶總想把所有的問題都改完再說，項目已經(jīng)一再延期。情況1：盡量滿足用戶需要據(jù)小王介紹，這兩個項目分別由兩個項目情況2：嚴(yán)格執(zhí)行項目計劃相比之下，項目經(jīng)理B顯得稍有些“盛氣凌人”，對于客戶提出的問題，大多都不予理睬，客戶對此不是很滿意，不過，該項目的進度控制得比較好，基本能夠按期完成項目。情況2：嚴(yán)格執(zhí)行項目計劃相比之下，項目經(jīng)理B顯得稍有些“盛氣分析1不太遷就用戶小王：“對項目經(jīng)理來說，成本、質(zhì)量和時間是最為重要的三要素。與客戶的關(guān)系當(dāng)然很重要，但也要全盤考慮項目的各要素。對于用戶的要求，應(yīng)該在有限的范圍內(nèi)給與解決，但不可以做出太大的犧牲。一味的遷就用戶將會使整個項目失敗?！?/p>

分析1不太遷就用戶小王：“對項目經(jīng)理來說，成本、質(zhì)量和時間分析2堅持原則，適當(dāng)調(diào)節(jié)用戶關(guān)系小林：“當(dāng)前，國內(nèi)的項目一般情況下是由銷售處面簽單，再由項目經(jīng)理接手后續(xù)的工作，因此客戶關(guān)系多在事前已經(jīng)搞定。發(fā)生新的情況后，可以由公司的公關(guān)部出面與客戶進行協(xié)調(diào)，項目經(jīng)理可以在此過程中堅持一下原則，與公司的公關(guān)部一個紅臉，一個白臉，唱出一出好戲?！?/p>

分析2堅持原則，適當(dāng)調(diào)節(jié)用戶關(guān)系小林：“當(dāng)前，國內(nèi)的項目一分析3用戶就是上帝小李：“不管怎樣，客戶才是第一位的。客戶可以給你帶來收入，也可以給你帶來更多的客戶和工作，有什么道理不多配合一下他們呢？說實話我對B的做法蠻欣賞的，可惜行不通。因為客戶是上帝，如果照B的做法，后果會造成做一次項目丟掉一個客戶，太不劃算了?！?/p>

分析3用戶就是上帝小李：“不管怎樣，客戶才是第一位的?？蛻魡栴}：1、如果你的項目遇到需求變更問題，你會采用哪種方式去應(yīng)對？2、分析這兩種應(yīng)對需求變更方式的優(yōu)缺點。

問題：指導(dǎo)策略：合理控制1、根據(jù)客戶提出需求的實際情況而定對于客戶的需求，如何是合理的，在自己的范圍之內(nèi)，是可以變更的，但是如果在對前面的主體框架是做以否定的話，那就斷然拒絕！指導(dǎo)策略：合理控制1、根據(jù)客戶提出需求的實際情況而定指導(dǎo)策略：合理控制2、把握好度項目的目的是在規(guī)定的時間內(nèi)完成規(guī)定的內(nèi)容。項目范圍在項目啟動階段就已經(jīng)確定下來了，絕對不能更改的。如果經(jīng)常更改，項目經(jīng)理需要分析一下原因。如果是客戶原因需要更改，項目經(jīng)理需要分析工作量，盡量少做改動，但是不能完全拒絕客戶。如果全盤接受，客戶會毫無顧及的更改；如果全然拒絕，就沒做好溝通管理。指導(dǎo)策略：合理控制2、把握好度隨著開發(fā)工作的進展需求將逐步擴展和演化各個開發(fā)階段的工作業(yè)務(wù)之間存在的繼承關(guān)系使每一項需求均能追溯到前后繼承關(guān)系的脈絡(luò)清晰可見三、需求跟蹤隨著開發(fā)工作的進展需求將逐步擴展和演化三、需求跟蹤開發(fā)階段需求狀態(tài)需求建議設(shè)計編碼測試獲取定義承諾設(shè)計實現(xiàn)完成生存期各階段需求狀態(tài)的演變開發(fā)需求需求建議設(shè)計編碼測試獲取定義承諾設(shè)計實現(xiàn)完成生存期各需求的類型及其追蹤性問題解決方案領(lǐng)域業(yè)務(wù)領(lǐng)域業(yè)務(wù)需求用戶需求軟件需求測試規(guī)約設(shè)計或代碼用戶手冊所要構(gòu)建的系統(tǒng)追蹤性需求的類型及其追蹤性問題解決方案領(lǐng)域業(yè)務(wù)領(lǐng)域業(yè)務(wù)需求用戶需求需求跟蹤歸納如下：1、建立和維護需求跟蹤矩陣正向跟蹤逆向跟蹤當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣2、查找不一致后續(xù)工作成果沒有實現(xiàn)需求文檔中的某些需求后續(xù)工作成果實現(xiàn)了需求文檔中不存在的需求后續(xù)工作成果沒有正確實現(xiàn)需求文檔中的需求3、消除不一致將消除不一致記錄到“需求跟蹤報告”消除不一致后，項目經(jīng)理更新“需求跟蹤矩陣”需求跟蹤歸納如下：軟件需求屬性矩陣屬性需求需求狀態(tài)優(yōu)先級工作量風(fēng)險穩(wěn)定性產(chǎn)品版本職責(zé)分配原因功能需求非功能需求設(shè)計約束軟件需求屬性矩陣屬性需求優(yōu)先級工作量風(fēng)險穩(wěn)定性產(chǎn)品職責(zé)第2章IT項目管理之需求管理實現(xiàn)“需求全生命周期”的管理達到“需求-開發(fā)-測試”一體化實現(xiàn)“需求全生命周期”的管理需求生命周期管理平臺需求生命周期管理平臺一些重要名詞解釋管理流程：用于管理的規(guī)范流程（例如：需求確認、審批、簽署、驗收、變更流程等）OBS：組織分解結(jié)構(gòu)（以樹形結(jié)構(gòu)描述項目參與組織與角色的分解）WBS:工作分解結(jié)構(gòu)（以樹形結(jié)構(gòu)描述工作任務(wù)分解）PBS：產(chǎn)品分解結(jié)構(gòu)（以樹形結(jié)構(gòu)描述交付物分解）RBS:資源分解結(jié)構(gòu)（以樹形結(jié)構(gòu)描述服務(wù)于項目的資源）報表模版：項目執(zhí)行所需要的報表、報告、文檔的模版活動：Activity（WBS的葉子），也稱為工作，作業(yè)等依賴關(guān)系：作業(yè)(活動)的先后次序資源：有形資源，為完成工作所用到的人財物日歷：工作日歷關(guān)鍵路徑：一系列不得有任何推遲的工作，否則就來不及了浮時：那些有可能能推遲的工作的浮動時間量基線：計劃的快照，形成比較基準(zhǔn)風(fēng)險：預(yù)計未來可能發(fā)生并對項目產(chǎn)生影響的事件變更：項目進行過程中產(chǎn)生的新需求或原有需求的變化一些重要名詞解釋管理流程：用于管理的規(guī)范流程（例如：需求確認項目管理基礎(chǔ)動畫教程1、資源分配管理；2、個人效能；3、資源管理；4、風(fēng)險管理；5、承諾；6、不懂承諾的管理者；7、不明白依賴；8、不知后果；9、理解承諾事項；10、索取承諾的困難；11、信口開河；12、假裝信心；13、不切實際的信心；14、其實不可能做到；15、其實做到是萬幸；16、沒有自知之明；17、對任何人都說盡力；18、項目缺失了什么；19、現(xiàn)狀調(diào)查。項目管理基礎(chǔ)動畫教程1、資源分配管理；11、信口開河；本節(jié)結(jié)束，祝大家需求為準(zhǔn)！謝謝本節(jié)結(jié)束，祝大家需求為準(zhǔn)！謝謝IT項目管理之需求為準(zhǔn)第二部分IT項目管理之需求為準(zhǔn)第二部分需求工程需求獲取需求分析文檔編寫需求狀態(tài)需求跟蹤版本控制需求開發(fā)需求管理需求驗證需求變更需求工程需求獲取需求分析文檔編寫需求狀態(tài)需求跟蹤版本控制需求基礎(chǔ)認知需求相關(guān)概念剖析基礎(chǔ)認知需求相關(guān)概念剖析需求的重要性需求是業(yè)務(wù)的根源，需求工作的優(yōu)劣對業(yè)務(wù)影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。需求的重要性需求是業(yè)務(wù)的根源，需求工作的優(yōu)劣對業(yè)務(wù)影響最大。需求是缺陷主要來源錯誤定位費用分析錯誤引入階段分析JamesMartin：超過50%的缺陷由不完善的、不正確的、不準(zhǔn)確的和/或不明確的需求所引起JamesMartin：80%以上的用于定位業(yè)務(wù)錯誤的費用是基于業(yè)務(wù)系統(tǒng)需求定義的錯誤需求是缺陷主要來源錯誤定位費用分析錯誤引入階段分析James一個小故事一個小故事如何練就需求分析的火眼金晴？5W+1H+8C

5W就是Who、When、Where、What、WhyWhy是關(guān)鍵1H就是How–需求本身的流程8C指的是8個約束和限制，即8個Constraints：包括性能Performance、成本Cost、時間Time、可靠性Reliability、安全性Security、合規(guī)性Compliance、技術(shù)性Technology、兼容性Compatibility如何練就需求分析的火眼金晴？5W+1H+8C如何建立組織級需求工程？專業(yè)的角色做專業(yè)的事？專業(yè)的人做專業(yè)的事？如何建立組織級需求工程？專業(yè)的角色做專業(yè)的事？專業(yè)的人做專業(yè)需求工程貫穿開發(fā)全過程設(shè)計需求架構(gòu)設(shè)計系統(tǒng)規(guī)格軟件需求硬件需求質(zhì)量屬性DFX業(yè)務(wù)需求用戶需求內(nèi)部需求客戶要求功能需求非功能需求標(biāo)準(zhǔn)約束書面標(biāo)準(zhǔn)事實標(biāo)準(zhǔn)需求工程貫穿開發(fā)全過程設(shè)計需求架構(gòu)設(shè)計系統(tǒng)規(guī)格軟件需求硬件需需求存在什么問題不是“大而全”，而是“準(zhǔn)而精”；鍍金.swf不是“熱點組合”，而是“關(guān)鍵點組合”；不是“盲目跟風(fēng)”，而是“為我所用”；不是“形成報告”，而是“達成共識”。CRUDLCreate-Read-Update-Delete-List需求存在什么問題不是“大而全”，而是“準(zhǔn)而精”；鍍金.swf1.可行性研究項目的機會選擇初步可行性研究詳細可行性研究（1）可行性分析報告模版（2）金蝶公司可行性分析報告2.項目立項立項管理過程建設(shè)方的立項管理承建方的立項管理（1）某大型集團IT項目實施管理方法（2）校務(wù)通模型可研與立項1.可行性研究2.項目立項可研與立項第2章IT項目管理之需求管理合同項目立項過程1.甲方過程招標(biāo)書定義、乙方選擇、合同簽署2.乙方過程項目分析、競標(biāo)、合同簽署3.相關(guān)文檔《立項報告》、《可行性分析報告》、《標(biāo)書》合同項目立項過程1.甲方過程需求分析在工程中的位置用戶業(yè)務(wù)模型需求分析師抽象、提煉需求模型開發(fā)團隊設(shè)計依據(jù)軟件模型需求分析在工程中的位置用戶業(yè)務(wù)模型需求分析師抽象、提煉需求用戶/系統(tǒng)業(yè)務(wù)管理者初始需求變更的需求獲取,分析,定義,驗證需求控制需求變更需求規(guī)格說明項目環(huán)境需求開發(fā)需求管理需求工程活動綜合關(guān)系用戶/系統(tǒng)業(yè)務(wù)管理者初始需求變更的需求獲取,分析,定義,驗證包括：需求確認、需求變更控制、需求跟蹤1、需求確認需求確認是指開發(fā)方和用戶共同對需求文檔進行評審，雙方對需求達成共識后做出書面承諾，使需求文檔具有商業(yè)合同效果。需求管理的最終作用需求管理的目的是在用戶與開發(fā)方之間建立對需求的共同理解，維護需求與工作成果的一致性，并控制需求的變更。

包括：需求確認、需求變更控制、需求跟蹤需求管理的最終作用一、需求確認項目開發(fā)面臨的實際問題一、需求確認項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題項目開發(fā)面臨的實際問題需求驗證的目的和任務(wù)需求驗證的目的就是要確保軟件需求具有良好的特性（如完整性，正確性等）。需求驗證包含的活動滿足性（功能需求是否滿足需要）滿意性（非功能需求是否滿意）明確及含蓄的需求(失敗)、(成功)共識行（是否能共同理解）可行性（技術(shù)是否可行）明晰性（信息是否存在含混性）需求驗證的目的和任務(wù)需求驗證的目的就是要確保軟件需求具有良好1、為需求進行正式評審正式的審查過程1、為需求進行正式評審正式的審查過程需求評審做不好的后果：?需求變更?需求不明確?需求不可測?需求不可實現(xiàn)?導(dǎo)致后續(xù)工作難于開展或經(jīng)常出現(xiàn)變更

由于需求未能得到有效管理，在最終項目驗收過程中出現(xiàn)了令人不愉快的情況，實際開發(fā)的軟件沒能完全反映用戶的需求，導(dǎo)致用戶不滿意，項目延期。需求評審做不好的后果：?需求變更如何進行需求評審?參與需求分析和評審的人員的管理?軟件需求文檔的管理?需求分析過程的管理?需求變更的管理如何進行需求評審?參與需求分析和評審的人員的管理需求規(guī)格評審實例例1：“產(chǎn)品應(yīng)在不少于每秒的正常周期內(nèi)提供狀態(tài)信息?！狈治觯哼@個需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個需求有幾處含糊。我們在談?wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超過秒，那么1毫秒是不是太短？“每”這個詞導(dǎo)致了不確定性。問題的后果，就是需求的不可證實。需求規(guī)格評審實例例1：“產(chǎn)品應(yīng)在不少于每秒的正常周期內(nèi)提供狀需求規(guī)格評審實例例1需求：后臺任務(wù)管理器因以誤差上下不超過10秒的秒間隔，在用戶界面的指定位置顯示狀態(tài)信息；如果后臺進程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分數(shù)/比；任務(wù)完成時，應(yīng)顯示相關(guān)的信息；后臺任務(wù)出錯應(yīng)該顯示錯誤信息；為了測試和追蹤，將需求分解多個子需求。使在構(gòu)造和測試時，被易于分別執(zhí)行。需求規(guī)格評審實例例1需求：需求規(guī)格評審實例例2：“產(chǎn)品應(yīng)瞬間在文本中的顯示和隱藏不可打印字符間切換”

計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些什么動作？而且，在文檔中改變顯示的范圍是多大：選中的文本？整個的文檔，或其他的？這也是個模模糊的問題。不可打印字符和隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問題的后果，就是需求的不可證實。需求規(guī)格評審實例例2：“產(chǎn)品應(yīng)瞬間在文本中的顯示和隱藏不可打需求規(guī)格評審實例例2需求：用戶能夠在一個由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標(biāo)記間切換?，F(xiàn)在就很清楚，不可打印字符是HTML標(biāo)記。由于沒有定義觸發(fā)條件，需求對設(shè)計沒有約束力。只有設(shè)計人員選定了觸發(fā)條件后，你才能編寫測試驗證觸發(fā)的正確操作。需求規(guī)格評審實例例2需求：需求規(guī)格評審實例例3：“HTML分析器可以產(chǎn)生HTML標(biāo)記錯誤報告，幫助HTML入門者快速解決錯誤”。單詞“快速”使其模糊，沒有加進錯誤報告的定義也是不完整的。我不知道，你怎么驗證這個需求。找一個自稱為HTML的入門者，看看能不能根據(jù)錯誤報告快速解決錯誤？需求規(guī)格評審實例例3：“HTML分析器可以產(chǎn)生HTML標(biāo)記錯需求規(guī)格評審實例例3需求：“HTML分析器可以產(chǎn)生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，就不會產(chǎn)生錯誤報告”?，F(xiàn)在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設(shè)計人員決定。我們還指定了一個例外：如果沒有發(fā)現(xiàn)錯誤，不產(chǎn)生錯誤報告。需求規(guī)格評審實例例3需求：需求規(guī)格評審實例練習(xí)：以下描述哪些屬于不精確的用戶需求描述？如果不精確，應(yīng)如何改正？

1）系統(tǒng)應(yīng)表現(xiàn)出良好的響應(yīng)速度。

不精確，應(yīng)指出具體項目和響應(yīng)時間。

2）系統(tǒng)必須用菜單驅(qū)動。

“必須”不精確，因系統(tǒng)還可以用其他方式驅(qū)動。

3）在數(shù)據(jù)錄入界面，應(yīng)該有10個按鈕。

不精確，因過于細致，限制了設(shè)計的自由度。

4）系統(tǒng)運行時占用的內(nèi)存不得超過200M。

僅是一個約束條件。

5）電梯應(yīng)平穩(wěn)運行。

不精確，應(yīng)指出加速、減速、運行速度的大小。

6）即使系統(tǒng)崩潰，也不能損壞用戶數(shù)據(jù)。

不精確，因這是一個難以保證的“用戶需求”。需求規(guī)格評審實例練習(xí)：以下描述哪些屬于不精確的用戶需求描2、為需求寫測試用例目標(biāo)是識別需求的含混性以需求為基礎(chǔ)，并視其為黑盒子，然后編寫測試用例。要覆蓋需求常見的測試點入口條件出口條件主事件流可選事件流非功能需求2、為需求寫測試用例目標(biāo)是識別需求的含混性3、用檢查單識別常見問題3、用檢查單識別常見問題4、為需求設(shè)定優(yōu)先級支持項目分期交付支持需求取舍之道支持需求的模式化4、為需求設(shè)定優(yōu)先級支持項目分期交付為什么要設(shè)定需求的優(yōu)先級軟件開發(fā)受時間、成本、質(zhì)量等多種資源的限制，同時軟件開發(fā)的高不確定性，導(dǎo)致需求在項目結(jié)束時往往難以被全部實現(xiàn)。因此需要在需求開發(fā)階段，對需求進行分解，設(shè)定優(yōu)先級，先實現(xiàn)優(yōu)先級別較高的需求，有助于維護項目收益和提高項目成功率。為什么要設(shè)定需求的優(yōu)先級軟件開發(fā)受時間、成本、質(zhì)量等多種資基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定費用方法（Cost）：價值方法（Value）：風(fēng)險方法（Risk）：最小費用優(yōu)先原則最高價值優(yōu)先原則最低風(fēng)險優(yōu)先原則它們本質(zhì)上從單一視角探尋適用標(biāo)準(zhǔn)來評價每個需求，并且計算出一個分值用于編排需求的優(yōu)先級。如何設(shè)定需求的優(yōu)先級基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定費用方法（Cost）：最小費基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定XXXXX%XXX%XXX%XXXXn.XXXXX優(yōu)先級風(fēng)險%相對風(fēng)險費用%相對費用價值%總價值相對損失相對利潤需求/特性XXXXX%XXX%XXX%XXXX1.XXXXX總計XXXX相對權(quán)值在一個平面中列出要設(shè)定優(yōu)先級的所有需求、特性或使用實例；在這個例子中，我們將使用特性來設(shè)定優(yōu)先級。所有項都必須在同一抽象級別上；不要把個人需求與產(chǎn)品特性混合在一起。如果某些特性有邏輯上的聯(lián)系（例如，只有包括特性A的情況下才能實現(xiàn)特性B）那么在分析中只要列出驅(qū)動特性就可以了。這種模型在其有效范圍內(nèi)可以容納幾十種特性。如果你有更多的項，那么就把相關(guān)的特性歸成一類，并建立一個可管理的初始化列表。如果你需要的話，可以在更詳細的級別上進行第二輪分析。估計每一個特性提供給客戶或業(yè)務(wù)的相關(guān)利益，并用1~9劃分等級，1代表可忽略的利益，9代表最大的價值。這些利益等級表明了與產(chǎn)品的業(yè)務(wù)需求的一致性。客戶代表是判斷這些利益的最佳人選。在缺省情況下，利潤和損失的權(quán)值是相等的，作為一種精化，你可以更改這兩個因素的相對權(quán)值。估計出如果沒有把應(yīng)該實現(xiàn)的特性包括到產(chǎn)品中，將會給客戶或業(yè)務(wù)上帶來的損失。使用1~9劃分等級，這里1代表基本無損失，9代表嚴(yán)重損失?？們r值＝相對利潤＋相對損失價值%=總價值/總計價值×100

根據(jù)需求的復(fù)雜度，所需求的用戶界面的實現(xiàn)情況、重用當(dāng)前代碼的潛在能力、所需要的測試量和文檔等等，開發(fā)者可以估算出費用。估計實現(xiàn)每個特性的相對費用，使用1（低）~9（高）劃分等級。平面圖將計算出由每一個特性所構(gòu)成的總費用的百分比。開發(fā)者應(yīng)該要估計出與每個特性相關(guān)的技術(shù)或風(fēng)險相對程度，并利用1~9劃分等級。1級表示你可以輕而易舉地實現(xiàn)編程，而9級表示需要極大地關(guān)注其可行性、缺乏具有專門知識的人員，或者使用不成熟或不熟悉的工具和技術(shù)。平面圖將計算出每個特性所產(chǎn)生的風(fēng)險百分比。在缺省情況下，利潤損失，費用和風(fēng)險的權(quán)值是相等的，但是你可以在平面圖中調(diào)整其權(quán)值。如果你無需在模型中考慮風(fēng)險，就把風(fēng)險的權(quán)值設(shè)為0。價值%優(yōu)先級＝（費用%×費用權(quán)值）＋（風(fēng)險%×風(fēng)險權(quán)值）基于價值、費用和風(fēng)險的優(yōu)先級設(shè)定XXXXX%XXX%XXX%優(yōu)先級設(shè)定演示相對權(quán)值2110.5需求/特性相對利潤相對損失總價值價值%相對費用費用%相對風(fēng)險風(fēng)險%優(yōu)先級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總計54461541004210033100迭代1BaseLine=UC1-3迭代2BaseLine=UC4-6迭代3BaseLine=UC7-9優(yōu)先級設(shè)定演示相對權(quán)值2110.5需求/特性相對相對總5、最后：形成總體共識

本需求文檔建立在雙方對需求的共同理解基礎(chǔ)上，我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白，需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進度等。甲方負責(zé)人簽字乙方負責(zé)人簽字5、最后：形成總體共識什么是需求變更？項目實現(xiàn)需求的程度(失敗)、（成功）初始需求變更的需求對問題的初始理解對問題的新理解時間二、控制需求變更什么是需求變更？初始需求變更的需求對問題的對問題的時間二、控受控的需求需求文檔V1系統(tǒng)實現(xiàn)V1系統(tǒng)實現(xiàn)V2需求變更受控的需求需求文檔V1系統(tǒng)實現(xiàn)系統(tǒng)實現(xiàn)需求變更受控的需求變更需求文檔V1需求文檔V2系統(tǒng)實現(xiàn)V1系統(tǒng)實現(xiàn)V2需求變更由CCB委員會裁定受控的需求變更需求文檔V1需求文檔V2系統(tǒng)實現(xiàn)系統(tǒng)實現(xiàn)需求變CCB的解釋CCB變更控制委員會(ChangeControlBoard)CCB是系統(tǒng)集成項目的所有者權(quán)益代表，負載裁定接受那些變更。CCB由項目所涉及的多方成員共同組成，通常包括用戶和實施方的決策人員。CCB是決策機構(gòu)，不是作業(yè)機構(gòu)，通常CCB的工作是通過評審手段來決定項目是否能變更，不提出變更方案。CCB的解釋CCB變更控制委員會(ChangeContr批準(zhǔn)提出變更請求變更影響評估評審評估報告審批用戶認可修訂項目計劃實施變更驗證變更結(jié)束拒絕修正需求變更控制流程批準(zhǔn)提出變更請求變更影響評估評審評估報告審批用戶認可修訂項目需求變更申請單（我國）需求變更申請單（我國）變更管理五級成熟度模型第五級統(tǒng)一平臺（建立變更管理工作流系統(tǒng)）第四級統(tǒng)一流程（為了協(xié)商小組高效工作而設(shè)定）第三級統(tǒng)一協(xié)商（批處理、根據(jù)項目設(shè)定變更批處理周期）第二級統(tǒng)一接口（協(xié)商改動的人應(yīng)少而精、項目層）第一級統(tǒng)一描述（變更單標(biāo)準(zhǔn)化）變更管理五級成熟度模型第五級統(tǒng)一平臺（建立變更管理工作流系需求變更案例分析面對客戶的需求變更，接受還是拒絕？在某公司的項目管理課堂上，小李，小王、小林等人正在七嘴八舌地議論紛紛。原來，大家正在討論公司最近遇到的兩個頗為有趣的項目。

需求變更案例分析面對客戶的需求變更，接受還是拒絕？情況1：盡量滿足用戶需要據(jù)小王介紹，這兩個項目分別由兩個項目經(jīng)理來擔(dān)任。其中，項目經(jīng)理A屬于“謙虛”型，對于客戶提出的問題，無論大小都給與解決，客戶對此非常滿意，然而，項目進度卻拖得比較長，而且，客戶總想把所有的問題都改完再說，項目已經(jīng)一再延期。情況1：盡量滿足用戶需要據(jù)小王介紹，這兩個項目分別由兩個項目情況2：嚴(yán)格執(zhí)行項目計劃相比之下，項目經(jīng)理B顯得稍有些“盛氣凌人”，對于客戶提出的問題，大多都不予理睬，客戶對此不是很滿意，不過，該項目的進度控制得比較好，基本能夠按期完成項目。情況2：嚴(yán)格執(zhí)行項目計劃相比之下，項目經(jīng)理B顯得稍有些“盛氣分析1不太遷就用戶小王：“對項目經(jīng)理來說，成本、質(zhì)量和時間是最為重要的三要素。與客戶的關(guān)系當(dāng)然很重要，但也要全盤考慮項目的各要素。對于用戶的要求，應(yīng)該在有限的范圍內(nèi)給與解決，但不可以做出太大的犧牲。一味的遷就用戶將會使整個項目失敗?！?/p>

分析1不太遷就用戶小王：“對項目經(jīng)理來說，成本、質(zhì)量和時間分析2堅持原則，適當(dāng)調(diào)節(jié)用戶關(guān)系小林：“當(dāng)前，國內(nèi)的項目一般情況下是由銷售處面簽單，再由項目經(jīng)理接手后續(xù)的工作，因此客戶關(guān)系多在事前已經(jīng)搞定。發(fā)生新的情況后，可以由公司的公關(guān)部出面與客戶進行協(xié)調(diào)，項目經(jīng)理可以在此過程中堅持一下原則，與公司的公關(guān)部一個紅臉，一個白臉，唱出一出好戲。”

分析2堅持原則，適當(dāng)調(diào)節(jié)用戶關(guān)系小林：“當(dāng)前，國內(nèi)的項目一分析3用戶就是上帝小李：“