需求分析師培訓課件

需求分析師培訓軟件需求實作要點與誤區(qū)分析需求分析師培訓軟件需求實作要點與誤區(qū)分析1Agenda不同軟件項目的需求視圖軟件需求誤區(qū)與應對之道需求工程組織與實作要點Agenda不同軟件項目的需求視圖2Agenda不同軟件項目的需求視圖軟件需求誤區(qū)與應對之道需求工程組織與實作要點Agenda不同軟件項目的需求視圖3軟件需求誤區(qū)與應對之道軟件需求誤區(qū)與應對之道4軟件需求誤區(qū)與應對之道軟件需求誤區(qū)與應對之道5需求問題的癥狀1癥狀：在軟件項目中，變更頻繁，而且集中出現在項目的中后階段。分析要點：

>變更是對原需求的背離，還是補遺(需求不完整)?

>背離發(fā)生在什么方面(流程間/流程內/數據使用…)？

>這些變更是需求階段是否可能預見的?

>是否存在無效的變更響應(管理有問題)?改進方向：

>變更的可預測性需求階段標識(需求捕獲/分析)

>變更渠道單一化、統一化(需求管理)需求問題的癥狀1癥狀：在軟件項目中，變更頻繁，而且集中出現6需求問題的癥狀2癥狀：軟件項目上線運行時遇到很多阻力。分析要點：

>是否為組織因素?

>阻力源于操作層還是管理層?改進方向：

>清晰的業(yè)務需求導向(需求定義)

>面向不同層面的需求分析

>正確識別組織因素(需求捕獲)需求問題的癥狀2癥狀：軟件項目上線運行時遇到很多阻力。7需求問題的癥狀3癥狀：軟件項目上線運行后效果很差。分析要點：

>為什么不使用(用戶界面/功能/手工系統)?

>使用者的成本/效益分析?改進方向：

>抓準業(yè)務需求(需求定義)

>不同層面用戶的分析(需求捕獲/分析)

需求問題的癥狀3癥狀：軟件項目上線運行后效果很差。8需求問題的癥狀4癥狀：產品二次開發(fā)量大。分析要點：

>二次開發(fā)量最要集中于什么方面(業(yè)務規(guī)則/用戶界面/流程順序/流程細節(jié)/報表格式)?改進方向：

>工作流模型順序/細節(jié)

>彈性設計業(yè)務規(guī)則/UI

>報表格式理解數據模型

需求問題的癥狀4癥狀：產品二次開發(fā)量大。9需求問題的癥狀5癥狀：產品/項目完全不可用或崩潰。分析要點：

>忽略了哪方面非功能需求?改進方向：

>性能與能力

>操作環(huán)境

>可靠性

>……

需求問題的癥狀5癥狀：產品/項目完全不可用或崩潰。10軟件需求誤區(qū)與應對之道軟件需求誤區(qū)與應對之道11需求:導致項目失敗的罪魁禍首根據StandishGroup對23000個項目進行的研究結果表明，28%的項目徹底失敗，46%的項目超出經費預算或者超出工期，只有約26%的項目獲得成功。而在于這些高達74%的不成功項目中，有約60%的失敗是源于需求問題。也就是說，有近45%的項目最終因為需求的問題最終導致失敗。

對不知道航行目的地的人來說，沒有順風！需求:導致項目失敗的罪魁禍首根據StandishGroup12我們在哪里重重摔了一跤在StandishGroup的報告中總結了導致項目失敗的最重要的8大原因中，有5個與需求相關：不完整的需求(13.1%)；缺乏用戶的介入(12.4%)；不實際的客戶期望(9.9%)；需求和規(guī)范的變更(8.7%)；提供了不再需要的(7.5%)

缺乏資源(10.6%),沒有執(zhí)行層支持(9.3%),缺少規(guī)劃(8.1%)我們在哪里重重摔了一跤在StandishGroup的報告中13項目成功的因素用戶的參與：15.9%管理層支持：13.9%清晰的需求描述(13.0%)；合適的規(guī)劃(9.6%)；現實的客戶期望(8.2%)；較小的里程碑(7.7%)；有才能的員工(7.2%)項目成功的因素用戶的參與：15.9%14軟件需求曾經讓我們如此狼狽

