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

1、軟件需求實(shí)作要點(diǎn)與誤區(qū)分析Agenda不同軟件項(xiàng)目的需求視圖軟件需求誤區(qū)與應(yīng)對之道需求工程組織與實(shí)作要點(diǎn)Agenda不同軟件項(xiàng)目的需求視圖軟件需求誤區(qū)與應(yīng)對之道需求工程組織與實(shí)作要點(diǎn)軟件需求誤區(qū)與應(yīng)對之道軟件需求誤區(qū)與應(yīng)對之道需求問題的癥狀 1癥狀：在軟件項(xiàng)目中，變更頻繁，而且集中出現(xiàn)在項(xiàng)目的中后階段。分析要點(diǎn)： 變更是對原需求的背離，還是補(bǔ)遺(需求不完整)? 背離發(fā)生在什么方面(流程間/流程內(nèi)/數(shù)據(jù)使用)？ 這些變更是需求階段是否可能預(yù)見的? 是否存在無效的變更響應(yīng)(管理有問題)?改進(jìn)方向： 變更的可預(yù)測性需求階段標(biāo)識(需求捕獲/分析) 變更渠道單一化、統(tǒng)一化(需求管理)需求問題的癥狀 2癥

2、狀：軟件項(xiàng)目上線運(yùn)行時遇到很多阻力。分析要點(diǎn)： 是否為組織因素? 阻力源于操作層還是管理層?改進(jìn)方向： 清晰的業(yè)務(wù)需求導(dǎo)向 (需求定義) 面向不同層面的需求分析 正確識別組織因素(需求捕獲)需求問題的癥狀 3癥狀：軟件項(xiàng)目上線運(yùn)行后效果很差。分析要點(diǎn)： 為什么不使用(用戶界面/功能/手工系統(tǒng))? 使用者的成本/效益分析?改進(jìn)方向： 抓準(zhǔn)業(yè)務(wù)需求(需求定義) 不同層面用戶的分析(需求捕獲/分析)需求問題的癥狀 4癥狀：產(chǎn)品二次開發(fā)量大。分析要點(diǎn)： 二次開發(fā)量最要集中于什么方面(業(yè)務(wù)規(guī)則/用戶界面/流程順序/流程細(xì)節(jié)/報表格式)?改進(jìn)方向： 工作流模型順序/細(xì)節(jié) 彈性設(shè)計業(yè)務(wù)規(guī)則/UI 報表格式理

3、解數(shù)據(jù)模型需求問題的癥狀 5癥狀：產(chǎn)品/項(xiàng)目完全不可用或崩潰。分析要點(diǎn)： 忽略了哪方面非功能需求?改進(jìn)方向： 性能與能力 操作環(huán)境 可靠性 軟件需求誤區(qū)與應(yīng)對之道需求:導(dǎo)致項(xiàng)目失敗的罪魁禍?zhǔn)赘鶕?jù)Standish Group對23000個項(xiàng)目進(jìn)行的研究結(jié)果表明，28%的項(xiàng)目徹底失敗，46%的項(xiàng)目超出經(jīng)費(fèi)預(yù)算或者超出工期，只有約26%的項(xiàng)目獲得成功。而在于這些高達(dá)74%的不成功項(xiàng)目中，有約60%的失敗是源于需求問題。也就是說，有近45%的項(xiàng)目最終因?yàn)樾枨蟮膯栴}最終導(dǎo)致失敗。對不知道航行目的地的人來說，沒有順風(fēng)！我們在哪里重重摔了一跤在Standish Group的報告中總結(jié)了導(dǎo)致項(xiàng)目失敗的最重要的

4、8大原因中，有5個與需求相關(guān)：不完整的需求(13.1%)；缺乏用戶的介入(12.4%)； 不實(shí)際的客戶期望(9.9%)；需求和規(guī)范的變更(8.7%)；提供了不再需要的(7.5%)缺乏資源(10.6%),沒有執(zhí)行層支持(9.3%),缺少規(guī)劃(8.1%)項(xiàng)目成功的因素用戶的參與：用戶的參與：15.9%管理層支持：13.9%清晰的需求描述清晰的需求描述(13.0%)；合適的規(guī)劃(9.6%)； 現(xiàn)實(shí)的客戶期望現(xiàn)實(shí)的客戶期望(8.2%)；較小的里程碑(7.7%)；有才能的員工(7.2%)軟件需求曾經(jīng)讓我們?nèi)绱死仟N-軟件需求誤區(qū)與應(yīng)對之道需求是什么?業(yè)務(wù)需求業(yè)務(wù)需求是指反映組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次

