第一篇：將軍項目-需求調研報告

需求調研報告

一、調研目的

主要對將軍集團現有安全業務運行情況、安全管理制度、組織機構等內容進行調研；結合招標要求，了解各級領導、安全管理人員對于信息系統的真實想法，以方便需求分析、原型設計。

二、調研對象

實地調研將軍集團本部、煙輔中心、包材、萊州印務，其它公司在需求介紹會上征求意見。

三、調研情況(一)組織機構

目前將軍集團由集團本部、13家分公司組成，其中有3家中心歸屬集團本部管理。

(二)安全人員

不一定都有安保部，但都會有專兼職安全員。

(三)OA情況

OA系統賬號管理比較嚴格，下屬單位賬號只有公司領導和辦公室有，導致安全部門的一些文件通告等不能及時傳達給下屬單位的安全相關人員。

(四)計劃使用人員

安全系統主要由安全線人員使用，包括各部門、公司主管領導等也可以操作。(五)集團安保處在系統中作用

集團安保處主要進行監督、管理，具體業務在各公司內部完成。(六)集團安保處希望必須具備的功能

1、增加日報功能

2、增加文件查閱日志功能

3、增加集團培訓計劃下發，各公司上報人員功能(七)關于系統流程情況的說明

經過調研，考慮到人員操作水平、快捷性，只有公司級隱患涉及流程操作，其它業務線下走處理。

四、業務功能

1、目標考核

各個部門每年分別依據上級目標，建立自己的安全生產目標；

集團每季度對各公司進行考核；

公司每月對各部門進行考核。

2、安全費用

各部門每年初制定安全生產費用計劃，按照費用類別錄入；

當有對應項目時，需要選擇計劃，并將支出內容進行填報。

3、培訓、證書管理

各部門每年自行制定培訓計劃，并依據計劃執行。

集團安保處會安排組織有上級部門、集團、政府組織的培訓，需要下級公司部門根據計劃提交參加培訓人員，集團安保處對培訓結果進行登記。人勞部門負責證書的管理。

4、設備設施

各公司實行設備信息由設備管理部門自行登記的方式管理維護，設備檢查要具體到某個設備。

5、交通安全管理

一般有各公司辦公室統一管理，只針對普通車輛管理，需要包括車輛的年審、保險等信息。駕駛員也需要進行登記。

6、職業健康管理

公司安保部門根據國家職業病相關法規和標準對有危害因素的場所進行識別，并聯系相關檢測部門對場所進行檢測，檢測結果存在危害因素的納入危害因素場所進行管理，檢測結果達標的場所將不在系統內進行管理（危害因素檢測信息由公司安保部門錄入系統）。同時，安保部門需要針對危害因素的場所定期進行檢測，或者定期進行重新識別有危害因素的場所。危害因素的場所的危害因素由檢測報告的結果進行確定。

危害場所內工作的人員要進行統計，并根據要求定期進行體檢。人員的體檢工作由公司人勞部門進行管理。在有危害因素場所工作的人員在上崗前、上崗中和離崗前都要進行針對相關危害因素的體檢，確保沒有因為工作環境而得職業病。其進行體檢的相關人員信息由公司人勞部門建立檔案進行長期管理（管理年限和檔案相同）。各部門安全員從人勞部統一領取涉及本部門的所有勞防品（該領取記錄不在系統中體現），然后再由部門安全員將其發放到具體崗位、人員，發放時具體領取人員需簽字確認，發放完成后由部門安全員將發放記錄登記建檔，簽字確認單以照片附件形式上傳，不在系統中按人員逐條錄入。

7、消防安全管理

公司安保部負責對公司消防安全進行統一管理，主要包括建筑物消防臺賬、重點部位臺賬、設施器材和消防隊伍的管理與登記。其中設施器材日常要進行保養工作；每個公司至少有一支消防隊伍。

8、法規標準與資料

集團安保處安全員負責法律法規、國家標準信息的統一發布和管理。全集團所有角色可以對其進行查看。

公司安保處安全員、部門安全員可以發布適用自己部門特點的管理制度與相關資料，并對其進行管理。

