需求调研报告5要素

需求调研报告5要素一、用户需求报告组成一般在用户需求报告中，核心要素有以下几点：需要明确出产品的功能需求；软件的流程图，包含业务流程图和数据流程图；软件的数据体系，包含数据定义、数据结构和数据字典；接口说明，包含内部接口和外部接口；当然还包含一些易用性、性能等等。二、各阶段要素详解（一）功能需求对于功能需求，可以使用表格或者模块为段落章节描述清楚功能模块的细分，要列出详细的功能点，并且还要描述各功能。（二）流程图一般是先有业务流程图，然后才画数据流图。对于业务流图一般是结合用户使用场景进行绘画的，通俗的说就是用户使用软件进行现实生活场景时的操作，通过业务流程图可以了解用户如何使用软件进行工作。一般用户会有多个使用场景，因此可以画多个主要场景的业务流程图。业务流程图一般以泳道图的形式呈现，可以清晰的突出价值活动的逻辑关系，并能较好的展示各参与者的职责。对于数据流图，按照标准化一般是分级绘制，但是需要注意几点。首先顶层数据流图与实体之间的输出与1级数据流图的输出要保持一致；其次数据流图里面包含控制流信息，如果系统复杂，可以将控制流图与数据流图分开，但是要和数据流一一对应，数据流一般使用实线，控制流一般使用虚线。1级流图一般包含的是功能模块。三、数据体系好了，通过流程图章节，我们可以基本掌握软件的业务和数据走向。在数据体系章节里，我们就需要说明白各数据流的含义了，因此我们需要定义数据结构，数据传输使用的是什么协议。这样数据流图里的各种数据流就变得具体了。四、接口说明这里主要会绘制软件的外部接口图和内部接口图，接口图可以清楚的看到各模块之间的调用关系，并且主要描述的是数据的传输协议与数据，数据按照接口说明里的描述方式发送或者接收数据，方便开发者进行编码活动。五、说明这篇文章记录了当时对需求报告文件的理解，以上理解存在一些问题。本文问题：本文《需求报告的理解》将需求阶段的理解比较模糊，描写的内容既不像需求调研报告，也不像需求规格说明书，混为一谈了。后期工作：在需求阶段有哪些重要的过程节点，每一节点过程中需要输出哪些文件？Tips调研究竟调研应该从下（基层员工）向上（VP）还是从上往下走，很多人选择了从下往上，但是在具体开展的过程中，会发现从上往下走会相对正确。需求调研搞定人很重要，弄清楚调研对象的环境很重要。以某企业为例，部门间矛盾会导致需求人员输出结果被其余部门否定，导致调研返工，甚至于作废，这个时候应当建议公司商务介入做好客户关系没有与客户达成需求调研的目标和交付成果，造成耗费大量人力而最终没有产出的东西，只是一堆反映需求的过程文件。调研结果需要有正式文档输出，调研的最终结果需要用户确认，最好以邮件的形式，否则后续容易扯皮.项目负责人缺乏对于过程文件的管控，没有相应的审核的标准，也缺乏相应的及时反馈机制，导致结果的输出不是客户想要的内容从实际的调研过程来看，部分行业，如金融行业一般都会提供SOW，整个需求调研的过程也比较规。范部分行业，如政府项目，一般都不会提供相关的资料，需求确认也需要一定的技巧。需求获取的三阶段：需求背景、需求调研、需求分析□完成了需求的调研，就进入到了对需求进行分析的第三阶段，在这个阶段就要理解需求、分析需求、最后确定系统需要实现的功能需求。□调研方法分为三篇，第三篇介绍“需求分析”的作用和方法。需求分析，是对收集到的需求进行细致的分析、研判，准确地理解客户的目标、业务等对信息化的需求，最终将这些需求转换为准确的功能需求定义。需求分析阶段的主要工作有三个1）对收到的需求根据内容进行分层梳理，以利于进行分析；

2）对分层的需求进行转换，以确定系统要实现的功能需求；

3）将分析成果汇总成为【需求规格说明书】，该资料的用途有两个□对客户：确定了系统需要开发的全部内容，是客户验收系统的依据；

□对软件商：是系统的规划、设计，开发、测试、交付等全实施流程的依据；一、需求的分层与作用对收集到的需求按照不同的层次进行归集、划分：1.第一层：目标需求

□提出者：项目投资人、产品购买者、实际用户的管理者、信息中心负责人等；

□需求内容：企业导入系统的目的，信息化目标、企业战略、理念、希望、价值等；

□需求作用：用于指导系统的顶层设计，对业务需求转换的指导等；2.第二层：业务需求

□提出者：包括企业的经营者、部门管理者及员工，从业务管理层面提出的需求；

□需求内容：对系统对应的业务范围、流程，规则、标准、规范等提出的需求等；

□需求作用：用于指导对企业的业务架构、操作功能规划、业务流程的优化等；3.第三层：功能需求

□提出者：包括所有未来的系统用户；

□需求内容：给出系统必须提供的功能需求、以及对该功能需求的具体描述。

□需求作用：它是后续进行系统设计、系统开发、测试验证的具体依据；二、需求的转换需求调研收集的需求采用的是图形、文字和表单的形式，要分别从这三种形式中识别出最终要的“功能需求”，由于目标需求、业务需求直接看不出来是需要什么系统功能，因此要将它们按照“目标需求→业务需求→功能需求”的顺序进行转换，最终识别出全部的功能需求，这个功能需求就是后续要进行设计的系统功能依据。1.目标需求

目标需求不能直接给出对应的功能需求，因为目标需求是用目标、理念、思想、价值等抽象化的形式表达的，因此针对目标需求必须首先找到其对应的业务场景，也就是要先将目标需求转换到业务需求上。2.目标需求向业务需求转换

在调研时会发现客户熟悉自己的业务，但是并不清楚自己的需求对应的是什么样的软件功能，所以他们通常采用描述业务处理过程的形式说明自己想要完成什么任务，然后再通过与需求分析师的沟通、分析，最后转换成为功能需求。3.业务需求向功能需求转换

进入了功能需求阶段，就没有转换作业了。由于客户不一定理解信息系统的设计与开发工作，因此要对由他们提出来的功能需求进行甄别：是否是真实的需求？该需求的可行性？提出的功能需求是否有重叠？在“人-人”环境中需要的功能在进入到“人-机-人”环境中是否还需要？等等。三、需求规格说明书需求规格说明书是对前述的所有需求准备、调研和分析成果的总结。主要包括有□引言：包括项目目的、背景、用语等基础信息；

□项目概述：对项目自身的说明、包括范围、主要处理对象、与其他系统的关系等；

□功能需求：本项目具体的规划、架构层、功能层、数据层需求的详细说明等；

□非功能需求：对未来系统的性能、安全、扩展等的需求等；

□技术需求：接口、架构、硬件、网络、部署等；

□各类措施：质量保证、验收标准等；附：解决方案

对需求调研和分析的成果还有另外一种使用形式，即：解决方案。解决方案的目的是对客户进行概要说明，相对于需求规格说明书来说，解决方案包含的范围更加广泛、深度浅一些。解决方案也有其重点强调的内容，例如：□项目的目的、基本功能展示、导入信息化系统的价值、既有问题的改善、未来规划等内容；

□项目周期、里程碑计划、项目执行计划、项目开发金