5、的目標(biāo)要求，通常問題定義本身就是業(yè)務(wù)需求 。背景描述：XX保險公司希望充分利用日益完善的移動通信技術(shù)，在原有的辦公系統(tǒng)的基礎(chǔ)上進(jìn)行擴(kuò)展，使得在外的業(yè)務(wù)人員能夠及時地獲得客戶、業(yè)務(wù)相關(guān)的動態(tài)信息，與此同時，實(shí)現(xiàn)企業(yè)內(nèi)部的即時通信。業(yè)務(wù)需求/目標(biāo) ：通過該系統(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)狀：功能分解盛行的今天，常常會犯“盲人摸象”的錯誤，這使得需求太過脆弱，難以經(jīng)受考驗(yàn)。目標(biāo)！目標(biāo)！還是目標(biāo)！-系統(tǒng)開發(fā)應(yīng)目標(biāo)驅(qū)動目標(biāo)驅(qū)動！目標(biāo)是團(tuán)隊(duì)唯一的行動綱領(lǐng)。目標(biāo)的定義不能夠流于形式，應(yīng)該具有以

6、下特征：業(yè)業(yè)務(wù)導(dǎo)向、可度量、合理、可行務(wù)導(dǎo)向、可度量、合理、可行。要注意目標(biāo)太夸大會浪費(fèi)資源，目標(biāo)太縮小會影響士氣。（教堂與小屋）目標(biāo)通常就是業(yè)務(wù)需求業(yè)務(wù)需求！用戶需求用戶需求是指描述用戶使用產(chǎn)品必須要完成什么任務(wù)，怎么完成的需求，通常是在問題定義的基礎(chǔ)上進(jìn)用戶訪談、調(diào)查，對用戶使用的場景進(jìn)行整理，從而建立從用戶角度的需求。 用戶有不同類型： 管理型、事務(wù)型 信息系統(tǒng)、人 決策層、使用層 常用者、偶用者組織方法：用例、用戶故事、特性例子：對快到期的客戶，系統(tǒng)將通過短信將續(xù)保信息發(fā)給該客戶的代理人軟件需求從系統(tǒng)實(shí)現(xiàn)的角度描述的需求。開發(fā)人員（設(shè)計及分析人員）在業(yè)務(wù)需求、用戶需求的基礎(chǔ)上生成的。有

7、時還需要考慮相關(guān)聯(lián)的硬件、環(huán)境方面的需求功能需求功能需求是需求的主體，是需求的本質(zhì)功能需求定義了：系統(tǒng)必須完成的那些事，即為了向它的用戶提供有用的功能，產(chǎn)品必須執(zhí)行的動作 零散（需求項(xiàng)）整理（特性、用例）敏捷方法：用戶故事質(zhì)量屬性產(chǎn)品必須具備的屬性或品質(zhì) 可靠性：成熟性、容錯性、易恢復(fù)性易使用性：易理解性、易學(xué)習(xí)性、易操作性效率：時間特性、資源特性可維護(hù)性：易分析性、易更改性、穩(wěn)定性、易測試性可移植性：適應(yīng)性、易安裝性、一致性、易替換性McCall體系：運(yùn)行(正確性、可靠性、效率、完整性、使用性)、修正(維護(hù)性、測試性、靈活性)、轉(zhuǎn)移(移植性、復(fù)用性、共運(yùn)行性)設(shè)計約束也稱為限制條件、補(bǔ)充規(guī)約

8、，這通常是對解決方案的一些約束說明。例如：必須采用國有自主知識版權(quán)的數(shù)據(jù)庫系統(tǒng)再如：必須運(yùn)行在UNIX操作系統(tǒng)之下三如：用戶將在戶外完成作業(yè)軟件需求誤區(qū)與應(yīng)對之道優(yōu)秀的需求完整性：完整描述即將交付使用的功能，發(fā)現(xiàn)缺少某項(xiàng)信息，可以采用TBD來標(biāo)注正確性：經(jīng)過用戶或用戶信任的代理人審閱無歧義：對所有讀者只有一種一致的解釋必要性：每項(xiàng)需求記錄的功能都應(yīng)是用戶真正需要的有優(yōu)先次序：提供了實(shí)現(xiàn)優(yōu)先級可行性：在已知能力和約束條件中實(shí)現(xiàn)可驗(yàn)證性：可以設(shè)計測試方法來檢查Agenda不同軟件項(xiàng)目的需求視圖軟件需求誤區(qū)與應(yīng)對之道需求工程組織與實(shí)作要點(diǎn)需求工程組織與實(shí)作要點(diǎn)需求工程組織與實(shí)作要點(diǎn)需求錯誤的代價需求

