需求分析師培訓-1

需求分析師培訓Day01Agenda信息系統(tǒng)根底理論需求的根本概念與原理需求工程需求定義最正確實踐需求捕獲最正確實踐Agenda信息系統(tǒng)根底理論需求的根本概念與原理需求工程需求定義最正確實踐需求捕獲最正確實踐1〕了解我們將涉及的領(lǐng)域！2〕從信息化的本質(zhì)理解需求信息與信息系統(tǒng)根本概念信息系統(tǒng)〔IS〕：是人、數(shù)據(jù)、過程和接口的組合，它們之間相互作用，支持并改進企業(yè)日常的運作，并支持管理人員和用戶解決問題和做出決策。數(shù)據(jù)信息信息系統(tǒng)信息系統(tǒng)的應(yīng)用信息與信息系統(tǒng)根本概念事務(wù)處理系統(tǒng)：收集和處理企業(yè)事務(wù)，事務(wù)的響應(yīng)時間、吞吐量、正確性、一致性等，BPR管理信息系統(tǒng)：提供面向管理報告的信息系統(tǒng)應(yīng)用決策支持系統(tǒng)：為用戶提供決策信息，基于數(shù)據(jù)倉庫專家系統(tǒng)：程序化的決策制定信息系統(tǒng)，人工智能(AI)辦公自動化和工作組系統(tǒng)：改進工作流和通信信息與信息系統(tǒng)根本概念事務(wù)處理系統(tǒng)(TPS)概述每個組織都有手工和自動化的TPS，用來處理有關(guān)組織的根本業(yè)務(wù)記錄更新所需的詳細數(shù)據(jù)處理系統(tǒng)包括：訂單錄入、存貨控制、工資單、應(yīng)付帳款、應(yīng)收帳款、總分類帳處理處理包括：數(shù)據(jù)收集、數(shù)據(jù)編輯、數(shù)據(jù)修改、數(shù)據(jù)操作、數(shù)據(jù)存儲和文檔生成事務(wù)：根本業(yè)務(wù)活動，如顧客訂單、購貨訂單、時間卡和工資支票處理事務(wù)處理系統(tǒng)特性能夠迅速有效地處理大量數(shù)據(jù)的輸入和輸出能夠進行嚴格的數(shù)據(jù)編輯，以保證記錄的正確性和時效性通過審計以保證所有輸入數(shù)據(jù)、處理、程序和輸出是完整、準確和有效的提供了有關(guān)平安問題的防護能力支持許多人進行處理，因此系統(tǒng)的故障會對組織有嚴重和致命的影響事務(wù)處理系統(tǒng)的簡單縱覽事務(wù)處理方法批處理系統(tǒng)：將一段時間內(nèi)的一批事務(wù)一次性處理的系統(tǒng)聯(lián)機事務(wù)系統(tǒng)：該方法中每個事務(wù)即時進行處理，而不累積成批處理延遲的聯(lián)機錄入：前兩者的折衷事務(wù)處理系統(tǒng)的目標處理由事務(wù)產(chǎn)生的及與事務(wù)相關(guān)的數(shù)據(jù)保持高準確度：輸入和處理無錯數(shù)據(jù)保證數(shù)據(jù)和信息的完整性及時生成文檔和報告提高勞動效率有助于改善效勞事務(wù)處理系統(tǒng)—總結(jié)一個組織的TPS必須支持業(yè)務(wù)正常工作過程中發(fā)生的常規(guī)的日常活動，這有助于公司對產(chǎn)品和效勞增值數(shù)據(jù)應(yīng)該在源處獲得，以減少人工勞動，并且能準確、及時地記錄送入計算機的方式事務(wù)處理的業(yè)務(wù)數(shù)據(jù)包括數(shù)據(jù)收集、數(shù)據(jù)編輯、數(shù)據(jù)修改、數(shù)據(jù)操作、數(shù)據(jù)存儲和文檔生成將一個公司的事務(wù)處理系統(tǒng)與其他公司連接起來是降低本錢、加快信息流動的有效策略—例如SCM管理信息系統(tǒng)概述管理信息系統(tǒng)的主要目標是幫助管理者了解日常的業(yè)務(wù)以便進行既有效又高效的控制、組織、方案，最后到達組織的目標。--向管理者提供信息多數(shù)是通過不同的匯總分析報表來實現(xiàn)功能的；這些報表篩選、分析事務(wù)處理數(shù)據(jù)庫中高度細化的數(shù)據(jù)，然后用一種有意義的方式將結(jié)果送給管理者在恰當?shù)臅r機以恰當?shù)姆绞较蚯‘數(shù)膶ο筇峤徽_的信息，以改進工作效率管理信息系統(tǒng)特點制作進度、需求、異常、常規(guī)四類報表，有助于管理執(zhí)行人員即時作出高質(zhì)量決策報表具有固定和標準的格式生成硬拷貝和軟拷貝報表使用存儲在計算機系統(tǒng)內(nèi)的內(nèi)部數(shù)據(jù)報表由包括系統(tǒng)分析員和計算機程序員在內(nèi)的信息系統(tǒng)人員開發(fā)和實施需要用戶提交正式需求管理信息系統(tǒng)—四類報表進度報表：周期生成或按日程生成，如日、周、月報關(guān)鍵指標報表是一種特殊類型的進度表，匯總前一日關(guān)鍵活動。需求報表：按管理者的要求提供相應(yīng)的信息；如產(chǎn)品銷售形勢報表異常報表：當情況出現(xiàn)異常，需管理者加以注意而由系統(tǒng)自動生成的報表；如預(yù)算超支的工程列表常規(guī)報表：就某一情況為管理者提供更為詳盡的數(shù)據(jù)管理信息系統(tǒng)—報表開發(fā)原那么按用戶要求定制每份報表：要求用戶參與和輸入時間與精力應(yīng)只用于要使用的報表：一旦建立，即使沒人使用，許多報表仍會一直不斷生成注意報表的內(nèi)容和格式：突出顯示最為重要的信息，字詞和術(shù)語力求清晰易懂利用例外報告實施管理：某些報告只應(yīng)出現(xiàn)亟待解決問題或需要采取某動作時生成審核設(shè)定參數(shù)：如參數(shù)過低結(jié)果是報告過多，如參數(shù)過高那么忽略有價值信息確保報告的時效：過期的報告無價值或價值極小管理信息系統(tǒng)小結(jié)MIS必須在恰當?shù)臅r間以恰當?shù)姆绞较蚯‘數(shù)娜颂峁┣‘數(shù)男畔⒔M織的MIS的最重要的內(nèi)部信息來源是事務(wù)處理系統(tǒng)在大多數(shù)的情況下，公司最了解如何得到數(shù)據(jù)以及何時以何種形式向哪一位管理者提交報表可以為公司帶來最大的利益不同信息系統(tǒng)的集成使數(shù)據(jù)和信息可以更簡單地共享，從而降低公司的本錢，提高報表的精確度、數(shù)據(jù)更平安，公司到達更高的效率決策支持系統(tǒng)根本概念決策是問題解答的一個組成局部決策階段是問題解答的處理階段，其包括情報、設(shè)計和選擇三個時期。情報時期：認識和確定潛在的困難和(或者)時機設(shè)計時期：確定問題解答的可選擇的方案選擇時期：要求選擇一種行動方案問題解答除了決策階段外還包括實施時期和監(jiān)控時期實施時期：確定的行動方案開始生效監(jiān)控時期：決策者們評估問題解答方案實施效果決策支持系統(tǒng)根本概念程序化決策：使用一種規(guī)那么、過程或量化方法所做的決策。例如：存貨下降到一百單位時應(yīng)該定貨。--系統(tǒng)要素之間的關(guān)系通過規(guī)律、過程和數(shù)值關(guān)系的方式固定下來，通?？梢酝ㄟ^MIS實現(xiàn)非程序化決策：處理不常見和異常的情況，很難量化。例如為雇員確定適宜的培訓方案、決定是否新建一條生產(chǎn)線。--決策支持系統(tǒng)將解決的問題最優(yōu)化模型：找到最好解決方案的決策支持方法滿意性模型：找出一個好的(但未必是最好)解決方案啟發(fā)式方式：認為能找到一個較好解決方案的指導(dǎo)或過程決策支持系統(tǒng)的作用與特點用于支持專門問題決策的人力、過程、軟件、數(shù)據(jù)庫和設(shè)備的一個有組織的集合。用來解決非結(jié)構(gòu)化或半結(jié)構(gòu)化企業(yè)問題的決策。將處理不同來源的大量數(shù)據(jù)提供靈活的報告和展示以文本和圖表格式提供信息支持深入的分析使用先進的軟件包，完成錯綜復(fù)雜的分析和比較支持最優(yōu)化的、滿意性和啟發(fā)式的方法執(zhí)行What-if，模擬和目標求解分析決策支持系統(tǒng)的組成DSS的核心是數(shù)據(jù)庫和模型庫，還包括對話管理器(提供更友好的人機界面)模型庫：財務(wù)模型、統(tǒng)計分析模型、圖表模型、工程管理模型……專家系統(tǒng)簡介專家系統(tǒng)可以像某個特定領(lǐng)域的人類專家一樣行動用來輔助設(shè)計新產(chǎn)品或新系統(tǒng)、決定木材的最正確使用、提高醫(yī)療衛(wèi)生的質(zhì)量、決定信用卡的信貸額度它能對它們的推理或提議的決策作出解釋能顯示“智能〞行為能從復(fù)雜的關(guān)系間得出結(jié)論能提供“可移動〞的知識能處理不確定性不同視角下的信息系統(tǒng)主流信息應(yīng)用系統(tǒng)MRPMRPIIERP：制造業(yè)，本錢、生產(chǎn)流程CRM：客戶關(guān)系管理SCM：供給鏈管理BI：商業(yè)智能OA：辦公自動化E-Commerce：電子商務(wù)……信息應(yīng)用系統(tǒng)分類內(nèi)部：OA、MIS、BI、KM外部：CRM、E-Commerce、WebPortal協(xié)作：SCM、GroupWare、AssistantTools信息系統(tǒng)需求的本質(zhì)流程電子化

