需求分析師培訓(xùn)資料

需求分析師培訓(xùn)軟件需求實(shí)作要點(diǎn)與誤區(qū)分析Agenda不同軟件項(xiàng)目的需求視圖軟件需求誤區(qū)與應(yīng)對(duì)之道需求工程組織與實(shí)作要點(diǎn)Agenda不同軟件項(xiàng)目的需求視圖軟件需求誤區(qū)與應(yīng)對(duì)之道需求工程組織與實(shí)作要點(diǎn)1理論是實(shí)踐的基礎(chǔ)2解決概念性誤區(qū)軟件需求誤區(qū)與應(yīng)對(duì)之道2.1透過(guò)表象，分析本質(zhì)2.2國(guó)內(nèi)外需求實(shí)踐現(xiàn)狀分析2.3需求的三個(gè)層面和三種類型2.4優(yōu)秀需求的要點(diǎn)與實(shí)現(xiàn)手段軟件需求誤區(qū)與應(yīng)對(duì)之道2.1透過(guò)表象，分析本質(zhì)2.2國(guó)內(nèi)外需求實(shí)踐現(xiàn)狀分析2.3需求的三個(gè)層面和三種類型2.4優(yōu)秀需求的要點(diǎn)與實(shí)現(xiàn)手段需求問(wèn)題的癥狀1癥狀：在軟件項(xiàng)目中，變更頻繁，而且集中出現(xiàn)在項(xiàng)目的中后階段。分析要點(diǎn)：

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

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

>這些變更是需求階段是否可能預(yù)見(jiàn)的?

>是否存在無(wú)效的變更響應(yīng)(管理有問(wèn)題)?改進(jìn)方向：

>變更的可預(yù)測(cè)性需求階段標(biāo)識(shí)(需求捕獲/分析)

>變更渠道單一化、統(tǒng)一化(需求管理)需求問(wèn)題的癥狀2癥狀：軟件項(xiàng)目上線運(yùn)行時(shí)遇到很多阻力。分析要點(diǎn)：

>是否為組織因素?

>阻力源于操作層還是管理層?改進(jìn)方向：

>清晰的業(yè)務(wù)需求導(dǎo)向(需求定義)

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

>正確識(shí)別組織因素(需求捕獲)需求問(wèn)題的癥狀3癥狀：軟件項(xiàng)目上線運(yùn)行后效果很差。分析要點(diǎn)：

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

>使用者的成本/效益分析?改進(jìn)方向：

>抓準(zhǔn)業(yè)務(wù)需求(需求定義)

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

需求問(wèn)題的癥狀4癥狀：產(chǎn)品二次開(kāi)發(fā)量大。分析要點(diǎn)：

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

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

>彈性設(shè)計(jì)業(yè)務(wù)規(guī)則/UI

>報(bào)表格式理解數(shù)據(jù)模型

需求問(wèn)題的癥狀5癥狀：產(chǎn)品/項(xiàng)目完全不可用或崩潰。分析要點(diǎn)：

>忽略了哪方面非功能需求?改進(jìn)方向：

>性能與能力

>操作環(huán)境

>可靠性

>……

軟件需求誤區(qū)與應(yīng)對(duì)之道2.1透過(guò)表象，分析本質(zhì)2.2國(guó)內(nèi)外需求實(shí)踐現(xiàn)狀分析2.3需求的三個(gè)層面和三種類型2.4優(yōu)秀需求的要點(diǎn)與實(shí)現(xiàn)手段需求:導(dǎo)致項(xiàng)目失敗的罪魁禍?zhǔn)赘鶕?jù)StandishGroup對(duì)23000個(gè)項(xiàng)目進(jìn)行的研究結(jié)果表明，28%的項(xiàng)目徹底失敗，46%的項(xiàng)目超出經(jīng)費(fèi)預(yù)算或者超出工期，只有約26%的項(xiàng)目獲得成功。而在于這些高達(dá)74%的不成功項(xiàng)目中，有約60%的失敗是源于需求問(wèn)題。也就是說(shuō)，有近45%的項(xiàng)目最終因?yàn)樾枨蟮膯?wèn)題最終導(dǎo)致失敗。

