需求分析师/产品经理通过访谈、问卷调查、观察等技巧获取需求后，手头可能有客户提出的大量的、杂乱无章的需求。其中有些是乙方领导暗示可放入二期的；有些凭过往经验可提供甲方更优方案解决同一业务目标的；有些技术实现不可行或成本太大的……需求调研与控制需求，有许多弯道超车的途径，本文不做阐述。本文只提供需求调研报告模板，使得需求更明确、更系统，也是之后工作（业务需求、功能需求）纲领性、可追溯文件。
需求调研报告模板
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）双方未达成一致或未处理的问题