>利用信息化系統(tǒng)改進、固化流程

>事務(wù)處理系統(tǒng)尤其明顯

>工作流定義、流程改進、再造

>工作流模型數(shù)據(jù)信息化

>業(yè)務(wù)術(shù)語，業(yè)務(wù)實體

>需要留存哪些數(shù)據(jù)？誰需要共享？

>需要什么報表？有哪些數(shù)據(jù)分析規(guī)那么？信息系統(tǒng)常見技術(shù)計算模式：B/S、C/S主要開發(fā)體系：.NET、J2EE、LAMP、RailonRuby重要思想：SOA、WebService、工作流引擎開發(fā)方法論：重方法論〔RUP〕、敏捷方法論建模技術(shù)：UML、E-R模型Agenda信息系統(tǒng)根底理論需求的根本概念與原理需求工程需求定義最正確實踐需求捕獲最正確實踐1〕理論是實踐的根底2〕解決概念性的誤區(qū)討論你認為“什么是需求〞？日常工作中，遇到與“需求〞相關(guān)的問題有哪些？關(guān)于“需求〞最大的困惑是什么？以下問題中，對你影響最大的是哪個？

>不切實際的用戶需求

>很多需求最終是不需要的

>用戶介入太少

>需求不完整

>需求變更頻繁需求—導(dǎo)致工程失敗的罪魁禍首根據(jù)StandishGroup對23000個工程進行的研究結(jié)果說明，28%的工程徹底失敗，46%的工程超出經(jīng)費預(yù)算或者超出工期，只有約26%的工程獲得成功。而在于這些高達74%的不成功工程中，有約60%的失敗是源于需求問題。也就是說，有近45%的工程最終因為需求的問題最終導(dǎo)致失敗。對不知道航行目的地的人來說，沒有順風！我們在哪里重重摔了一跤在StandishGroup的報告中總結(jié)了導(dǎo)致工程失敗的最重要的8大原因中，有5個與需求相關(guān)：不完整的需求(13.1%)；缺乏用戶的介入(12.4%)；不實際的客戶期望(9.9%)；需求和標準的變更(8.7%)；提供了不再需要的(7.5%)

缺乏資源(10.6%),沒有執(zhí)行層支持(9.3%),缺少規(guī)劃(8.1%)工程成功的因素用戶的參與：15.9%管理層支持：13.9%清晰的需求描述(13.0%)；適宜的規(guī)劃(9.6%)；現(xiàn)實的客戶期望(8.2%)；較小的里程碑(7.7%)；有才能的員工(7.2%)軟件需求曾經(jīng)讓我們?nèi)绱死仟N參與各方都以自已角度講述問題分布式WebServices三層

對話框菜單條DCOM

B/S數(shù)據(jù)交換……財務(wù)計算管理報表工作流自動庫存控制庫存報警

業(yè)務(wù)線索管理業(yè)務(wù)經(jīng)線索跟蹤

銷售月報生成交易流數(shù)據(jù)問題的根源是什么？用戶說的不是他想的：客戶提供〔陳述的需求〕的需求并不是真實的需求，還需要作進一步的分析，以確定客戶的真正需求和期望，接下來需要澄清并重新描述?？梢赃@么說客戶在理解根底業(yè)務(wù)過程和描述自己的需求方面有很大的差異。需求分析方法有問題：系統(tǒng)開發(fā)人員

使用低效的需求分析和工程管理方法。共同責任強調(diào)缺乏：對客戶和提供商

在工程成功的共同責任方面強調(diào)不夠。優(yōu)秀的團隊遇到糟糕的需求用戶參與缺乏用戶需求擴展有歧義的需求鍍金問題過于抽象的需求忽略某種用戶不準確的方案……我們應(yīng)該怎么辦？對“需求〞建立正確的認識；客戶和供給商—一根繩子上的兩個螞蚱；和客戶一起建立起“共同的目標〞；尋找并使用正確的、有效的需求捕獲、描述〔建?！场⒐芾矸椒?；動態(tài)、持續(xù)地適應(yīng)需求的變化；需求是什么？業(yè)務(wù)需求業(yè)務(wù)需求是指反映組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，通常問題定義本身就是業(yè)務(wù)需求。背景描述：XX保險公司希望充分利用日益完善的移動通信技術(shù)，在原有的辦公系統(tǒng)的根底上進行擴展，使得在外的業(yè)務(wù)人員能夠及時地獲得客戶、業(yè)務(wù)相關(guān)的動態(tài)信息，與此同時，實現(xiàn)企業(yè)內(nèi)部的即時通信。業(yè)務(wù)需求/目標：通過該系統(tǒng)的實施，將人

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

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