對(duì)不知道航行目的地的人來(lái)說(shuō)，沒(méi)有順風(fēng)！我們?cè)谀睦镏刂厮ち艘货釉赟tandishGroup的報(bào)告中總結(jié)了導(dǎo)致項(xiàng)目失敗的最重要的8大原因中，有5個(gè)與需求相關(guān)：不完整的需求(13.1%)；缺乏用戶的介入(12.4%)；不實(shí)際的客戶期望(9.9%)；需求和規(guī)范的變更(8.7%)；提供了不再需要的(7.5%)

缺乏資源(10.6%),沒(méi)有執(zhí)行層支持(9.3%),缺少規(guī)劃(8.1%)項(xiàng)目成功的因素用戶的參與：15.9%管理層支持：13.9%清晰的需求描述(13.0%)；合適的規(guī)劃(9.6%)；現(xiàn)實(shí)的客戶期望(8.2%)；較小的里程碑(7.7%)；有才能的員工(7.2%)軟件需求曾經(jīng)讓我們?nèi)绱死仟N

-軟件需求誤區(qū)與應(yīng)對(duì)之道2.1透過(guò)表象，分析本質(zhì)2.2國(guó)內(nèi)外需求實(shí)踐現(xiàn)狀分析2.3需求的三個(gè)層面和三種類型2.4優(yōu)秀需求的要點(diǎn)與實(shí)現(xiàn)手段需求是什么?業(yè)務(wù)需求業(yè)務(wù)需求是指反映組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常問(wèn)題定義本身就是業(yè)務(wù)需求。背景描述：XX保險(xiǎn)公司希望充分利用日益完善的移動(dòng)通信技術(shù)，在原有的辦公系統(tǒng)的基礎(chǔ)上進(jìn)行擴(kuò)展，使得在外的業(yè)務(wù)人員能夠及時(shí)地獲得客戶、業(yè)務(wù)相關(guān)的動(dòng)態(tài)信息，與此同時(shí)，實(shí)現(xiàn)企業(yè)內(nèi)部的即時(shí)通信。業(yè)務(wù)需求/目標(biāo)：通過(guò)該系統(tǒng)的實(shí)施，將人

工保費(fèi)續(xù)繳、投保手續(xù)辦理兩項(xiàng)業(yè)務(wù)運(yùn)轉(zhuǎn)

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

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

業(yè)務(wù)需求就是系統(tǒng)目標(biāo)現(xiàn)狀：功能分解盛行的今天，常常會(huì)犯“盲人摸象”的錯(cuò)誤，這使得需求太過(guò)脆弱，難以經(jīng)受考驗(yàn)。目標(biāo)！目標(biāo)！還是目標(biāo)！--系統(tǒng)開(kāi)發(fā)應(yīng)目標(biāo)驅(qū)動(dòng)！目標(biāo)是團(tuán)隊(duì)唯一的行動(dòng)綱領(lǐng)。目標(biāo)的定義不能夠流于形式，應(yīng)該具有以下特征：業(yè)務(wù)導(dǎo)向、可度量、合理、可行。要

注意目標(biāo)太夸大會(huì)浪費(fèi)資源，目標(biāo)

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

用戶需求用戶需求是指描述用戶使用產(chǎn)品必須要完成什么任務(wù)，怎么完成的需求，通常是在問(wèn)題定義的基礎(chǔ)上進(jìn)用戶訪談、調(diào)查，對(duì)用戶使用的場(chǎng)景進(jìn)行整理，從而建立從用戶角度的需求。用戶有不同類型：

>管理型、事務(wù)型>信息系統(tǒng)、人

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

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