-軟件需求曾經讓我們如此狼狽

-15軟件需求誤區(qū)與應對之道軟件需求誤區(qū)與應對之道16需求是什么?需求是什么?17業(yè)務需求業(yè)務需求是指反映組織機構或客戶對系統、產品高層次的目標要求，通常問題定義本身就是業(yè)務需求。背景描述：XX保險公司希望充分利用日益完善的移動通信技術，在原有的辦公系統的基礎上進行擴展，使得在外的業(yè)務人員能夠及時地獲得客戶、業(yè)務相關的動態(tài)信息，與此同時，實現企業(yè)內部的即時通信。業(yè)務需求/目標：通過該系統的實施，將人

工保費續(xù)繳、投保手續(xù)辦理兩項業(yè)務運轉

周期縮短10％以上，使企業(yè)內部溝通效率

大幅改善，以幫助企業(yè)運轉效率得以提高。

業(yè)務需求業(yè)務需求是指反映組織機構或客戶對系統、產品高層次的目18業(yè)務需求就是系統目標現狀：功能分解盛行的今天，常常會犯“盲人摸象”的錯誤，這使得需求太過脆弱，難以經受考驗。目標！目標！還是目標！--系統開發(fā)應目標驅動！目標是團隊唯一的行動綱領。目標的定義不能夠流于形式，應該具有以下特征：業(yè)務導向、可度量、合理、可行。要

注意目標太夸大會浪費資源，目標

太縮小會影響士氣。（教堂與小屋）目標通常就是業(yè)務需求！

業(yè)務需求就是系統目標現狀：功能分解盛行的今天，常常會犯“盲人19用戶需求用戶需求是指描述用戶使用產品必須要完成什么任務，怎么完成的需求，通常是在問題定義的基礎上進用戶訪談、調查，對用戶使用的場景進行整理，從而建立從用戶角度的需求。用戶有不同類型：

>管理型、事務型>信息系統、人

>決策層、使用層>常用者、偶用者組織方法：用例、用戶故事、特性例子：對快到期的客戶，系統將通過短信

將續(xù)保信息發(fā)給該客戶的代理人用戶需求用戶需求是指描述用戶使用產品必須要完成什么任務，怎么20軟件需求從系統實現的角度描述的需求。開發(fā)人員（設計及分析人員）在業(yè)務需求、用戶需求的基礎上生成的。有時還需要考慮相關聯的硬件、環(huán)境方面的需求軟件需求從系統實現的角度描述的需求。21功能需求功能需求是需求的主體，是需求的本質功能需求定義了：系統必須完成的那些事，即為了向它的用戶提供有用的功能，產品必須執(zhí)行的動作零散（需求項）整理（特性、用例）敏捷方法：用戶故事功能需求功能需求是需求的主體，是需求的本質22質量屬性產品必須具備的屬性或品質可靠性：成熟性、容錯性、易恢復性易使用性：易理解性、易學習性、易操作性效率：時間特性、資源特性可維護性：易分析性、易更改性、穩(wěn)定性、易測試性可移植性：適應性、易安裝性、一致性、易替換性McCall體系：運行(正確性、可靠性、效率、

完整性、使用性)、修正(維護性、測試性、

靈活性)、轉移(移植性、復用性、共運行性)質量屬性產品必須具備的屬性或品質23設計約束也稱為限制條件、補充規(guī)約，這通常是對解決方案的一些約束說明。例如：必須采用國有自主知識版權的數據庫系統…再如：必須運行在UNIX操作系統之下三如：用戶將在戶外完成作業(yè)設計約束也稱為限制條件、補充規(guī)約，這通常是對解決方案的一些約24軟件需求誤區(qū)與應對之道軟件需求誤區(qū)與應對之道25優(yōu)秀的需求完整性：完整描述即將交付使用的功能，發(fā)現缺少某項信息，可以采用TBD來標注正確性：經過用戶或用戶信任的代理人審閱無歧義：對所有讀者只有一種一致的解釋必要性：每項需求記錄的功能都應是用戶真正需要的有優(yōu)先次序：提供了實現優(yōu)先級可行性：在已知能力和約束條件中實現可驗證性：可以設計測試方法來檢查優(yōu)秀的需求完整性：完整描述即將交付使用的功能，發(fā)現缺少某項信26Agenda不同軟件項目的需求視圖軟件需求誤區(qū)與應對之道需求工程組織與實作要點Agenda不同軟件項目的需求視圖27需求工程組織與實作要點需求工程組織與實作要點28需求工程組織與實作要點需求工程組織與實作要點29需求錯誤的代價需求錯誤的代價30需求開發(fā)與管理需求開發(fā)與管理31需求工程組織與實作要點需求工程組織與實作要點32需求開發(fā)活動需求開發(fā)活動33需求獲取應收集什么信息：