大幅改善，以幫助企業(yè)運轉(zhuǎn)效率得以提高。業(yè)務(wù)目標例如某船廠商業(yè)管理系統(tǒng)目標：A1.取代過時的系統(tǒng)A2.集成訂單文檔及數(shù)據(jù)庫A3.使用經(jīng)驗數(shù)據(jù)進行報價

A4.支持系統(tǒng)化的銷售

A5.快速捕獲本錢數(shù)據(jù)

A6.加快發(fā)票的制作某醫(yī)院管理系統(tǒng)目標：B1.降低IT本錢人事部門：B2.實現(xiàn)一些任務(wù)的自動化B3.消除出錯源B4.遵守最后期限

B5.減少繁瑣工作

醫(yī)院部門：B6.減少加班及工作量缺乏的情況

B7.更快速的勤務(wù)規(guī)劃

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

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

太縮小會影響士氣?！步烫门c小屋〕目標通常就是業(yè)務(wù)需求！業(yè)務(wù)需求就是定義系統(tǒng)目標目標在哪里？業(yè)務(wù)需求是構(gòu)建在“工程發(fā)起人〞的腦子里的，也就是誰提出工程，誰就擁有對“業(yè)務(wù)需求〞的最清晰的理解。引出宏觀的目標：思考企業(yè)運作中存在什么問題？這些問題主要是表達在哪些方面？這些問題對企業(yè)造成了什么影響？認為可以怎么解決？希望到達什么樣的效果？將大任務(wù)分解成為小目標，并且引導(dǎo)客戶良好地定義，這也是我們形成“工程子目標描述〞的關(guān)鍵根底。衡量這些目標的合理性與可行性。業(yè)務(wù)需求就是定義系統(tǒng)目標形成一個不超過50字的工程目標，并且列出5-9個主要子目標，并且將其制作成一頁文檔，作為“工程的行動綱領(lǐng)〞，還應(yīng)該得到“工程發(fā)起人〞的認可。在此根底上，可以編寫“工程的目標和范圍文檔〞(或稱工程綜述，即POS，內(nèi)容包括問題/時機、工程目標、工程目的、成功標準、假設(shè)/風險/障礙)，對于產(chǎn)品而言，我們還可以構(gòu)建一個從市場角度分析的“愿景〞文檔。該局部工作是處于“需求過程〞的金字塔尖，多花費一些時間和精力是值得的，也是必要的。業(yè)務(wù)需求就是定義系統(tǒng)目標有了清晰的目標之

后，還應(yīng)該對系統(tǒng)

劃定范圍，最常用

的方法是工作上下

文范圍圖〔結(jié)構(gòu)化

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

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

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

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

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

靈活性)、轉(zhuǎn)移(移植性、復(fù)用性、共運行性)設(shè)計約束也稱為限制條件、補充規(guī)約，這通常是對解決方案的一些約束說明。例如：必須采用國有自主知識版權(quán)的數(shù)據(jù)庫系統(tǒng)…再如：必須運行在UNIX操作系統(tǒng)之下兩個世界三種設(shè)計優(yōu)秀的需求完整性：完整描述即將交付使用的功能，發(fā)現(xiàn)缺少某項信息，可以采用TBD來標注正確性：經(jīng)過用戶或用戶信任的代理人審閱可行性：在能力和約束條件中實現(xiàn)必要性：每項需求記錄的功能都應(yīng)是用戶真正需要的有優(yōu)先次序：提供了實現(xiàn)優(yōu)先級無歧義：對所有讀者只有一種一致的解釋可驗證性：可以設(shè)計測試方法來檢查檢查表例如討論前面的描述中，最大的感觸是什么？業(yè)務(wù)需求需求定義用戶需求需求捕獲軟件需求需求分析與編寫規(guī)約Agenda信息系統(tǒng)根底理論需求的根本概念與原理需求工程需求定義最正確實踐需求捕獲最正確實踐1〕掌握需求的相關(guān)工作2〕了解需求的相關(guān)人員需求錯誤的代價需求：1設(shè)計：5編碼：10測試：20-50運行與維護：200需求開發(fā)與管理需求開發(fā)活動需求獲取應(yīng)收集什么信息：

>問題域的描述

>要求解決的問題列表〔需求〕

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

>客戶〔實際的和潛在的〕

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

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

>應(yīng)用〔問題〕領(lǐng)域?qū)＜?/p>

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

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

>問題域的結(jié)構(gòu)〔子域，及子域間關(guān)系〕

>問題域的數(shù)據(jù)

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

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

>需求：應(yīng)產(chǎn)生的效果需求分析方法—結(jié)構(gòu)化分析從基于文本分析和規(guī)格文檔圖形建模表示法結(jié)構(gòu)化分析初期的模型：數(shù)據(jù)流圖+E-R圖數(shù)據(jù)流圖：表達了流程，但是以數(shù)據(jù)為中心的流程E-R圖：表達了要存儲的信息數(shù)據(jù)字典：對數(shù)據(jù)、數(shù)據(jù)流的描述需求分析方法—結(jié)構(gòu)化分析對問題域的研究力度不夠大分析和設(shè)計之間缺乏清晰的界限，將會導(dǎo)致不成熟的內(nèi)部設(shè)計沒有一個真正的功能規(guī)格說明需求實質(zhì)上是根據(jù)滿足該需求的某一特定系統(tǒng)的內(nèi)部設(shè)計來加以說明的內(nèi)部設(shè)計的開發(fā)使用的那么是不可靠的內(nèi)部設(shè)計技術(shù)，即功能分解SA不適用于某些類型〔絕非少數(shù)〕的應(yīng)用需求分析方法—面向?qū)ο蠓治雠c開發(fā)方法最為接近的分析方法主要模型：

>用例模型：系統(tǒng)的功能，場景化分析

>類模型：對象、數(shù)據(jù)

>活動圖、狀態(tài)圖用例驅(qū)動的需求實踐最正確實踐需求分析方法—面向問題域分析是一種新的、返璞歸真，較少強調(diào)建模搜集根本的信息并開發(fā)問題框架，以建立問題域的類型；在問題框架類型的指導(dǎo)下，進一步搜集詳細信息并給出一個問題域相關(guān)特性的描述。需求分析—何時進行應(yīng)該在“業(yè)務(wù)需求〞充分理解，并且收集了最本質(zhì)的“用戶需求〞之后就開始需求分析，但并不是等到需求捕獲完全做完之后交替進行，先把握用戶需求主要局部，然后在分析的根底上引入系統(tǒng)級的需求〔系統(tǒng)的設(shè)計與實現(xiàn)角度〕，并且分析模型，成為開發(fā)人員之間、開發(fā)人員與客戶之間達成共識的一個平臺分析的根底上，就會發(fā)現(xiàn)更多的不明確項，