完整性、使用性)、修正(維護(hù)性、測(cè)試性、

靈活性)、轉(zhuǎn)移(移植性、復(fù)用性、共運(yùn)行性)設(shè)計(jì)約束也稱為限制條件、補(bǔ)充規(guī)約，這通常是對(duì)解決方案的一些約束說(shuō)明。例如：必須采用國(guó)有自主知識(shí)版權(quán)的數(shù)據(jù)庫(kù)系統(tǒng)…再如：必須運(yùn)行在UNIX操作系統(tǒng)之下三如：用戶將在戶外完成作業(yè)軟件需求誤區(qū)與應(yīng)對(duì)之道2.1透過(guò)表象，分析本質(zhì)2.2國(guó)內(nèi)外需求實(shí)踐現(xiàn)狀分析2.3需求的三個(gè)層面和三種類型2.4優(yōu)秀需求的要點(diǎn)與實(shí)現(xiàn)手段優(yōu)秀的需求完整性：完整描述即將交付使用的功能，發(fā)現(xiàn)缺少某項(xiàng)信息，可以采用TBD來(lái)標(biāo)注正確性：經(jīng)過(guò)用戶或用戶信任的代理人審閱無(wú)歧義：對(duì)所有讀者只有一種一致的解釋必要性：每項(xiàng)需求記錄的功能都應(yīng)是用戶真正需要的有優(yōu)先次序：提供了實(shí)現(xiàn)優(yōu)先級(jí)可行性：在已知能力和約束條件中實(shí)現(xiàn)可驗(yàn)證性：可以設(shè)計(jì)測(cè)試方法來(lái)檢查Agenda不同軟件項(xiàng)目的需求視圖軟件需求誤區(qū)與應(yīng)對(duì)之道需求工程組織與實(shí)作要點(diǎn)1掌握需求相關(guān)工作任務(wù)2了解需求相關(guān)工作人員需求工程組織與實(shí)作要點(diǎn)3.1需求工作要素與需求工程3.5需求過(guò)程與SERU模型3.4需求參與人員構(gòu)成分析3.3需求管理工作要點(diǎn)解析3.2需求開(kāi)發(fā)工作要點(diǎn)解析需求工程組織與實(shí)作要點(diǎn)3.1需求工作要素與需求工程3.5需求過(guò)程與SERU模型3.4需求參與人員構(gòu)成分析3.3需求管理工作要點(diǎn)解析3.2需求開(kāi)發(fā)工作要點(diǎn)解析需求錯(cuò)誤的代價(jià)需求：1設(shè)計(jì)：5編碼：10測(cè)試：20～50運(yùn)行與維護(hù)：200

需求開(kāi)發(fā)與管理需求工程組織與實(shí)作要點(diǎn)3.1需求工作要素與需求工程3.5需求過(guò)程與SERU模型3.4需求參與人員構(gòu)成分析3.3需求管理工作要點(diǎn)解析3.2需求開(kāi)發(fā)工作要點(diǎn)解析需求開(kāi)發(fā)活動(dòng)需求獲取應(yīng)收集什么信息：

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

>要求解決的問(wèn)題列表（需求）

>用戶對(duì)解系統(tǒng)的行為或結(jié)構(gòu)施加的任何約束信息來(lái)源：

>客戶（實(shí)際的和潛在的）

>任何原有解系統(tǒng)（已有系統(tǒng)）及其文檔

>原有系統(tǒng)用戶/新系統(tǒng)的潛在用戶

>應(yīng)用（問(wèn)題）領(lǐng)域?qū)＜?/p>

>定義了任何接口系統(tǒng)的特片和行為的文檔

>相關(guān)的技術(shù)標(biāo)準(zhǔn)和法規(guī)需求獲取技術(shù)閱讀背景資料頭腦風(fēng)暴討論分析文檔考古面談（用戶訪談）聯(lián)合應(yīng)用設(shè)計(jì)用戶調(diào)查需求剝離現(xiàn)場(chǎng)觀摩任務(wù)觀察用例和場(chǎng)景需求獲取的誤區(qū)缺乏計(jì)劃性：隨意、走過(guò)場(chǎng)，預(yù)先沒(méi)計(jì)劃缺乏科學(xué)性：未從本質(zhì)入手捕獲對(duì)象不明確，甚至造成岐義過(guò)于迷信現(xiàn)有文檔過(guò)于迷信“聽(tīng)”到的東西需求分析所謂分析是指通過(guò)對(duì)問(wèn)題域的研究，獲得對(duì)該領(lǐng)域特性及存在于其中（需要解決）的問(wèn)題特性的透徹理解并用文檔說(shuō)明分析方法：結(jié)構(gòu)化分析法、面向?qū)ο蠓治龇?、面向?wèn)題域分析法任何分析法，均需描述以下幾個(gè)方面:

>問(wèn)題域的結(jié)構(gòu)

>問(wèn)題子域的固有屬性及行為

>問(wèn)題域中的重要事件及現(xiàn)象

>需求：應(yīng)產(chǎn)生的效果需求分析方法--結(jié)構(gòu)化分析從基于文本分析和規(guī)格文檔圖形建模表示法結(jié)構(gòu)化分析初期的模型：數(shù)據(jù)流圖+E-R圖數(shù)據(jù)流圖：體現(xiàn)了流程，但是以數(shù)據(jù)為中心的流程E-R圖：體現(xiàn)了要存儲(chǔ)的信息數(shù)據(jù)字典：對(duì)數(shù)據(jù)、數(shù)據(jù)流的描述對(duì)問(wèn)題域的研究力度不夠大分析和設(shè)計(jì)之間缺乏清晰的界限，將

會(huì)導(dǎo)致不成熟的內(nèi)部設(shè)計(jì)需求分析--何時(shí)進(jìn)行應(yīng)該在“業(yè)務(wù)需求”充分理解，并且收集了最本質(zhì)的“用戶需求”之后就開(kāi)始需求分析，但并不是等到需求捕獲完全做完之后交替進(jìn)行，先把握用戶需求主要部分，然后在分析的基礎(chǔ)上引入系統(tǒng)級(jí)的需求（系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)角度），并且分析模型，成為開(kāi)發(fā)人員之間、開(kāi)發(fā)人員與客戶之間達(dá)成共識(shí)的一個(gè)平臺(tái)分析的基礎(chǔ)上，就會(huì)發(fā)現(xiàn)更多的不明確

項(xiàng)，更多待捕獲的信息，這時(shí)就可以生

成第二次的需求調(diào)研的計(jì)劃、問(wèn)題、素材需求分析--何時(shí)結(jié)束需求捕獲、分析與建模、規(guī)格說(shuō)明書(shū)的編寫(xiě)、需求的驗(yàn)證這個(gè)需求開(kāi)發(fā)的循環(huán)，是在整個(gè)軟件開(kāi)發(fā)生命周期中存在的每一次的循環(huán)，都將在需求開(kāi)發(fā)的工作要點(diǎn)與份量上有所不同，它們應(yīng)該遵循以下：

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

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

>構(gòu)建階段需求開(kāi)發(fā)逐漸減少需求分析--內(nèi)容與形式需求分析與建模不應(yīng)該是孤立的行為，產(chǎn)生的結(jié)果也不一定非得是規(guī)范度很高的標(biāo)準(zhǔn)文檔，而應(yīng)該重在分析、重在方法、重在交流、重在解決問(wèn)題團(tuán)隊(duì)聚在一起，利用白板甚至是紙張，在充分的合作下進(jìn)行分析與初步建模是成本最低、效率最高、實(shí)用性最強(qiáng)的方法對(duì)于這些活動(dòng)所產(chǎn)生的結(jié)果，可以利用數(shù)碼相機(jī)、掃描儀進(jìn)行文檔化，“直到你一定要用時(shí)，再寫(xiě)文檔”對(duì)于比較重要、核心的內(nèi)容，再采用Rose、Together這樣的工具進(jìn)行文檔化編寫(xiě)規(guī)約規(guī)格說(shuō)明書(shū)是對(duì)需求分析結(jié)果的文檔化過(guò)程比較“正規(guī)”的開(kāi)發(fā)組織都會(huì)重視這個(gè)活動(dòng)，甚至可以說(shuō)是“重視過(guò)度”，而且產(chǎn)生出來(lái)的文檔經(jīng)常是與實(shí)際的開(kāi)發(fā)脫離，完成之后就束之高閣，再也不使用、不更新。這是一個(gè)需求崩潰的信號(hào)規(guī)格說(shuō)明書(shū)的格式與所采用的開(kāi)發(fā)過(guò)程、分析方法相關(guān)的，不同的方法格式不同定義統(tǒng)一的格式是一個(gè)很重要的工作規(guī)約內(nèi)容的嚴(yán)謹(jǐn)、正確、無(wú)岐義是很

