XXXXXX需求調研報告IDxx 1.1調研整體流程調研開始項目前期資料匯總項目人員交流調研資料模本準備調研模本行業資料收集項目成員討論否是否完整是資料非電子資料庫書寫需求報告否是否通過審核是需求說明書問題識別:解決目標系統做什么，做到什么程度.需求包括：功能、性能、環境、可靠性、安全性、保密性、用戶界面、資源使用、成本、進度。同時建立需求調查分需的通信途徑。分，綜合成系統解決方案，給出目標系統的詳細邏輯模型。[常用的分析方法有面流的結構化分析方法SA(數據流圖DFD、數據詞典DD、加工邏輯說明)、求方法和模型中發生教條的思維模式和派系斗爭，一般來說結構化方法用于中小規模軟件、面向對象方法用于大型軟件.]編制需求分析文檔需求評審1.2組成部分關系需求分析可分為問題識別、分析與綜合、編制需求分析文檔、需求評審等四個階段，包括以下幾個方面:確定軟件所期望的用戶類；獲取每個用戶的需求;了解實際用戶任務和目標中的一部分分配給軟件組件；了解相關質量屬性的重要性;討論得出實施優先級；將所收集的用戶需求編寫成需求規格說明和模型；評審需求規格說明，確保與用戶達成共識.1.3分析過程需求分析的任務是借助于當前系統的物理模型(待開發系統的系統元素)導出目標系統的邏輯模型(只描述系統要完成的功能和要處理的數據),解決目標系統“做什么”的問題，所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統元素的接口細節,定義軟件的其他有效性需求，通過逐步細化對軟件的要求描述軟件要處理的數據，全面理解用戶的各項要求，但不能全盤接受,只能接受合理的要求;對其中模糊的要求要進一步澄清，然后決定是否采納;對于無法實現的要求要向用戶作充分的解釋。最后將軟件的需求準確地表達出來，形成軟件需求說明書SRS。來反映自己對當前系統的理解。此步驟也可以稱為“業務建模"，其主要任務是對用戶的組織機構或企業進行評估理解他們的需要及未來系統要解決的問題,然后建干戈區進行業務建模，只要做一些簡單的業務分析即可。抽象出當前系統的邏輯模型:在理解當前系統“怎樣做”的基礎上,取出非本質因素，抽取出“做什么"的本質。建立目標系統的邏輯模型：明確目標系統要“做什么".對邏輯模型的補充,如用戶界面、啟動和結束、出錯處理、系統輸入輸出、系統性2需求調研和分析的方法、策略和步驟2.1如何調研需求調研涉及三個問題:者.被調研對象主要是人員和業務兩類，其間主要涉及人與人、人與事物、事物與事物等三構成。而能否把握這一時機并找準需求提煉的關鍵點，是考驗需求調研人員的重要方面.優秀的需求調研人員不僅能認識問題之所在,還能藉此獲取足夠多的知識，最后成為問題領域的專家。需求調研非常困難，必須引起重視。因為:●缺乏專門領域的知識,同時應用領域中的許多問題通常模糊，很難界定；●機構實踐存在默認知識,難以描述；●多個知識源或信息源既有沖突又有重合；●被調研對象可能有認知偏見或者欠缺或有時不愿提供確切信息。這些都會給需求調研人員帶來障礙和困難.在這種情況下，掌握必要的方法與技巧非常2.2如何分析需求描述、需求認可、需求演進這五個層次，并且逐層遞進、螺旋式上升.需求分析是需求工程的核心，貫穿于系統整個生命周期.需求分析的出發點在于:對調研的需求進行進一步提煉并指導需求的抽取；幫助需求分析人員發現問題.需求模擬則幫助檢查驗證對問題的理解。需求分析和模擬又包含三個層次的工作：需求定義、需求建模、需求模擬。需求定義,是對經調研獲取的需求進行初步整理,抽取其中基本需求和關鍵需求予以界定，并為需求建模提供必要的需求元素.需求建模,是把抽象的需求通過概念、符號、數學模型及邏輯結構表現出來。表現形式有自然語言、半形式化(如圖、表、結構化英語等)和形式化表示等三種。自然語言形式具有表達能力強的優點,但不利于捕獲模型語義；半形式化表示可捕獲結構和一定的語義，也的形式化模型,需要較長時間和對問題領域的深層次理解。相對而言，圖表形式的需求模型直觀常用，比如組織結構圖、系統流程圖、網絡拓撲圖等。可構造性、利于分析、可追蹤性、可執行性、最小冗余性.2.3調研方法;確；3、收集分析客戶使用的各種表格、有關工作責任、工作流程、工作規范、相關數據標準、業務標準的各種文字資料；5、情景分析：利用情景分析誘導用戶能夠把它們的需求告知分析員(可以描述當前一項業務怎么做、也可以描述設想的系統中此項業務怎么做);6、可視化方法:結和情景分析，利用畫用戶界面圖、業務流程圖、功能結構圖、時序圖等圖形與客戶進行討論;2.4基本策略1、首先確定用戶的軟件開發目標,確定系統基本范圍,然后圍繞這一目標，確定要訪問的部門和人員，要了解的業務，在基本范圍內展開調研；輸出項；6、應思考是否有新技術可以改進現有工作，用戶提出的需求用現有技術能否實現。2.5結構化方法分析步驟2、決定哪些部分需要計算機化和怎樣計算機化(取決于用戶投資限制和自身技術限制)；；4、定義處理邏輯(加工邏輯:每個加工處理做什么)；5、定義數據存儲，即定義每個存儲的確切內容及其表示法(格式);6、定義物理資源：如是文件需指定:文件名、組織結構(排序、索引等)、存儲介質和記錄；如是數據庫需指定每個表的相關信息;、輸入屏幕、打印輸出格式、輸出長度等等；2.6UML方法分析步驟一般的應用系統又是各組成部分：問題論域、人機界面、數據管理、任務管理，在OOA進行抽象，提出高層次的解決方案)；(1)確定系統范圍和系統邊界; (2)確定系統的約束(環境和條件)； (3)定義活動者； (4)確定系統的綜合要求(功能、性能、運行)； (5)確定系統的數據要求(名稱、范圍、類型、數量、特點)； (7)繪制主要交互圖；3、建立靜態結構模型(對象類圖、數據庫模型、包圖)；4、建立動態行為模型(順序圖、協同圖、狀態圖、活動圖)；5、建立系統物理模型(組件圖、配置圖)；3.1文檔規范2、建立圖形化模型，這些模型可以描繪轉換過程、系統狀態、和它們之間的變化、數據關系、邏輯流或對象類和他們的關系;3、編寫形式化規格說明,這可以通過使用數學上精確的形式化邏輯語言來定義需求。多種編寫方法可在同一個文檔使用，根據需要選擇，或互為補充，以能夠把需求說明白4、目標軟件系統功能劃分(示意圖及文字說明)；6、目標軟件系統中各業務辦理流程圖(模型);3、需求陳述應該有一致的樣式，例如“系統必須.."或者“用戶必須。。”，并緊跟一個行為動作和可觀察的結果。；4、避免使用模糊、主觀的術語，減少不確定性，如“界面友好、操作方便”;度。3.2需求管理過程域)，這些活動包括: (1)定義需求基線(需求文檔的主體)； (2)評審提出的需求變更申請、評估每項變更可能的影響,從而決定是否實施變更；(3)以一種可控的方式將需求變更融入到項目中; (4)使當前的項目計劃與需求保持一致； (5)分析變更所產生的影響并在此基礎上協商出新的約定; (6)使每項需求都能與其對應的設計、