更多待捕獲的信息，這時就可以生成第二次

的需求調(diào)研的方案、問題、素材需求分析—何時結(jié)束需求捕獲、分析與建模、規(guī)格說明書的編寫、需求的驗證這個需求開發(fā)的循環(huán)，是在整個軟件開發(fā)生命周期中存在的每一次的循環(huán)，都將在需求開發(fā)的工作要點與份量上有所不同，它們應(yīng)該遵循以下：

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

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

>構(gòu)建階段需求開發(fā)逐漸減少需求分析—內(nèi)容與形式需求分析與建模不應(yīng)該是孤立的行為，產(chǎn)生的結(jié)果也不一定非得是標準度很高的標準文檔，而應(yīng)該重在分析、重在方法、重在交流、重在解決問題團隊聚在一起，利用白板甚至是紙張，在充分的合作下進行分析與初步建模是本錢最低、效率最高、實用性最強的方法對于這些活動所產(chǎn)生的結(jié)果，可以利用數(shù)碼相機、掃描儀進行文檔化，“直到你一定要用時，再寫文檔〞對于比較重要、核心的內(nèi)容，再采用Rose、

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

>需求評審

>需求確認

>通過原型來驗證需求需求開發(fā)與需求管理的分界需求基線管理頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個工程開發(fā)的進度陷入混亂和失控的狀態(tài)，而且會變成一個“救火隊〞式的工作，整天都在處理突發(fā)事件將所有現(xiàn)在的、將來的需求進行優(yōu)先級評估，然后分解成為不同的組，每次迭代都選擇其中優(yōu)先級最高的局部進行開發(fā)，然后在迭代完成之前，開發(fā)工作不響應(yīng)變更，這些劃入的需求項就是需求基線的組成局部需求基線管理—操作思路我們應(yīng)該在分析的根底上，將需求整合成為用例或功能項，然后對其進行優(yōu)先級、依賴性進行綜合性評估優(yōu)先級判斷：業(yè)務(wù)人員確定業(yè)務(wù)決定，技術(shù)人員確定技術(shù)決策；“滿意度/不滿意度〞模型依賴性是指對于某些功能，在實現(xiàn)上有必須的依賴關(guān)系，即當某些功能沒有實現(xiàn)時，另外的功能無法開始，這就需要對其進行調(diào)整需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避它，更不是說要防止它，它實際上是希望控制變更在基線內(nèi)的需求不響應(yīng)變更，為開發(fā)人員提供一個安靜的工作時間狀態(tài)專門的需求變更管理來對所有的需求變更進行響應(yīng)，了解需求變更的關(guān)鍵意圖、新產(chǎn)生的工作量，從而良好地進行重新方案，以便能夠有效地解決其對整個開發(fā)帶來的麻煩需求變更管理—變更的流程提出變更：正式的方式提交變更是很重要的，合約式的溝通平臺變更評估：合理性評估，進一步了解其變更的主要原因，認清其是否是因為溝通上的誤會與不理解而造成的不必要的變更；工作量評估那么是評估其對進度的影響；影響面分析那么是評估該變更會對哪些局部工作產(chǎn)生影響，具體地說會對哪些人的工作產(chǎn)生影響分級響應(yīng)評估：不影響相關(guān)模塊開發(fā)進度的，可直接響應(yīng)；影響本模塊開發(fā)進度但不影響工程總體進度的，可由工程經(jīng)理協(xié)調(diào)后直接響應(yīng)；影響工程進度的，那么應(yīng)該交與客戶協(xié)商響應(yīng)方式需求跟蹤需求的跟蹤是指對需求的完成情況、變更影響進行系統(tǒng)化的跟蹤與處理“需求是不是已經(jīng)被實現(xiàn)？〞、“需求的變化將需要修改哪些設(shè)計元素？會影響誰的工作？對已經(jīng)完成的局部是否有影響？〞需求管理的參與者需求分析師需求分析員是對工程涉眾的需求進行收集、分析、記錄和驗證等職責的主要承擔者，是用戶群體與軟件開發(fā)團隊間進行需求溝通的主要渠道典型活動：定義業(yè)務(wù)需求、確定工程涉眾和用戶類別、獲取需求、分析需求、為需求建模、編寫需求規(guī)格說明、主持對需求的驗證、引導(dǎo)對需求的優(yōu)先級劃分、管理需求必備技能：傾聽、交談和提問的技巧，分析、

協(xié)調(diào)、觀察、寫作、組織、建模、人際交

往和創(chuàng)造能力需求分析師必備知識：現(xiàn)代需求管理技術(shù)、各種軟件開發(fā)生命周期、領(lǐng)域知識需求分析員的來源：用戶轉(zhuǎn)為分析員〔軟件工程知識欠缺〕、開發(fā)人員轉(zhuǎn)為分析員〔領(lǐng)域知識、溝通能力〕、主題專家〔易按自己的偏好來構(gòu)建系統(tǒng)〕需求過程需求過程Agenda信息系統(tǒng)根底理論需求的根本概念與原理需求工程需求定義最正確實踐需求捕獲最正確實踐對問題進行了正確的定義意味著成功解決了問題的一半討論你認為需求定義的目標是什么？通常需求定義在什么階段進行？其主要的產(chǎn)物是什么？信息系統(tǒng)立項前的分析方法GPOA方法：GoalProblemOptionAnswer信息系統(tǒng)立項前的分析方法G〔目標〕：要確定需要開發(fā)某個信息系統(tǒng)之前，應(yīng)該分析其應(yīng)該到達的目標：業(yè)務(wù)性、可度量P〔問題〕：要到達該目標所需解決的問題！O〔選項〕：針對這些問題可選的解決方案A〔答案〕：針對各種Option進行分析、評估，最終確定答案。信息系統(tǒng)立項可行性分析確定目標：信息系統(tǒng)實現(xiàn)前，信息系統(tǒng)實現(xiàn)后提出解決方案：分析P，給出O，得出A可行性分析：

>效益分析：經(jīng)濟可行性，投資回報

>社會可行性

>技術(shù)可行性信息系統(tǒng)立項時的常見誤區(qū)目標：含混不清，過為宏觀

Solution:基于業(yè)務(wù)需求思考解決方案：思路過于受限

Solutions:>只想What，別想How

>了解、理解IT技術(shù)期望值：脫離現(xiàn)實發(fā)起人、用戶、使用者想法不一致

框定問題的技巧問題的定義是需求工作的第一步，也是最重要的一步。問題是否能夠解決，通常與是否能夠更好、更準確地框定問題相關(guān)。例如，經(jīng)典的馬的遍歷問題：

尋找一系列的移動步驟，使

馬走完每個方塊，而落入任