>問題域的描述--業(yè)務模型

>要求解決的問題列表（需求）

>用戶對解系統的行為或結構施加的任何約束信息來源：

>客戶（實際的和潛在的）

>任何原有解系統（已有系統）及其文檔

>原有系統用戶/新系統的潛在用戶

>應用（問題）領域專家

>定義了任何接口系統的特片和行為的文檔

>相關的技術標準和法規(guī)需求獲取應收集什么信息：

>問題域的描述--業(yè)務模型

>34需求獲取技術閱讀背景資料頭腦風暴討論分析文檔考古面談（用戶訪談）聯合應用設計用戶調查需求剝離現場觀摩任務觀察用例和場景需求獲取技術閱讀背景資料現場觀摩35需求獲取的誤區(qū)缺乏計劃性：隨意、走過場，預先沒計劃缺乏科學性：未從本質入手捕獲對象不明確，甚至造成岐義過于迷信現有文檔過于迷信“聽”到的東西需求獲取的誤區(qū)缺乏計劃性：隨意、走過場，預先沒計劃36需求分析所謂分析是指通過對問題域的研究，獲得對該領域特性及存在于其中（需要解決）的問題特性的透徹理解并用文檔說明分析方法：結構化分析法、面向對象分析法、面向問題域分析法任何分析法，均需描述以下幾個方面:

>問題域的結構

>問題子域的固有屬性及行為

>問題域中的重要事件及現象

>需求：應產生的效果需求分析所謂分析是指通過對問題域的研究，獲得對該領域特性及存37需求分析方法--結構化分析從基于文本分析和規(guī)格文檔圖形建模表示法結構化分析初期的模型：數據流圖+E-R圖數據流圖：體現了流程，但是以數據為中心的流程E-R圖：體現了要存儲的信息數據字典：對數據、數據流的描述對問題域的研究力度不夠大分析和設計之間缺乏清晰的界限，將

會導致不成熟的內部設計需求分析方法--結構化分析從基于文本分析和規(guī)格文檔圖形建模38需求分析--何時進行應該在“業(yè)務需求”充分理解，并且收集了最本質的“用戶需求”之后就開始需求分析，但并不是等到需求捕獲完全做完之后交替進行，先把握用戶需求主要部分，然后在分析的基礎上引入系統級的需求（系統的設計與實現角度），并且分析模型，成為開發(fā)人員之間、開發(fā)人員與客戶之間達成共識的一個平臺分析的基礎上，就會發(fā)現更多的不明確

項，更多待捕獲的信息，這時就可以生

成第二次的需求調研的計劃、問題、素材需求分析--何時進行應該在“業(yè)務需求”充分理解，并且收集了最39需求分析--何時結束需求捕獲、分析與建模、規(guī)格說明書的編寫、需求的驗證這個需求開發(fā)的循環(huán)，是在整個軟件開發(fā)生命周期中存在的每一次的循環(huán)，都將在需求開發(fā)的工作要點與份量上有所不同，它們應該遵循以下：

