需求分析師培訓-1

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

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

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

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

>工作流模型數據信息化

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

>需要留存哪些數據？誰需要共享？

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

>不切實際的用戶需求

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

>用戶介入太少

>需求不完整

>需求變更頻繁需求—導致工程失敗的罪魁禍首根據StandishGroup對23000個工程進行的研究結果說明，28%的工程徹底失敗，46%的工程超出經費預算或者超出工期，只有約26%的工程獲得成功。而在于這些高達74%的不成功工程中，有約60%的失敗是源于需求問題。也就是說，有近45%的工程最終因為需求的問題最終導致失敗。對不知道航行目的地的人來說，沒有順風！我們在哪里重重摔了一跤在StandishGroup的報告中總結了導致工程失敗的最重要的8大原因中，有5個與需求相關：不完整的需求(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%)；現實的客戶期望(8.2%)；較小的里程碑(7.7%)；有才能的員工(7.2%)軟件需求曾經讓我們如此狼狽參與各方都以自已角度講述問題分布式WebServices三層

對話框菜單條DCOM

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

業(yè)務線索管理業(yè)務經線索跟蹤

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

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

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

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

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

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

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

A5.快速捕獲本錢數據

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

B5.減少繁瑣工作

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

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

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

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

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

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

劃定范圍，最常用

的方法是工作上下

文范圍圖〔結構化

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

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

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

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

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

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

>問題域的描述

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

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

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

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

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

>應用〔問題〕領域專家

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

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

>問題域的結構〔子域，及子域間關系〕

>問題域的數據

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

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

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

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

>類模型：對象、數據

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

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

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

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

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

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

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

>需求評審

>需求確認

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

協調、觀察、寫作、組織、建模、人際交

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

>效益分析：經濟可行性，投資回報

>社會可行性

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

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

Solutions:>只想What，別想How

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

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

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

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

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

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

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

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

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

>問題：描述問題

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

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

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

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

>增加了銷售數據的報告以便進行管理

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

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

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

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

>背景：新產品的來由與背景

>業(yè)務機遇

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

>客戶與市場需求

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

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

>主要特性

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

>第一個版本的范圍

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

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

>涉眾簡介

>工程優(yōu)先級

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

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

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

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

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

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

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

>姓名、職位等根本信息

>你的主要職責是什么？

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

>為誰做的？

>如何測試成功?

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

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

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

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

>對每個問題，問：

>為什么存在這個問題？

>現在你怎么解決它？

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

>誰是用戶？

>他們的教育背景如何？

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

>用戶經歷過這種類型的應用嗎?

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

>有沒有用其他和該應用有關的應用？如果有簡單介紹

>對產品可用性的預期是什么?

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

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

>這是否足以表達你認為現在存在的問題？

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

(有效或無效的假設)，如果有，問題與什么有關？

對于每個建議，提問:

>這是一個實際的問題嗎？產生的原因是什么？

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

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

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

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

如果你能夠……

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

>在你的單位中，誰需要這樣的應用？

>使用這種應用的用戶有多少?

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

>你對可靠性的預期是什么？

>你對性能的預期是什么？

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

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

>維護及效勞如何?

>平安需求是什么？

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

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

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

>你還能想到其他我們應該知道的需求嗎?總結性提問

>我還有其他問題應該問你嗎？

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

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

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

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

>我的問題看起來相關嗎？你的答復正式嗎？

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

>我問了太多的問題嗎？

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

>你想問我什么？

>我還應該見其他什么人？

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

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

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

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

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

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

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

甚至常引起誤導。要點：應該盡量讓客戶提供寫有真

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

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

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

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

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

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

我是XX產品〔工程〕的管理者。這個工程已經〔或即將〕于開始并截止于完成。

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

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

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

望你能夠授權一名代表您的需求的成員參加?！矔蟮谝惶煳覀儗㈤_始工作；如果你希望對工程提出什么意見，請到這里來，或授權一

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

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

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

>按時開始、結束會議

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

>為會議訂立目標和議程

>管理會議進程并保