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

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u012785908/article/details/80490708

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

 

需求调研报告模板

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

 

展开阅读全文

没有更多推荐了,返回首页