>從本質到邊緣：本質、重要、次重要、一般、鑲金

>細化階段是需求開發(fā)最密集的階段

>構建階段需求開發(fā)逐漸減少需求分析--何時結束需求捕獲、分析與建模、規(guī)格說明書的編寫、40需求分析--內容與形式需求分析與建模不應該是孤立的行為，產生的結果也不一定非得是規(guī)范度很高的標準文檔，而應該重在分析、重在方法、重在交流、重在解決問題團隊聚在一起，利用白板甚至是紙張，在充分的合作下進行分析與初步建模是成本最低、效率最高、實用性最強的方法對于這些活動所產生的結果，可以利用數碼相機、掃描儀進行文檔化，“直到你一定要用時，再寫文檔”對于比較重要、核心的內容，再采用Rose、Together這樣的工具進行文檔化需求分析--內容與形式需求分析與建模不應該是孤立的行為，產41編寫規(guī)約規(guī)格說明書是對需求分析結果的文檔化過程比較“正規(guī)”的開發(fā)組織都會重視這個活動，甚至可以說是“重視過度”，而且產生出來的文檔經常是與實際的開發(fā)脫離，完成之后就束之高閣，再也不使用、不更新。這是一個需求崩潰的信號規(guī)格說明書的格式與所采用的開發(fā)過程、分析方法相關的，不同的方法格式不同定義統一的格式是一個很重要的工作規(guī)約內容的嚴謹、正確、無岐義是很

重要的編寫規(guī)約規(guī)格說明書是對需求分析結果的文檔化過程42需求驗證這個工作大多數組織都不夠重視，導致這個工作直到交付系統時才真正被履行，這也就是為什么客戶拿到系統后才提出許多這樣那樣的需求變更，甚至認為整個系統都不是他所需要的提高需求質量的重要手段：

>需求評審

>需求確認

>通過原型來驗證需求需求驗證這個工作大多數組織都不夠重視，導致這個工作直到交付系43需求工程組織與實作要點需求工程組織與實作要點44需求開發(fā)與需求管理的分界需求開發(fā)與需求管理的分界45需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個項目開發(fā)的進度陷入混亂和失控的狀態(tài)，而且會變成一個“救火隊”式的工作，整天都在處理突發(fā)事件主要思想：將所有現在的、將來的需求進行優(yōu)先級評估，然后分解成為不同的組，每次迭代都選擇其中優(yōu)先級最高的部分進行開發(fā)，然后在迭

代完成之前，開發(fā)工作不響應變更，

這些劃入的需求項就是需求基線的組

成部分需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個46需求基線管理--操作思路我們應該在分析的基礎上，將需求整合成為用例或功能項，然后對其進行優(yōu)先級、依賴性進行綜合性評估優(yōu)先級判斷：業(yè)務人員確定業(yè)務決定，技術人員確定技術決策；“滿意度/不滿意度”模型依賴性是指對于某些功能，在實現上有必須的依賴關系，即當某些功能沒有實現時，另

外的功能無法開始，這就需要對其

進行調整需求基線管理--操作思路我們應該在分析的基礎上，將需求整合成47需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避它，更不是說要避免它，它實際上是希望控制變更在基線內的需求不響應變更，為開發(fā)人員提供一個安靜的工作時間狀態(tài)專門的需求變更管理來對所有的需求變更進行響應，了解需求變更的關鍵意圖、新產生的工作量，從而良好地進行重新計劃，以便能夠有效地解決其對整個開發(fā)帶來的麻煩需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避48需求跟蹤需求的跟蹤是指對需求的完成情況、變更影響進行系統化的跟蹤與處理“需求是不是已經被實現？”、“需求的變化將需要修改哪些設計元素？會影響誰的工作？對已經完成的部分是否有影響？”需求跟蹤需求的跟蹤是指對需求的完成情況、變更影響進行系統化的49需求工程組織與實作要點需求工程組織與實作要點50需求管理的參與者需