9、開發(fā)與管理需求工程組織與實(shí)作要點(diǎn)需求開發(fā)活動需求獲取應(yīng)收集什么信息： 問題域的描述-業(yè)務(wù)模型業(yè)務(wù)模型 要求解決的問題列表（需求需求） 用戶對解系統(tǒng)的行為或結(jié)構(gòu)施加的任何約束約束信息來源： 客戶（實(shí)際的和潛在的） 任何原有解系統(tǒng)（已有系統(tǒng)）及其文檔 原有系統(tǒng)用戶 / 新系統(tǒng)的潛在用戶 應(yīng)用（問題）領(lǐng)域?qū)＜?定義了任何接口系統(tǒng)的特片和行為的文檔 相關(guān)的技術(shù)標(biāo)準(zhǔn)和法規(guī)需求獲取技術(shù)閱讀背景資料閱讀背景資料頭腦風(fēng)暴頭腦風(fēng)暴討論分析討論分析文檔考古文檔考古面談（用戶訪談）面談（用戶訪談）聯(lián)合應(yīng)用設(shè)計聯(lián)合應(yīng)用設(shè)計用戶調(diào)查用戶調(diào)查需求剝離需求剝離現(xiàn)場觀摩現(xiàn)場觀摩任務(wù)觀察任務(wù)觀察用例和場景用例和場景需求獲取的誤

10、區(qū)缺乏計劃性：隨意、走過場，預(yù)先沒計劃缺乏科學(xué)性：未從本質(zhì)入手捕獲對象不明確，甚至造成岐義過于迷信現(xiàn)有文檔過于迷信“聽”到的東西需求分析所謂分析是指通過對問題域的研究，獲得對該領(lǐng)域特性及存在于其中（需要解決）的問題特性的透徹理解并用文檔說明分析方法：結(jié)構(gòu)化分析法、面向?qū)ο蠓治龇?、面向問題域分析法任何分析法，均需描述以下幾個方面: 問題域的結(jié)構(gòu) 問題子域的固有屬性及行為 問題域中的重要事件及現(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)了要存儲的信息數(shù)據(jù)字典：

11、對數(shù)據(jù)、數(shù)據(jù)流的描述對問題域問題域的研究力度不夠大分析和設(shè)計之間缺乏清晰的界限，將會導(dǎo)致不成熟的內(nèi)部設(shè)計需求分析-何時進(jìn)行應(yīng)該在“業(yè)務(wù)需求”充分理解，并且收集了最本質(zhì)的“用戶需求”之后就開始需求分析，但并不是等到需求捕獲完全做完之后 交替進(jìn)行，先把握用戶需求主要部分，然后在分析的基礎(chǔ)上引入系統(tǒng)級的需求（系統(tǒng)的設(shè)計與實(shí)現(xiàn)角度），并且分析模型，成為開發(fā)人員之間、開發(fā)人員與客戶之間達(dá)成共識的一個平臺分析的基礎(chǔ)上，就會發(fā)現(xiàn)更多的不明確項(xiàng)，更多待捕獲的信息，這時就可以生成第二次的需求調(diào)研的計劃、問題、素材 需求分析-何時結(jié)束需求捕獲、分析與建模、規(guī)格說明書的編寫、需求的驗(yàn)證這個需求開發(fā)的循環(huán)，是在整個軟

12、件開發(fā)生命周期中存在的 每一次的循環(huán)，都將在需求開發(fā)的工作要點(diǎn)與份量上有所不同，它們應(yīng)該遵循以下： 從本質(zhì)到邊緣：本質(zhì)、重要、次重要、一般、鑲金 細(xì)化階段是需求開發(fā)最密集的階段 構(gòu)建階段需求開發(fā)逐漸減少需求分析-內(nèi)容與形式需求分析與建模不應(yīng)該是孤立的行為 ，產(chǎn)生的結(jié)果也不一定非得是規(guī)范度很高的標(biāo)準(zhǔn)文檔，而應(yīng)該重在分析、重在方法、重在交流、重在解決問題 團(tuán)隊(duì)聚在一起，利用白板甚至是紙張，在充分的合作下進(jìn)行分析與初步建模是成本最低、效率最高、實(shí)用性最強(qiáng)的方法 對于這些活動所產(chǎn)生的結(jié)果，可以利用數(shù)碼相機(jī)、掃描儀進(jìn)行文檔化 ，“直到你一定要用時，再寫文檔” 對于比較重要、核心的內(nèi)容，再采用Rose、T