9、安委會管理

公司安保部維護自己所在公司的安委會相關信息，安委會信息包括安委會基本信息和安委會成員信息兩部分。

公司安保部對各自的安委會日?；顒舆M行管理，主要包括定期召開安委會會議并紀錄會議紀要并跟蹤會議確定的決議后續工作。

10、危險作業管理

由于危險作業涉及重大責任問題，約定保留紙質檔案材料，線下走審批流程，安保部需要將最終審批通過的信息進行登記。

危險作業分為：動火、高處、有限空間、臨時用電。

安保部對不同階段的危險作業進行檢查工作，并將結果進行登記。

11、危險源管理

每年年初，公司各部門會對所轄區域內的所有危險源做一次辨識，辨識結果上報至公司安保部進行審核，通過后公司安保部匯總、上報公司分管領導審批。經過溝通，安保部將審批通過的危險源登記，并發布作為當年度確認的危險源。

在管理過程中如出現技術改造等，可通過撤銷發布，進行刪除、修改危險源。只有當年度辨識的未發布的危險源可進行發布；只有當年度的危險源可進行撤銷、修改；已經發布的非當年度危險源不能進行撤銷。

危險源所在部門以及公司安保部門在日常工作過程中需定期對其進行檢查。

12、隱患管理

部門級隱患在系統中不涉及流程；公司級隱患按照正常流程處理。公司級隱患的閉環管理包括：問題登記、隱患核準、隱患整改通知書下發、隱患整改措施制定、隱患整改實施、隱患驗收。上級檢查登記后，受檢部門進行整改，自行在系統中進行處理，需在全部整改完畢后，進行反饋，上級部門再進行復查。經過溝通，這一過程在系統中不涉及流程，僅以結果進行登記。公司級隱患管理流程經過溝通，流程圖如下： 隱患管理流程（web）問題登記公司級-隱患發現部門公司級-安保部門公司級-責任部門開始[安全員]問題登記[安全員]提交隱患核準[安全員]隱患核準否是否通過是整改通知[安全員]下發整改意見整改措施[安全員]是撤回整改意見書[安全員]是否接受否[安全員]填寫申訴理由是[安全員]不撤回[安全員]是否申訴反饋否[安全員]填寫整改措施實施整改實施整改簽收前可撤回[安全員]填寫整改實施情況整改驗收[安全員]簽收[安全員]整改驗收否是否驗收通過是結束

13、事故管理

事故管理主要包括未遂事件、事故臺賬.事故調查完成之后，形成最終事故報告。

每家公司每季度需要形成一份安全生產報告。

14、車間班組管理

各部門自行維護各自的班組信息，并對班組活動計劃、記錄進行管理。

15、溝通協商

主要針對日常安全工作中由安保部門牽頭的不同部門、人員協商溝通的活動紀要。主要包括會議、電話溝通、口頭溝通等形式的記錄。

16、三同時

主要針對需要報政府部門備案的三同時項目建立臺賬。要求安保部門參與，基建部門是主要責任部門。

17、信息交流

主要包括消息中心、集團發布的資訊信息、日報提交與查看、互動信息等。

18、安全知識

安全文化建設是企業文化建設中的一部分內容，通過建立安全文化園地實現安全文化建設，內容包括：問題建議查看、安全知識分享，其中問題建議通過手機端實現。

19、應急演練

各公司安保部錄入經過確定的應急預案，針對各預案每年年初制訂演練計劃，各部門依據演練計劃實施演練，最后會對演練的效果、預案的情況進行評價。20、危險物品管理

危險物品動態的臺賬由倉儲或者生產之類的業務部門管理，由于危險物品領用在日常工作中比較頻繁，并且每日均有變化，故在系統中不實現危險物品的領用量、庫存量的動態管理，不做領用記錄。在系統中危險物品的管理統一由公司安保部管理。

21、相關方管理

相關方管理有各部門(歸口部門)自行登記管理。

主要包括相關方信息、相關方協議、相關方評價、相關方交底教育。

22、移動端

(1)標準版：