何一個方塊一次：框定問題的技巧框定問題的技巧軟件需求第一和可能最重要的步驟是框定問題—把問題的特定局部，以及局部間特定的關(guān)系，放入一個特定的形式中。問題框定方法應(yīng)使問題的細節(jié)適合一個簡單連貫的框架同時，這也表現(xiàn)出，深入地理解問題域的知識，正確地抓住其本質(zhì)特性，是十分重要的。〔你的燈還亮著嗎？〕框定問題的技巧問題：日內(nèi)瓦湖上的山脈中建成了一條很長的汽車隧道，為了防止停電時發(fā)生災(zāi)難，必須提醒司機進入隧道之前把車燈翻開。解決方案一：“警告！前有隧道請翻開車頭燈〞新問題：隧道出口風景很美，返回時發(fā)現(xiàn)汽車沒電—忘了關(guān)車頭燈?。〗鉀Q方案二：出口處立標牌“關(guān)掉車燈〞新問題：夜行車也會關(guān)掉車燈？解決方案三：建充電站新問題：維護開支大，充電站也會出故障框定問題的技巧解決方案四：授權(quán)私人經(jīng)營充電站新問題：風景區(qū)商業(yè)化，政府與游客均不接受解決方案五：在隧道盡頭，樹立新標牌

如果是白天，并且車燈開著，請熄滅車燈；

如果天色已晚，并且車燈沒開，請翻開車燈；

如果是白天，并且車燈沒打，就別翻開它；

如果天色已晚，并且車燈開著，請別關(guān)掉它。新問題：誰能在行駛時讀完？！終極解決方案：你的燈亮著嗎？問題分析的五個步驟問題分析：理解真實世界中的問題和用戶的需求并提出滿足這些多方面要的解決方案的過程①在問題定義上達成共識②理解根本原因—問題背后的問題③確定風險承擔人和用戶④定義解決方案系統(tǒng)的界限⑤確定加在解決方案上的約束在問題定義上達成共識把問題寫下來，看每個人是否都同意采用標準化格式：

>問題：描述問題

>影響：確定受問題影響的風險承擔人

>結(jié)果：確定問題對風險承擔人和商業(yè)活動的影響

>優(yōu)點：指出解決方案并列出主要優(yōu)點理解原因后對問題的陳述問題：不準確的訂單影響：訂單操作者、客戶、生產(chǎn)者、銷售者及客服結(jié)果：增加廢品、額外處理本錢、客戶不滿及收益降低成功的解決方法：

>增加了輸入點訂單的準確性

>增加了銷售數(shù)據(jù)的報告以便進行管理

>獲得更好的效率理解原因后對問題的陳述問題：隨時提供大學體育賽事的最新報道影響：移動辦公的人群結(jié)果：他們不可能花很多時間來搜索他們感興趣的新聞，因此無法隨時了解到有關(guān)他們母校的賽事〔或者他們感興趣的其他大學的體育賽事〕。成功的解決方法：當發(fā)生他們感興趣的新聞時，向他們發(fā)出通知，并提供一個地點來為他們提供所請求的新聞。理解根本原因—問題背后的問題TQM的魚骨圖帕雷托圖確定涉眾和用戶系統(tǒng)的用戶是誰？系統(tǒng)的客戶是誰？還有哪些人會受系統(tǒng)輸出的影響？系統(tǒng)完成并投入使用后，有誰會對它進行評估？還有沒有其他系統(tǒng)內(nèi)部或外部用戶，他們的需要有沒有必要被考慮到？系統(tǒng)將來由誰維護？還有其他人嗎？用洋蔥圖來尋找涉眾定義解決方案系統(tǒng)的界限誰會對系統(tǒng)提供信息？誰會在系統(tǒng)中使用信息？誰會從系統(tǒng)中刪除信息？誰將操作該系統(tǒng)？誰是系統(tǒng)的維護者？系統(tǒng)將會在哪兒被使用？系統(tǒng)從哪兒得到信息？哪些外部系統(tǒng)要

和系統(tǒng)進行交互？定義解決方案系統(tǒng)的界限不好！大局部工

作都留給操作員了常見劃分，但

可以更好訂單接收自動化顧客缺貨前提醒上下文范圍圖例如上下文范圍圖例如確定加在解決方案上的約束經(jīng)濟約束：預(yù)算？行政約束：存在許可問題？潛在內(nèi)外部政問題？部門間問題？技術(shù)約束：技術(shù)選擇有何限制？限制在已有平臺或技術(shù)上？禁止使用新技術(shù)？需要購置軟件包？系統(tǒng)約束：建立在現(xiàn)有系統(tǒng)上？需要維護與原系統(tǒng)的兼容性？必須支付什么操作系統(tǒng)？環(huán)境約束：合法嗎？平安性要求？其他標準限制？進度及資源：進度要求？已有資源？外部勞動力可用否？有無擴展資源？確定加在解決方案上的約束操作性：銷售訂單數(shù)據(jù)必須在數(shù)據(jù)庫中備份一年，因為數(shù)據(jù)喪失風險太大，需并行運行至少一年的數(shù)據(jù)系統(tǒng)及操作系統(tǒng)：應(yīng)用在效勞器上占用不超過200M，因為效勞器上存儲空間有限設(shè)備預(yù)算：必須在已有效勞器和主機上開發(fā)人員預(yù)算：固定的人力資源，沒有外部資源技術(shù)要求：應(yīng)用新的面向?qū)ο蟮姆椒üこ潭x—業(yè)務(wù)需求產(chǎn)品/工程的目的：對業(yè)務(wù)目標的簡短、可度量的描述客戶：為誰構(gòu)建？顧客：誰會購置？風險承擔者：哪些人在產(chǎn)品中擁有既得利益？用戶：誰將操作它？他們的能力如何？限制條件：必須采用某設(shè)計方案？時間？經(jīng)費？名稱：該工程使用哪些術(shù)語？相關(guān)事實和假定：每個人都需要知道什么？工作的范圍：什么是產(chǎn)品和工程的邊界？估算的費用：需要花費多少工作量或資金風險：面臨的主要風險工程定義—目標的六要素目標：精確預(yù)報道路結(jié)冰時間并分派除冰卡車業(yè)務(wù)優(yōu)勢：通過預(yù)報道路結(jié)冰情況來減少道路事故度量：因結(jié)冰而發(fā)生的事故數(shù)年將低于冬季發(fā)生的事故總數(shù)的15%合理性：消除因結(jié)冰而發(fā)生的事故而減少的損失，與構(gòu)建該系統(tǒng)所花費的本錢和工作量相比，是否有價值？可行性：及時地除冰能否減少事故的發(fā)生？會降到總數(shù)的15%以下嗎？可達成性：該目標能到達嗎？工程定義—風險承擔人與用戶用戶：與主題相關(guān)的經(jīng)驗、技術(shù)上的經(jīng)驗、智力能力、對工作的態(tài)度、對技術(shù)的態(tài)度、受教育程度、語言技能、年齡、性別風險承擔者：用戶、客戶、顧客、管理者、業(yè)務(wù)主題相關(guān)者、開發(fā)人員、檢查人員、市場力量、法律方面、反對者、專業(yè)團體、公眾意見、政府、特殊利益團隊、技術(shù)專家、文化利益、相鄰系統(tǒng)〔Stakeholder解析〕工程定義文檔—前景文檔業(yè)務(wù)需求

