如何系统整理需求调研报告

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

需求调研报告模板

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）双方未达成一致或未处理的问题