應用對象為WEB端有賬號的人員，需通過平臺賬號登錄； 主要功能包括“移動巡檢、消息中心、問題建議、安全知識分享、集團資訊、日報提交”。

(2)全員版

應用對象為全員員工，安裝后無需賬號即可使用，主要目的為推進全員參與；

功能包括“集團資訊、安全知識分享、問題建議”；首次進入時需要設定所在公司。

第二篇：需求調研報告

文檔編號：XXXX-XXXX-XX/XX(XXXX)XXXXX

XXXX XXXX科技工程項目

XXXX XXXX XXXX研發工程

×××需求調研報告

項目包名稱：

項目編號/包號：

項目承擔形式：

項目單位（甲方）： XXXX XXXX XXXX XXXX GXTC-CZ-1015004/13 聯合承擔XXXX XXXX XXXX XXXX 項目承擔單位（乙方）：

責任承擔單位：

合作承擔單位：

項目起止年限： XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX 2011.1-2014.7

需求分析報告2/5

目錄引言...........................1

1.1 編寫目的.........................1

1.2 背景.................................1

1.3 參考資料.........................1

1.4 術語.................................1

任務概述..........................1

2.1 任務目標.........................1

2.2 調研對象.........................1

2.3 調研方法.........................1

2.4 組織安排.........................2

2.5 調研內容.........................2

業務流程調研.........................3

3.1 概述.................................3

3.2 總體業務流程圖...........................3

3.3 核心業務流程...............................3

3.4 核心業務對象和數據..........................3

應用系統調研.........................3

4.1 系統概述.........................3

4.2 系統功能結構...............................3

4.3 系統技術架構...............................3

4.4 系統部署環境...............................3

4.5 系統接口現狀...............................3

接口需求調研.........................3

5.1 ****接口需求...............................4

5.2 ****接口需求...............................4

尚需解決的問題............................4

附錄...........................4 2 3 4 5 6 7引言

1.1 編寫目的編寫此文檔的目的。

1.2 背景

需求調研的背景。

1.3 參考資料

列出編寫本報告時參考的文件(如經核準的計劃任務書或合同、上級機關的批文等)、資料、技術標準等。

1.4 術語

列出本報告中用到的專門術語的定義。任務概述

2.1 任務目標

敘述該調研主題的意圖、應用目標、作用范圍以及其他有關背景材料。

2.2 調研對象

調研的對象。

2.3 調研方法

調研的方式方法。

2.4 組織安排

參與人員及組織結構。

2.5 調研內容

列出本次調研的主要內容，以下章節根據實際內容撰寫。

比如：

1、業務流程調研

2、應用系統調研

3、接口需求調研

3業務流程調研

3.1 概述

3.2 總體業務流程圖

3.3 核心業務流程

3.4 核心業務對象和數據應用系統調研

4.1 系統概述

4.2 系統功能結構

4.3 系統技術架構

4.4 系統部署環境

4.5 系統接口現狀接口需求調研

5.1 ****接口需求

5.2 ****接口需求尚需解決的問題

調研遺留問題。附錄

包括過于復雜、專業性的內容，包括調查問卷、抽樣名單、地址表、地圖、統計檢驗計算結果、表格、制圖等

第三篇：某項目需求調研報告

XX 項目需求調研報告

一、背景分析 二、調研 概況（一）調查地點（二）調查對象（三）調查目的（四）調查方法（五）調查的分工及安排 三、調研結果（一）服務需求分析 示例：通過調研發現社區長者需求有：1）38%長者希望獲得社區康復方面的服務；2）29%長者獲得廣場舞等文體活動；3）21%需要長者小組、興趣班。

（二）調研結果分析（調研結果為響應服務需求而開展的服務）

示例：結合社區長者需求分析，在社區康復服務方面開展健康建檔、自我保健、診療服務等；在文體服務方面組織參觀文化館、文物建筑、影視放映、文藝匯演、老年教育等服務；在興趣服務方面開展唱歌、跳舞、下棋、球類服務等。

四、本調研的局限

五、項目 工作 方向及 重 點（調研結果與此相關）