重要的需求驗(yàn)證這個(gè)工作大多數(shù)組織都不夠重視，導(dǎo)致這個(gè)工作直到交付系統(tǒng)時(shí)才真正被履行，這也就是為什么客戶拿到系統(tǒng)后才提出許多這樣那樣的需求變更，甚至認(rèn)為整個(gè)系統(tǒng)都不是他所需要的提高需求質(zhì)量的重要手段：

>需求評(píng)審

>需求確認(rèn)

>通過(guò)原型來(lái)驗(yàn)證需求需求工程組織與實(shí)作要點(diǎn)3.1需求工作要素與需求工程3.5需求過(guò)程與SERU模型3.4需求參與人員構(gòu)成分析3.3需求管理工作要點(diǎn)解析3.2需求開(kāi)發(fā)工作要點(diǎn)解析需求開(kāi)發(fā)與需求管理的分界需求基線管理為何需要：頻繁的需求變更會(huì)破壞開(kāi)發(fā)的節(jié)奏，使整個(gè)項(xiàng)目開(kāi)發(fā)的進(jìn)度陷入混亂和失控的狀態(tài)，而且會(huì)變成一個(gè)“救火隊(duì)”式的工作，整天都在處理突發(fā)事件主要思想：將所有現(xiàn)在的、將來(lái)的需求進(jìn)行優(yōu)先級(jí)評(píng)估，然后分解成為不同的組，每次迭代都選擇其中優(yōu)先級(jí)最高的部分進(jìn)行開(kāi)發(fā)，然后在迭

代完成之前，開(kāi)發(fā)工作不響應(yīng)變更，

這些劃入的需求項(xiàng)就是需求基線的組

成部分需求基線管理--操作思路我們應(yīng)該在分析的基礎(chǔ)上，將需求整合成為用例或功能項(xiàng)，然后對(duì)其進(jìn)行優(yōu)先級(jí)、依賴性進(jìn)行綜合性評(píng)估優(yōu)先級(jí)判斷：業(yè)務(wù)人員確定業(yè)務(wù)決定，技術(shù)人員確定技術(shù)決策；“滿意度/不滿意度”模型依賴性是指對(duì)于某些功能，在實(shí)現(xiàn)上有必須的依賴關(guān)系，即當(dāng)某些功能沒(méi)有實(shí)現(xiàn)時(shí)，另

外的功能無(wú)法開(kāi)始，這就需要對(duì)其

進(jìn)行調(diào)整需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避它，更不是說(shuō)要避免它，它實(shí)際上是希望控制變更在基線內(nèi)的需求不響應(yīng)變更，為開(kāi)發(fā)人員提供一個(gè)安靜的工作時(shí)間狀態(tài)專門(mén)的需求變更管理來(lái)對(duì)所有的需求變更進(jìn)行響應(yīng)，了解需求變更的關(guān)鍵意圖、新產(chǎn)生的工作量，從而良好地進(jìn)行重新計(jì)劃，以便能夠有效地解決其對(duì)整個(gè)開(kāi)發(fā)帶來(lái)的麻煩需求跟蹤需求的跟蹤是指對(duì)需求的完成情況、變更影響進(jìn)行系統(tǒng)化的跟蹤與處理“需求是不是已經(jīng)被實(shí)現(xiàn)？”、“需求的變化將需要修改哪些設(shè)計(jì)元素？會(huì)影響誰(shuí)的工作？對(duì)已經(jīng)完成的部分是否有影響？”需求工程組織與實(shí)作要點(diǎn)3.1需求工作要素與需求工程3.5需求過(guò)程與SERU模型3.4需求參與人員構(gòu)成分析3.3需求管理工作要點(diǎn)解析3.2需求開(kāi)發(fā)