?????? 需求分析師/產品經理通過訪談、問卷調查、觀察等技巧獲取需求后，手頭可能有客戶提出的大量的、雜亂無章的需求。其中有些是乙方領導暗示可放入二期的；有些憑過往經驗可提供甲方更優方案解決同一業務目標的；有些技術實現不可行或成本太大的……需求調研與控制需求，有許多彎道超車的途徑，本文不做闡述。本文只提供需求調研報告模板，使得需求更明確、更系統，也是之后工作（業務需求、功能需求）綱領性、可追溯文件。

?

需求調研報告模板

1引言

1.1編寫目的//編寫本文檔的目的

1.2調研背景//參與人員與調研過程

1.3專業術語//文檔中的專業術語解釋

?

2概述

2.1項目背景與目標

例：PAD(平板電腦)在教育信息化方面有著獨特的技術優勢，近年隨著PAD技術的成熟、價格的下降，采用PAD作為電子書包，將其應用于課堂教學成為大勢所趨。XXX智慧課堂系統提供課前多媒體微課程電子教材預習、課中互動教學、課后微課程作業輔導三大功能

2.2期待解決的問題//希望通過本項目解決當前存在的哪些問題。

例：完美解決了Pad不受控、Wi-Fi掉線、與電子白板難以無縫對接等制約電子書包應用的關鍵問題，為老師和學生提供了一種高效的“教”與“學”模式。該系統為實現“顛倒的課堂”和學生隨時隨地碎片化學習提供了全面支撐。

2.3項目范圍//軟件項目定義其范圍，陳述正在開發中的解決方案是什么和不是什么

例：本系統所管理的業務范圍包括紙質作業和試卷批閱、多媒體互動（二期）、電子白板互動、教室設備管理。

2.4雙方約定//約定雙方理解上可能有歧義的地方，例如范圍限制、支持的平臺、第三方受限等

3相關資料

3.1組織結構//公司的組織結構

3.2用戶名單

3.3業務規則//每個組織的運營遵守的政策、法規、行業標準。金融、醫療器制造等行業必須遵守大量的政策法規。

4需求//本文檔的核心內容

該部分整理用戶提出的各種需求。需求調研，正是為了獲取用戶的需求，該部分為本文檔的核心內容。

需求的描述可從不同的維度去分類。一種是按照業務領域劃分（以用戶為中信）；另一種是按照功能模塊劃分（以產品為中心）。在大多數情況下，最好選擇“以用戶為中心”。關注用戶的需求，避免做出的產品雖然實現了功能，但并不是用戶真正所需要的。（可使用用例描述一系列系統和外部角色之間的交互，表達出該用例為用戶提供的價值）

可用VISIO等建模工具畫用例圖（見下圖）

用例使用場景描述的系統的使用方法。用例是相關使用場景的一個集合，場景是用例的特定實例。在探索用戶需求時，可以從一個通用的用例開始，開發更多具體的使用場景。也可以從一個特定場景示例歸納出整個用例。

用例場景包括：角色、觸發條件、前置條件、后置條件、正常流程、可選流程、異常等。（見下圖）

ID和名稱：	UC-5.9.3-請假-教師提出請假申請：教師提出請假申請
創建人：	?	創建日期：	2018/05/29
主要操作者：	教師	次要操作者	無
描述：	教師錄入請假的信息，能成功提出請假申請（注意：不是成功請假，請假成功需各級審批，各級審批都通過后為請假成功）
觸發器：	教師表示要發出請假申請
前置條件：	?
后置條件：	系統保存請假申請數據，并提示成功提交申請的信息。
一般性流程：	1.指示提出請假申請 ------2.顯示請假申請表單（系統） 3.填寫申請單，選擇請假類別、請假時間等 4.指示提交申請 ------5.顯示成功提交申請的信息（系統）
選擇性流程：	4.指示取消申請 -------5.顯示申請被取消的信息（系統）
異常（特殊情況，非代碼中異常）：	必填字段未填寫，提示 彈窗
優先級：	高
業務規則：	?
其他信息：	申請者默認為當前用戶 不可修改 請假流程 依據請假類別和請假天數

5數據

//本階段無需設計數據字典，只需整理本系統需處理哪些字段。

6相關系統

//可能跟本項目有關的其它軟件系統

描述本系統與外部軟、硬件的借口規定（正常通信）。如果一個復雜系統由多部分組成，則應創建獨立的接口規范說明或者系統架構規范說明。

7其它

7.1注意事項//注意點

7.2待定問題//TBD（to be determed）雙方未達成一致或未處理的問題

?

總結

以上是生活随笔為你收集整理的如何系统整理需求调研报告的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。