13、ogether這樣的工具進(jìn)行文檔化編寫規(guī)約規(guī)格說明書是對需求分析結(jié)果的文檔化過程比較“正規(guī)”的開發(fā)組織都會重視這個活動，甚至可以說是“重視過度”，而且產(chǎn)生出來的文檔經(jīng)常是與實(shí)際的開發(fā)脫離，完成之后就束之高閣，再也不使用、不更新。這是一個需求崩潰的信號 規(guī)格說明書的格式與所采用的開發(fā)過程、分析方法相關(guān)的，不同的方法格式不同定義統(tǒng)一的格式是一個很重要的工作規(guī)約內(nèi)容的嚴(yán)謹(jǐn)、正確、無岐義是很重要的需求驗(yàn)證這個工作大多數(shù)組織都不夠重視，導(dǎo)致這個工作直到交付系統(tǒng)時才真正被履行，這也就是為什么客戶拿到系統(tǒng)后才提出許多這樣那樣的需求變更，甚至認(rèn)為整個系統(tǒng)都不是他所需要的提高需求質(zhì)量的重要手段： 需求評審 需求

14、確認(rèn) 通過原型來驗(yàn)證需求需求工程組織與實(shí)作要點(diǎn)需求開發(fā)與需求管理的分界需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個項(xiàng)目開發(fā)的進(jìn)度陷入混亂和失控的狀態(tài)，而且會變成一個“救火隊(duì)”式的工作，整天都在處理突發(fā)事件主要思想：將所有現(xiàn)在的、將來的需求進(jìn)行優(yōu)先級評估，然后分解成為不同的組，每次迭代都選擇其中優(yōu)先級最高的部分進(jìn)行開發(fā)，然后在迭代完成之前，開發(fā)工作不響應(yīng)變更，這些劃入的需求項(xiàng)就是需求基線的組成部分 需求基線管理-操作思路我們應(yīng)該在分析的基礎(chǔ)上，將需求整合成為用例或功能項(xiàng)，然后對其進(jìn)行優(yōu)先級、依賴性進(jìn)行綜合性評估優(yōu)先級判斷：業(yè)務(wù)人員確定業(yè)務(wù)決定，技術(shù)人員確定技術(shù)決策；“滿意度/不滿

15、意度”模型依賴性是指對于某些功能，在實(shí)現(xiàn)上有必須的依賴關(guān)系，即當(dāng)某些功能沒有實(shí)現(xiàn)時，另外的功能無法開始，這就需要對其進(jìn)行調(diào)整需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避它，更不是說要避免它，它實(shí)際上是希望控制變更 在基線內(nèi)的需求不響應(yīng)變更，為開發(fā)人員提供一個安靜的工作時間狀態(tài) 專門的需求變更管理來對所有的需求變更進(jìn)行響應(yīng)，了解需求變更的關(guān)鍵意圖、新產(chǎn)生的工作量，從而良好地進(jìn)行重新計劃，以便能夠有效地解決其對整個開發(fā)帶來的麻煩 需求跟蹤需求的跟蹤是指對需求的完成情況、變更影響進(jìn)行系統(tǒng)化的跟蹤與處理“需求是不是已經(jīng)被實(shí)現(xiàn)？”、“需求的變化將需要修改哪些設(shè)計元素？會影響誰的工作？對已經(jīng)完成的部分是否有影響？” 需求工程組織與實(shí)作要點(diǎn)需求管理的參與者需求分析師需求分析員是對項(xiàng)目涉眾的需求進(jìn)行收集、分析、記錄和驗(yàn)證等職責(zé)的主要承擔(dān)者，是用戶群體與軟件開發(fā)團(tuán)隊(duì)間進(jìn)行需求溝通的主要渠道典型活動：定義業(yè)務(wù)需求、確定項(xiàng)目涉眾和用戶類別、獲取需求、分析需求、為需求建模、編寫需求規(guī)格說明、主持對需求的驗(yàn)證、引導(dǎo)對需求的優(yōu)先級劃分、管理需求必備技能：傾聽、交談和提問的技巧，分析、協(xié)調(diào)、觀察、寫作、組織、建模、人際交往和創(chuàng)造能力 需求分析師必備知識：現(xiàn)代需求管理技術(shù)、各種軟件開發(fā)生命周期、領(lǐng)域知識需求分析員的來源：用戶轉(zhuǎn)為分析員（軟件工程知識欠缺）、開發(fā)人員