示例：綜合社區已有資源和服務對象需求，在老年人服務方面以社區康復服務為主，文體服務和行為服務為輔，在滿足老年人服務需求的基礎上，重點集中在老年人社區康復服務方面，力爭通過服務（項目）的開展讓老年人享有健康、幸福的晚年生活。

六、審批意見 1、撰寫人姓名

職位

簽名

日期

2、督導審批意見

審批人姓名

職位

簽名

日期

備注：紅色字體為填寫說明及示范，填寫完成后請刪除。

第四篇：項目管理心得—需求調研

項目管理心得—需求調研

2016年8月我作為項目經理承接了廣州某區政務智能機器人建設項目，在承接此項目的時候公司售前告訴我，項目已經有了初步的建設需求，并將項目前期的全部資料都發給了我，我經過整理發現，這些資料在客戶具體建設需求方面描述不夠清晰，缺乏驗收具體指標，有可能會造成項目最終無法驗收。

項目正式入場后，我帶領2名需求人員，先對項目干系人進行收集，對結合之前的資料，通過召開需求調研會、調研表、面對面調研、郵件等方式收集所有項目干系人的項目需求，編制需求說明書，并充分聽取項目關鍵干系人的意見完善了項目需求，最終形成需求調研報告，并由甲方關鍵干系人簽字確認，在項目實施期間按照項目需求書進行項目建設規劃設計并組織項目實施，2016年12月份項目順利驗收。

在本項目我充分利用PMP所學的需求調研過程及要點，在充分識別干系人的基礎上完成了項目需求的調研，有效的減少項目實施過程中的需求蔓延導致項目無法驗收的情況。

慧翔天地廣州學員黃賢裕

第五篇：軟件項目需求調研總結

軟件項目需求調研總結

一、需求調研準備：

在需求調研過程中，應該做好三種準備，保持兩種心態，做到五種提高：

三種準備

1）調研前應該將所有項目前期資料進行匯總，與相關的前期銷售人員進行交流，以便對項目有一個基本輪廓的認識。

2）做好調研前使用資料的準備，如需求調研模板，需求調研問題列表等。

3）做好不怕一切困難的準備。

兩種心態

1）保持一種和客戶平等合作的心態，確定需求調研是為了給客戶解決問題，探討問題，而不是接受問題，更不是來指導工作的。

2）平靜面對需求變更的心態，在需求調研過程中，往往雙方對需求理解不一致，造成需求調研前后矛盾，應當心平氣和的去引導客戶，達到需求理解基本一致。

三種提高

1）首先提高自己業務知識，對于人力資源的標準業務應該基本熟悉。

2）其次應該努力的去熟悉用戶的行業，學習用戶使用的術語，標準，以便能夠準確的理解用戶。這就需要我們閱讀用戶所在行業的資料、文章，盡量多選取一些整體性介紹的文章，這樣可以在短時間內能夠對該行業有一個全面的認識，這樣我們就能夠較好的和用戶進行交流了。

3）需求調研中，學會盡量不使用IT行業的術語，而采用淺顯易懂的口頭語言來解釋IT行業中高深莫測的術語，以便用戶能夠很好的理解，提高自己的溝通交流能力。

4）提高自己的速記能力，文字表述能力以及歸納，能迅速的記錄需求調研核心的問題，總結歸納形成原始的需求調研資料。

5）提高自己的總結能力，書寫一份完整的、前后一致的、可追蹤的需求報告。

二、需求調研過程的總體流程

需求調研中應遵循一定的流程，而且在調研過程中表現出規范，調研有條不紊，對客戶有理有據，調研中資料做好備份，做到有備無患：

三、需求調研過程中注意問題

四、需求報告書寫要求及標準

編寫優秀的需求是沒有公式化的方法的。這需要大量的經驗，要從你在過去的文檔中發現的問題學習。請在組織軟件需求文檔時，嚴格遵從這些方針。

句子和段落要簡練。使用正確的語法，拼寫，標點。使用術語，要保持一致性，并在術語表或數據字典中定義它們需求編寫者還要努力正確地把握粒度。多個需求盡可能拆分開。