>背景：新產(chǎn)品的來由與背景

>業(yè)務(wù)機遇

>業(yè)務(wù)目標與成功標準

>客戶與市場需求

>業(yè)務(wù)風險解決方案的前景

>前景說明(目標客戶、需求與時機、競爭對手與優(yōu)勢)

>主要特性

>假設(shè)與依賴工程定義文檔—前景文檔范圍與限制

>第一個版本的范圍

>各后續(xù)版本的范圍

>限制與排除業(yè)務(wù)背景

>涉眾簡介

>工程優(yōu)先級

>操作環(huán)境前景文檔模板例如一例如二愿景陳述—ABC航空ABC航空通過提高對旅行效勞的深入，以及提供其競爭對手無法提供的創(chuàng)新效勞，來維護自己的形象。具體手段包括：通過創(chuàng)立一個公共網(wǎng)站，提高ABC航空的品牌知名度通過讓30%的客戶在線訂票，將市場份額提高15%，并降低訂票的本錢通過提供出色的訂票效勞，向獨立的旅行社開放ABC旅行系統(tǒng)，這樣也就產(chǎn)生了一個新的收入流……愿景陳述—自動鐵道信號系統(tǒng)工程的目的是通過如下方式降低與交通工具控制中心的維護和修改相關(guān)的本錢：將系統(tǒng)從老化的16位微型計算機移植到現(xiàn)代的32位計算上使用高級語言對最初的匯編代碼進行重新編碼，從而使招聘開發(fā)人員的工作變得更為容易采用一個符合鐵路行業(yè)需求的開發(fā)方法將系統(tǒng)容量提高4倍集成在參考文檔DOC-XXX中識別出來的

新特性需求定義階段產(chǎn)物POS/Vision主題域劃分各個主題域的上下文關(guān)系圖業(yè)務(wù)事件業(yè)務(wù)流程圖邊界確定Report定義與概述業(yè)務(wù)術(shù)語初稿練習：連鎖酒店管理系統(tǒng)Agenda信息系統(tǒng)根底理論需求的根本概念與原理需求工程需求定義最正確實踐需求捕獲最正確實踐需求捕獲是一個探索的過程是一個有方案、科學性的過程討論平時需求捕獲怎么做？需求捕獲有哪些方法？主要的優(yōu)缺點是什么？在需求捕獲過程中遇到的主要障礙有哪些？需求捕獲的主要障礙大多數(shù)情況下，系統(tǒng)相關(guān)的人員無法陳述自己的需要許多用戶難以解釋所執(zhí)行的任務(wù)，更難解釋為什么執(zhí)行這些任務(wù)相關(guān)人員經(jīng)常指定解決方案而不是需求相關(guān)人員也難以設(shè)想出新的工作方法，或者想像出使用提供的方法執(zhí)行熟悉的任務(wù)所能夠得到的結(jié)果不同的相關(guān)人員可能持有相互矛盾的觀點相關(guān)人員經(jīng)常出于抵抗變更而拒絕新系統(tǒng)需求可能過多—過度的需求需求隨著時間而變化需求捕獲的各方職責由需求分析師籌劃，由需求分析師、用戶和其他風險承擔者積極合作完成。用戶、顧客和客戶：有責任向需求分析師提供他們的工作知識需求分析師：理解用戶所說的關(guān)于工作的事情，并將其解釋成產(chǎn)品的需求規(guī)格說明

>觀察和學習該項工作，從用戶角度來理解它

>用戶對某項工作的描述必須作為事實來對待，要發(fā)現(xiàn)工作的本質(zhì)，而非表象

>創(chuàng)造完成該工作更好的方法

>以需求規(guī)格說明書和分析模型的方式記錄用戶在需求捕獲過程中的角色作為設(shè)計組、專題討論會的成員，參與設(shè)計用戶界面作為知識來源，提供任務(wù)、商業(yè)過程的當前執(zhí)行情況參與集策討論會，提供設(shè)想、確定問題作為測試用戶，在驗收時測試系統(tǒng)檢查能否正常工作作為審查者評估用戶界面進行可用性測度，嘗試使用新的用戶界面執(zhí)行任務(wù)作為工程管理委員會成員用戶的各種需求意識到的需求：是指那些用戶最先想到的需求，常常說明用戶希望改進的一些事情無意識的需求：是指那些用戶沒有言明的事情，因為用戶對它們知道得太多，以致于他們假定其他任何人都具備同樣的知識未夢想過的需求：是指那些一旦用戶認識到它們可能就會要求的事情需求心理學—常見現(xiàn)象言過其實心理：說的流程是一種理想化流程，與實際情況嚴重不符越俎代皰心理：對非自己處理的流程津津熱道，根據(jù)自己的理解、想像進行肯定的描述非正事心理：一直忙于工作，無瑕配合需求調(diào)研抗拒心理：新系統(tǒng)對其利益有損，成心不配合推卸責任心理：裝不知，說沒需求需求變化的預(yù)期流程變化：流程順序變化，流程細節(jié)變化，流程負責人變化，流程輸入變化，流程輸出變化。數(shù)據(jù)變化：數(shù)據(jù)格式變化、數(shù)據(jù)規(guī)那么變化、數(shù)據(jù)輸出變化、數(shù)據(jù)項變化業(yè)務(wù)規(guī)那么：規(guī)那么增加、規(guī)那么減少、規(guī)那么變化系統(tǒng)表現(xiàn)形式變化：界面、風格、輸入形式、

展現(xiàn)方式、訪問方法、網(wǎng)絡(luò)環(huán)境目標變化系統(tǒng)化地組織需求捕獲術(shù)語表、域建模、領(lǐng)域培訓—這些都是因地制宜的業(yè)務(wù)建模的常見工具?！瞁iki〕與業(yè)務(wù)流程相關(guān)的系統(tǒng)，最重要的是：置身于流程之中，分析信息、工作流。從“組織結(jié)構(gòu)與崗位設(shè)置圖〞所表達的管理層次與線條建立全局了解；--參與者的來源；針對業(yè)務(wù)流程，繪制出跨部門職能流程圖，以幫助開發(fā)人員對客戶方的業(yè)務(wù)流程建立宏觀、清晰的認識，以便更加有的放矢地進行進一步的需求捕獲工作?？绮块T職責流程圖流程圖系統(tǒng)化地組織需求捕獲應(yīng)該搜集什么信息？細化地研究流程圖，看看是否已經(jīng)對每個環(huán)節(jié)、每個步驟都清楚地認識了。我們應(yīng)該根據(jù)自己的理解首先對每個流程的工作進行定義，寫出事件流，并且標識出疑問點，這些都將使我們明白“應(yīng)該收集什么信息〞。從哪搜集這些信息？流程涉及到什么部門、崗位，答案就應(yīng)該從誰身上找?！查e聊惹的禍〕用什么機制來搜集？需求捕獲技術(shù)有多種，重點在于因地制宜地使用不同的機制……主要需求捕獲技術(shù)比較主要需求捕獲技術(shù)比較用戶訪談用戶訪談：最根本、最常見的技術(shù)利：直接有效、形式靈活、交流深入，應(yīng)該做為主要的需求捕獲技術(shù)〔寬帶通信、固有靈活性、各類信息〕弊：占用時間長〔特別當客戶忙時更顯示出其缺乏〕、面窄而容易造成信息的片面性。要點：首先要有準備：通常包括說明對流程的理解，并征得客戶的意見；預(yù)先根據(jù)流程中的不明確點設(shè)計要詢問的問題，并將客戶的反響記錄下來；應(yīng)留有一些即興的空間，根據(jù)實際情況應(yīng)變，以確保信息完善。第二是要有方案性：方案好時間、方案好人員、方案好策略。用戶訪談：特點最傳統(tǒng)的方法，單獨使用并不有效，通常別期望用戶知道并能夠說出他們的需求應(yīng)先草擬一份問卷，向要訪談的用戶發(fā)出一份涉及訪談主題和時間安排的材料在訪談的過程中，及時用草圖繪制模型〔DFD、用例、思維圖〕，從而得以及時反響應(yīng)以業(yè)務(wù)事件為談話的中心，問問題，聽取答復(fù)，然后反響理解用戶訪談：準備工作圍繞目標制訂一個方案，包括一組按邏輯方式分組和排序的問題在方案內(nèi)應(yīng)有時間在結(jié)束時檢查是否已涵蓋所有問題，并理解對所有問題的答復(fù)不要超過1小時，否那么應(yīng)安排下一次面談地點選擇：適當?shù)牟皇芨蓴_和防止打攪記錄：自己做筆記〔分神〕、專門一同事做筆記〔本錢高〕、錄音〔失去身體語言〕/錄像〔難操作〕自己做筆記+錄音用戶訪談：通用問卷建立客戶或用戶情況表