整個需求文檔細節上要保持一致。

避免在需求報告中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護增加困難。文檔的多份文本要在同一時間內全部更新，避免不一致性。

需求調研對于系統的構造，系統測試以及最后的客戶滿意，都會成為好的奠基石。并且要記住，沒有高質量的需求，軟件就象一盒巧克力，你永遠不知道你會得到什么。我希望我們能得到一塊“德芙”。

調研概要情況：X項目需求調研開始于2006-3-23結束于2006-6-15，內容包括現場需求調研4個人月和分析需求編寫需求文檔6個人月。參與調研的包括項目經理、技術經理和兩個開發骨干，編寫需求規格說明書字數95.4萬。

1.把二期項目當作一個新項目來做調研，避免需求細節遺漏。在調研的初期我們曾經有過疑慮，這是一個二期的項目，那么調研的內容是否只針對二期的新需求，對需求內容二期和一期一致的部分就不必調研了?

經過討論我們還是決定把二期項目當作一個新項目來做調研，即使二期和一期需求內容一致，我們也在調研會上討論，并記錄在調研筆記及以后的需求文檔上。這樣的好處是最大限度地避免了需求細節的遺漏。在現場調研時，發現有不少地方原來以為是二期不必修改的，經過討論后發現還是需要修改。（往往危險的需求描述就在于“這部分做的和某個系統或某個版本的舊系統一樣就可以了”）

2.調研團隊參加所有子系統的調研會議，可以相互補充避免需求遺漏。這個項目規模比較大，根據業務的類型不同，分成了6個子系統，各個子系統的業務信息互有接口。我們安排每個人至少負責一個子系統的需求，但是在調研時，只要可能，我們都盡量讓每個人都參與所有系統的調研會議。對項目經理和技術經理則進一步要求了解所有系統的業務需求。這樣做的好處是，對于子系統之間的業務關系，調研團隊都可以有全面的了解，對業務的理解比較透徹全面，并且還可以相互補充遺漏。

3.多人調研，在會議后應該立刻回顧整理統一的會議筆記，消除歧義，避免遺漏。在開調研會時，全體與會人員都各自記自己的會議筆記，會后沒有強調當天整理會議筆記（會議進度很緊，每天開會到晚上8、9點鐘）。這導致以后閱讀會議筆記發現一些描述很簡單理解上有歧義的內容，或者同一份需求在幾個筆記上記錄的內容細節上有差異，事后難以追溯正確的信息。給編寫需求文檔帶來了一些困難，需要再次討論需求。

4.需求文檔編寫完成后，在開發階段也應該做檢查和更新，避免文檔錯誤對開發的誤導。我們在完成大量的需求文檔編寫工作后，在開發階段有部分文檔沒有做內容檢查和及時更新。后期測試時才發現少數需求內容的矛盾和錯誤，導致需要重新修改。

建議：

1、如果在編寫需求文檔后，開發階段應該做一邊閱讀需求文檔，一邊做需求文檔的檢查，對于保證需求質量效果會更好。

2、應該指定人負責需求追蹤和更新，在開發階段、測試階段要保持和用戶的需求溝通，這不是一個可有可無的簡單工作，很重要，并且會占用責任人50%的工作時間。

3、企業業務管理信息系統的需求調研方法：我認為對調研的組織安排是非常重要的，好的調研安排雖然未必產生質量高的需求，但是一個不遵循調研規律的調研活動，必然是低效的。下面是H項目調研組采取的調研流程，供參考：

4、第一步不是立刻和用戶當面討論需求細節，而是要業務關鍵用戶編寫初步的需求報告，提供給開發團隊閱讀分析。需求報告的內容是，對業務流程的描述，對業務需求的描述。需求報告的質量往往和關鍵用戶的投入多少有較大關系，經常在沒有面對面溝通時，關鍵用戶未必能對這份報告投入很多的時間和精力。但這是當面調研的基礎，一定要做，有粗糙疏漏的地方可以再現場調研時再細化。這可以再調研前就和用戶溝通，讓用戶編寫。