>姓名、職位等根本信息

>你的主要職責是什么？

>你們的主要輸出是什么？

>為誰做的？

>如何測試成功?

>什么問題阻撓你們的成功?

>如果有，什么使你的工作更容易或更困難用戶訪談：通用問卷評估問題

>你對哪種問題缺乏好的解決方案？

>它們是什么？〔提示：不斷問“還有嗎？〞〕

>對每個問題，問：

>為什么存在這個問題？

>現(xiàn)在你怎么解決它？

>你打算怎么解決它？用戶訪談：通用問卷理解用戶環(huán)境

>誰是用戶？

>他們的教育背景如何？

>他們的計算機背景如何？

>用戶經(jīng)歷過這種類型的應(yīng)用嗎?

>使用的是哪一種平臺？方案將來的平臺是什么？

>有沒有用其他和該應(yīng)用有關(guān)的應(yīng)用？如果有簡單介紹

>對產(chǎn)品可用性的預(yù)期是什么?

>你需要什么樣的用戶幫助〔在線文檔、紙介質(zhì)？〕用戶訪談：通用問卷簡要說明理解情況

>你剛剛告訴我…〔用自己的話列出客戶所述問題〕

>這是否足以表達你認為現(xiàn)在存在的問題？

>如果還有，那是什么問題？分析人員對客戶問題的輸入

(有效或無效的假設(shè))，如果有，問題與什么有關(guān)？

對于每個建議，提問:

>這是一個實際的問題嗎？產(chǎn)生的原因是什么？

>你是怎么解決這個問題的？希望怎么解決？

>和你提到的其他問題相比，這些問題

的位置如何？用戶訪談：通用問卷評估你的解決

(總結(jié)你建議的解決方案的主要功能)

如果你能夠……

對于這些的重要性，你是如何排序的？評估時機

>在你的單位中，誰需要這樣的應(yīng)用？

>使用這種應(yīng)用的用戶有多少?

>如何評價一個成功的解決方案?用戶訪談：通用問卷評估可靠性、性能及支持的需要

>你對可靠性的預(yù)期是什么？

>你對性能的預(yù)期是什么？

>是你還是其他人來支持該系統(tǒng)？

>你對支持還有特別的要求嗎？

>維護及效勞如何?

>平安需求是什么？

>安裝和配置需求是什么？

>有什么特殊的許可需求嗎？用戶訪談：通用問卷其他需求

>有必須支持的法律、法規(guī)、環(huán)境需求或標準嗎？

>你還能想到其他我們應(yīng)該知道的需求嗎?總結(jié)性提問

>我還有其他問題應(yīng)該問你嗎？

>如果我還問你其他問題的話，可以打給你嗎？你愿意參加需求審閱嗎？分析人員總結(jié)：面談后，趁你記得時，總結(jié)

出用戶/客戶確認的三條最高優(yōu)先級的需求或

問題用戶訪談：操作法防止類似以下暗示：我的時間比你珍貴，我不知道我在做什么，你不知道你在講什么用簡單的語言清楚地表達問題，采用對方的術(shù)語和行話不要遺漏任何事情能夠找到和探究異常現(xiàn)角，例如

對未預(yù)料問題的反響不要搞錯根本信息流要求的方向用戶訪談：詢問的問題問題類型：待解決的問題、開發(fā)解決方案的過程、需求獲取本身需求獲取本身的問題：

>我的問題看起來相關(guān)嗎？你的答復(fù)正式嗎？

>你是答復(fù)這些問題的最正確人選嗎？

>我問了太多的問題嗎？

>還有其他什么我該問你的？

>你想問我什么？

>我還應(yīng)該見其他什么人？

>關(guān)于這個工程有什么人我們不需要？用戶訪談：主要困難缺乏對所需要的人的訪問〔知道最多的人最忙〕在面談時記錄信息很困難被訪談人會試圖說他們認為你想要聽的話訪談人用誘導(dǎo)性問題提問束縛關(guān)鍵職員的有關(guān)費用由不同領(lǐng)域知識和行話引起的交流困難隱蔽的動機和組織政策產(chǎn)生錯誤信息練習用戶訪談方案例如用戶調(diào)查：概述用戶調(diào)查：調(diào)查面最廣的技術(shù)利：面廣，能夠獲得更多的人的反響。這點是對用戶訪談技術(shù)缺乏之處的最好補充。弊：不夠深入，容易形而上學。而這點是正是用戶訪談技術(shù)所能夠解決的。要點：結(jié)合用戶訪談技術(shù)使用，具體來說：先設(shè)計問題，制作成為用戶調(diào)查表，下發(fā)填寫完后，進行仔細的分組、整理、分析，以獲得根底信息，然后再針對這個結(jié)果進行小范圍的用戶訪談，作為補充。用戶調(diào)查：主要用途搜索某項假設(shè)的統(tǒng)計依據(jù)：設(shè)計一些封閉的問題，例如“從現(xiàn)有系統(tǒng)中取得客戶統(tǒng)計資料的難易程度：非常困難、相當困難、容易、非常容易〞搜索意見、建議：詢問與用戶訪談類似的開放性問題，例如“日常工作中的三個最大問題是什么？〞，“你對能夠更好地支持日常工作的IT系統(tǒng)有什么建議〞。--誤解你的問題，你誤解他的答復(fù)用戶調(diào)查：主要困難相關(guān)的問題不能事先決定問題背后的假設(shè)對答案會造成偏頗

>例如：這功能符合你的期望嗎？

>假設(shè)：你有期望，所以這是一個有意義的提問難以探索一些新的領(lǐng)域，也沒有探索新的需要被探索的領(lǐng)域的交互難以繼續(xù)用戶的模糊響應(yīng)練習用戶調(diào)查例如現(xiàn)場觀摩：概述現(xiàn)場觀摩：最生動的技術(shù)利：百聞不如一見，能夠?qū)π枨笈c業(yè)務(wù)流程建立直觀的認識。弊：消耗時間長，而且由于“被觀摩〞的微妙心理變化，會使得“觀摩〞失真。適用性：要對于復(fù)雜流程的更加深入的

理解時。要點：悄悄地進行，明確要強化理解的

具體流程環(huán)節(jié)?，F(xiàn)場觀摩：常用變體任務(wù)示范：要求用戶示范如何執(zhí)行特定的任務(wù)利：可用于發(fā)現(xiàn)異常的、關(guān)鍵性的任務(wù)弊：“示范〞失真、耗時做學徒：和用戶坐在一起，通過觀察、問問題、并在用戶指導(dǎo)下完成一些工作來學習適用性：用戶無法詳細解釋清楚他們在做什么時“人們正在做一件事時，最能解釋他們在

做什么，為什么要這么做〞需求分析員可以通過學徒關(guān)系試驗他的

需求和設(shè)計思想文檔考古：概述文檔考古：最貼近實現(xiàn)的技術(shù)利：能詳細、直觀地對數(shù)據(jù)流細節(jié)進行了解與分析。弊：易陷入文山書海之中不可自拔，

甚至常引起誤導(dǎo)。要點：應(yīng)該盡量讓客戶提供寫有真

實數(shù)據(jù)的文檔。特點：從舊的工作材料中挖掘新的需求檢查收集的文檔，從中找知名詞，或

“東西〞，包括列標題、命名的表格區(qū)域涉及內(nèi)容：文檔、打印輸出、清單、

手冊、屏幕等文檔考古：常用思考點此物的目的是什么？怎么用它？為什么用它？用它做什么？系統(tǒng)都利用它來做些什么？哪些業(yè)務(wù)事件用到或引用了此物？此物會有一個值嗎？是數(shù)字、代碼、數(shù)量？如果是這樣的話，它屬于哪些東西的組成體？此物的用途是什么？文檔中是否包含了一組重復(fù)的事物？如果是這樣的話，這些事物的集合稱為什么？文檔考古：常用思考點我能找到事物之間的聯(lián)系嗎？什么過程建立了它們之間的聯(lián)系？每件事物附加的規(guī)那么是什么？換句話說，哪局部業(yè)務(wù)策略涉及該事物？什么過程確保了這些規(guī)那么會被遵守？什么文檔給用戶最多問題？建議：做為數(shù)據(jù)建模方法的一部分文檔考古：優(yōu)缺點優(yōu)：獲取信息相比照較直接，獲得系統(tǒng)所有輸入、輸出及內(nèi)部文檔〔但不應(yīng)假定已獲得全部描述〕；有助于數(shù)據(jù)模型分析。缺：文檔說明的系統(tǒng)與實際系統(tǒng)可能是不匹配的；文檔考古的傳統(tǒng)分析方式〔如開發(fā)文檔流圖〕可能導(dǎo)致產(chǎn)生現(xiàn)有系統(tǒng)的結(jié)構(gòu)模型，從而帶入新系統(tǒng)聯(lián)合開發(fā)：概述聯(lián)合開發(fā)：最理想的技術(shù)利：客戶、開發(fā)人員直接的頭腦風暴，是擊破需求盲點的關(guān)鍵手段。弊：本錢高，如果缺乏控制會變成一次閑扯大會。要點：需要有一個經(jīng)驗豐富、能夠把控大局的主持人。聯(lián)合開發(fā)：優(yōu)點協(xié)助建立一支高效的團隊，圍繞一個目的：工程成功所有風險承擔人都暢所欲言，沒人被落下正如應(yīng)用工程所必須做的，它促進風險承擔人和開發(fā)團隊之間達成共識它能夠揭露和解決那些阻礙工程上成功的行政問題能夠產(chǎn)生一個在特征級別上的初步系統(tǒng)定義聯(lián)合開發(fā)：準備工作推銷概念：充分的準備是聯(lián)合開發(fā)的關(guān)鍵，推銷聯(lián)合開發(fā)〔需求專題討論會〕的好處確保真正的風險承擔人參與后勤保障熱身材料：在開會前散發(fā)資料

>工程專有信息：需求文件草案、已排序的特性…

>擺脫束縛思想的：提供創(chuàng)新方法、自由討論規(guī)那么…

>2天~1周內(nèi)散發(fā)，太早會使人忘記！聯(lián)合開發(fā)：準備工作備忘錄收件人：XXX工程的風險承擔人主題：即將召開的需求專題討論會

我是XX產(chǎn)品〔工程〕的管理者。這個工程已經(jīng)〔或即將〕于開始并截止于完成。

〔我們了解它，我們是認真的，我們想要按時完成它〕正如大多數(shù)的工程一樣，獲得關(guān)于應(yīng)用工程的新特征的共識并定義一個最初的根本系統(tǒng)來滿足不同風險承擔人的需要是十分困難的?！菜踔帘仍谶@個組達成任何其他共識更，因此我們將嘗試一些不同的方法…〕為了使這個過程更加容易，我們將召開一次關(guān)于的需求專題討論會。專題討論會的目標是：為產(chǎn)品的下一個基線版本確定新特性。為了做到這些，聽取每一個風險承擔人的意見就極為重要。專題討論會將由來主持，他是一位經(jīng)驗豐富的需求管理聯(lián)

絡(luò)員?！沧鳛轱L險承擔人，我們可能也有偏見，從外面聘請主持人可以使其更公平〕專題討論會將很快得出結(jié)果，并在第二天將結(jié)果分發(fā)給開發(fā)部。我們熱忱地邀請您參加專

題討論會并提出代表你的〔團隊、部門、用戶〕需求的意見。如果您無法參加，我們熱切地希

望你能夠授權(quán)一名代表您的需求的成員參加。〔會后第一天我們將開始工作；如果你希望對工程提出什么意見，請到這里來，或授權(quán)一

名代表來。換句話說，要么現(xiàn)在說，要么永遠別說?！硞渫浿杏幸粋€關(guān)于當前產(chǎn)品期望特征的簡短說明，以及其他關(guān)于專題討論會和自由討論

進程的資料。專題討論會將于上午8:30開始，下午5:30結(jié)束。〔這個專題討論會以及該工程將按專業(yè)要求運作，需要你們來建議，使工程更順利〕熱切期盼在會場上見到您。[工程領(lǐng)導(dǎo)人]聯(lián)合開發(fā)：聯(lián)絡(luò)員聯(lián)絡(luò)員：熟悉該過程，有風度受尊重，團隊外成員主要職責

>在會議中建立一種專業(yè)、客觀的基調(diào)

>按時開始、結(jié)束會議

>建立并維持會議“規(guī)那么〞

>為會議訂立目標和議程

>管理會議進程并保