需求调研的评估方法问题(需求分析有哪几个步骤)
1.需求分析有哪几个步骤
一、需求获取阶段
在需求获取阶段，需要做好收集和管理两件事。
这些需求既有产品经理主动挖掘的，也有从用户、运营、业务方、领导等渠道被动获取的，无论哪个渠道来的需求，都需要有一个正式的地方进行管理，也就是我们通常所说的需求池。
不过，对于多方关注的重点需求，通过需求池来向各方同步就不太合适了：
一是因为需求池内容太多、太杂，向业务方、领导汇报的时候会有很多干扰信息，难以快速抓住重点；
二是因为需求池里面可能有些需求不适合完全公开。
这时我们就需要使用《事项跟踪表》来单独跟进，形式上用Excel、PPT都可以。
而放在《事项跟踪表》里的需求，也要在需求池里记录下来，即需求池是做全量需求管理的，《事项跟踪表》是做重点需求跟进、汇报的。
二、需求分析阶段
1. 分析内容
需求分析主要从需求要素、定位、分解、优先级四个方面进行。
1）需求要素分析
需求要素分析是从需求本身出发，不考虑其他因素。
这些要素包括：内容、用户/角色、频次、价值、场景-动机、强度六个方面，这些要素的含义大家应该都比较清楚了，这里说一下分析各个要素的目的是什么：
分析需求内容，是为了弄清楚需求是什么；
分析需求用户/角色，是为了弄清楚需求为谁服务；
分析需求频次、强度，是为了弄清楚需求对用户的重要性、紧迫程度；
分析需求场景-动机，是为了弄清楚需求真伪、用户目的，更深入的理解需求；
分析需求价值，是为了弄清楚需求值不值得做。
2）定位分析
需求的定位分析是分析需求对产品当前阶段目标的意义。
分析需求的定位，有以下两个目的：
一是作为优先级排期的判断条件之一，如果需求与产品当前阶段的目标密切相关，则需要作为高优先级上线；
二是为了框定需求范围。每个需求的实现程度都有深有浅，可以很简单，也可以很复杂，了解了需求之于产品的定位，就能判断需求要做到什么程度。如果一个需求对产品很重要，那就需要做得很丰富，如果只是辅助需求，则需要适当轻量。
3）需求分解
原始需求的颗粒度往往较粗，不利于后续的分析、设计、开发等工作，所以我们需要对这些颗粒度较粗的原始需求进行分解，分解为一个个完整、独立、可实现的子需求。
4）优先级分析
优先级分析是以拆解后的子需求为单位进行的，根据各类优先级的判断方法、原则，初步评估各个子需求的上线顺序及时间。
2. 常见问题
需求分析应该是大家从入行那天就知道要做的事，但大多数同学在做需求分析时会犯以下三个比较常见的错误。
1）缺乏系统性
这是在分析中最常见的问题，即很多同学在分析需求时没有系统性的框架，导致很多方面没有分析到、考虑到，从而对需求认识不全面。
2）缺乏深度
对需求某些要素认识比较浅，不够细致深入，例如在分析需求的用户时，没有对用户分层、切片，对各个分层的用户也缺乏足够的了解，导致对用户只有一个笼统、模糊的认识，最后自然无法深入进去。
不过分析是否有深度的定义其实很难把握，也缺乏明确的判断标准，需要随着分析者思维能力的提升、信息量的提升来加强。
2.需求调研的几种错误观点
1）快速原型法，可以替代需求 软件工程项目中，经常会遇到这样一种尴尬的局面，我们调研完需求，做完设计，代码也编写的差不多了，这时请客户过来一看，客户却惊奇地发现这根本不是他们想要的东西。
为了让客户更早更快的对将要建成的软件系统，有直观和感性的认识，我们便建立一个系统原型，用于给客户做演示。客户在我们演示和讲解的时候，马上就可以发现问题，而我们甚至可以现场修改原型，直到客户满意为止。
从理论上说，快速原型法确实几乎没有任何问题。但实际情况并非如此。
第一点，也是最重要的一点，快速原型法无法解决需求主线的问题。关于需求主线前文已经讲得很多，而调研需求主线的禁忌中，就特别提到不可以上来就做原型。
说直接点，你是做了某个模块或功能的原型，而且这部分原型也得到了客户的认可，但项目中真的需要这个模块或功能吗？另外更可怕的一点，当你宣告整个项目的原型已经制作完毕，并且全面得到了用户的认可，而那些必须有的需求主线，真的全部包括进来了吗？ 第二点，快速原型法背后还隐含了一个假设，客户就有极高的计算机素养，非常清楚自己需要什么样的系统，他的认可就标志着原型已经合理且完善。但现实中，绝大多数情况下，这种假设是不成立的。
我们知道，客户方的角色实际至少可以分为两个部分：项目发起人与项目负责人。发起人多数是职能部门，而负责人是IT部门。
你能指望职能部门的最终使用者，能有多大的概率说清楚自己到底想要什么。 第三点，再好的原型，它的层次感也要弱于建筑行业的沙盘或效果图，这使得原型演示不可能完美的表达软件系统建成后的效果。
以大楼建设为例。我们可以用幻灯片或沙盘的方式，首先展示建筑的外部环境、外观设计。
然后再进入到某一层的楼层布局设计图，在进入到该楼层某个房间的布局设计图。这些甚至可以用3D的方法演示出来。
再配合讲解，就能够使客户非常清晰全面的了解到整个设计。 我们知道，一个大型软件系统，可能包含几十个大模块、上百个小模块，成百上千的界面，而涉及到按钮、功能键、数据输入和显示等细节甚至多达数万个。
这样庞大的软件系统，要去演示它的软件原型，我们就只能在屏幕上，演示一个又一个的界面，根本无法遵行从整体到局部再到细节这样一个流程来展示。 这样的一种情况，相当于在建筑行业中，客户要求你盖一栋商业、办公综合性大楼，而你给客户演示的幻灯片，却只是一大堆的房间、厨房、卫生间、甚至于类似排气扇、开关之类非常细枝末节的东西。
又如何让客户提意见，客户又从何提起？只见树木，不见森林，说的就是这个意思。 在快速原型法相关知识普及率如此之高的情况下，软件项目失败率依然居高不下，其最根本原因，就在于此。
在笔者看来，只有当需求分析已经细化到具体某个界面的时候，快速原型法的好处才能真正体现出来。而在此之前的仅仅只能用于确定界面布局，以及界面风格。
否则将不会对项目有多少帮助。 2）迭代次数越多，越能贴近用户需求 曾经有一次到一个朋友公司去谈事情，到朋友的办公室的时候，恰好有一个项目经理正在汇报项目进度。
朋友知道我也是做软件工程管理的，就让项目经理继续汇报。当时项目经理说的有一件事情记忆特别深刻：“现在的原型和设计已经进行到第5次迭代……”。
似乎迭代次数越多，就代表项目越能取得成功。 完成一个软件项目，特别是大型的软件项目，总是需要很长的时间，为了避免在项目已经进行到尾声的时候，才发现原来和用户的要求有很大的差别，于是产生了迭代法。
迭代的方式如下，假如这个项目要求6个月交货，我在第一个月就会拿出一个产品来，当然，这样会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样就知道自己距离客户的需求有多远。 回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。
就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。 对比快速原型法和迭代法，就可以发现它们所需要解决的核心问题是一样的，那就是如何应对和适用客户需求在项目实施过程中的变化。
实际上快速原型法中就包含了迭代的意思。它的目标是争取在设计、编码开始前，将客户的需求稳定下来。
而迭代法则走得更远，它发现在客户需求变化几乎贯穿了软件工程项目的整个过程，而不仅仅是在需求调研过程之中。于是迭代法就包含设计迭代、代码迭代、测试迭代。
但迭代法的同快速原型法一样，它重点仍然是着眼于如何应付需求的变化上，只是把变化扩展为整个开发过程。也因此，迭代法仍然无法摆脱上述快速原型法中，讲到的只见树木不见森林缺陷。
3）敏捷开发和极限编程，可以应付需求变动 敏捷开发这个词很好很形象。它使我仿佛看见一幅场景：两个人正在做游戏，一个人不停的丢出鸡蛋，而另一个人则敏捷地接下所有的鸡蛋，避免它掉在地。
3.市场需求预测有哪三种方法,其优缺点各是什么
1.定性预测方法。主要是通过社会调查，采用少量的数据和直观材料，结合人们的经验加以综合分析，作出判断和预测。它是以市场调研为基础的经验判断法。具体方法主要有：购买者意向调查法 、销售人员意见综合法、专家意见法、市场试销法。
2.定量预测方法。是依据市场调查所得的比较完备的统计资料，运用数学特别是数理统计方法，建立数学模型，用以预测经济现象未来数量表现的方法的总称。运用定量预测方法，一般需具有大量的统计资料和先进的计算手段。定量预测方法大致可分为两大类，即时间序列预测方法和因果分析预测方法。时间序列预测方法主要有：水平型发展趋势、线性变化趋势、二次曲线趋势、对数直线趋势、修正指数曲线趋势、龚佩子曲线趋势。因果分析法的主要工具是回归分析技术，因此又称其为回归分析预测方法。运用回归方程进行分析预测的方法主要有 三种：一元回归预测、多元回归预测、自回归预测。
4.社区需求评估包括哪些
1、社区需求评估包括两大方面：
(1)社区共同性问题（社区需求与问题评估）；
(2)社区群体性问题（服务对象群需求与问题评估及服务对象需求与问题评估）。
2、社区需求评估的目的：
(1)确认社区的需要、关注点与问题；
(2)建立社区服务的发展目标；
(3)帮助社区采取必要的行动；
(4)判断社区的需求是否发生了变化；
(5)收集社区的希望、梦想和愿望。
扩展资料：
社区拥有的三大类资源：
1、人力资源：社区中所有的个人的体力、技术、智慧、助人意愿以及人际关系等。（重视的对象：社区领袖、专家、学者、领导人、社工、志愿者）。
2、物力资源：用于社区服务的场地、设备。
3、财力资源：社区服务所需的经费，来源——政府、社会捐助、服务收费。
参考资料来源：百度百科 - 需求评估
5.软件工程中常用的需求分析的方法有哪些
一、过滤需求的方法做后端系统，要学会的第一个技能就是砍需求。
也就是过滤需求。这不是一个贬义词，反而是体现后端产品价值判断的基础。
过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。1. 用户场景模拟法后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。
如果不能帮助用户，那么这个需求就可能是伪需求。以下面的案例说明：背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。
需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析：调研到业务操作场景，是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。
也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。因此，该需求是个伪需求，应该被过滤掉。
2. 功能归属分析专门的系统做专职功能，有助于合理的产品体系建设。因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。
如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。
需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。
所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。
结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。
二、拆分和聚合的方法1. 拆分需求法业务用户提出一个需求，很可能只是短短的一段话。但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。
每个需求点再当做一个子需求进行调研，最后再聚合在一起。以下面的案例说明：背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。
需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。
这里不一一展开。2. 聚合需求法拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。
例如：由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。
然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。三、利用辅助功能调研需求调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。
比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。
看看下面的例子：背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。
需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析：需求是很明白的，也有它的意义，但有风险。
因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。
于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。测试法就像是探雷一样，主要用来解决未知风险点。
这个方式的重点是记录和分析操作前状态、操作位。
6.市场调查常用的方法有哪些,各自有什么优缺点
市场研究分为定量访问和定性访问。
定量访问指：大量访问普通的消费者，从而分析普通消费者的情况。一般最少80样本以上，最多可达数万甚至十几万样本。
定性访问指：访问特定的消费者，以得出特殊人群的共性。根据不同的形式，样本量在4个样本到几百样本不等。
定量研究的方法有：
电访访问（CATI）：优点是可同时访问不同城市、地区的消费者，完成样本速度快、费用低，质量可控性强。缺点是无法准确找到特殊条件的消费者，无法执行渗透率低的项目。无法出示图片和广告。
街访：优点是可通过选取街访点，有针对性的访问不同阶层的消费者。且面对面的访问更便于出示图片和广告。缺点是被访者的随机性不够强，受街访点影响，被访者有一定的倾向性。
入户：优点是可以准确的抽取不同的区、街道、地址，使得样本分布均匀。可留置产品，使用 后再作回访。缺点是质量可控性相对较弱。
在线访问（online）：优点是可由被访者在方便的时间自行上线填写，可出示图片和广告，减少访问员参加的环节，避免因访问员理解或听力问题造成的误差。缺点是难以确定被访者是否认真填写（一般通过强制访问时长来限制），难以区分填写过程中是否换人。
定性访问有：
座谈会：优点是客户可在现场观看，并随时补充需要了解的问题。缺点是一般座谈会访问8人（最少4人，最多12人），如其中个别被访者的预约质量有问题（如两两相识或条件造假），则整个座谈会的访问结果都会有偏差。
深访：优点是能深入了解特定消费者的深层需求和意见。缺点是，对访问者本身有较高的要求，深访访问的要求和定量访问截然不同，如访问员深访经验不足，不能随机应变的挖掘被访者的深层想法，则所能得到的信息有限。
有任何问题请追问，希望满意，~
7.需求分析的步骤有哪些
一、需求识别 需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。
1.需求类别确认：需求类别包含流程类需求、统计分析类需求、接口类需求，一个需求可能为某一类型需求，也可能包含多类需求。确认需求类别后应对每类需求的数量进行初步分析（比如流程类需求包含几个流程、统计分析类需求包含几个报表、接口类需求包含几个接口）。
2.需求复杂度分析：一般需求受理工作量在1-5人天的需求复杂度低，工作量在5-15人天的需求复杂度中，工作量在15人天以上需求复杂度高。（工作量表示需求受理全过程需求人员需要付出的工作量）。
3.价值分析：需求人员收到需求后应根据收集需求内容初步分析需求痛点/目标、需求复杂度、业务重要程度确定需求价值，需求价值分析 二、业务流程/统计查询/接口分析 针对流程类需求必须进行业务流程分析，统计查询和接口类需求可不进行详细的流程分析。1.业务流程分为部门级、组织级和岗位级 部门级流程关注脉络需要分析涉及哪些具体岗位、执行活动、每个活动之间的关联关系，它是需求分析的主线条，也是流程分析的主要产物。
组织级流程关注宏观一般不会直接绘制，是对部门级流程的概括和抽象。岗位级流程关注每个业务活动的执行步骤属需求细节范畴，在流程分析阶段不要过度进入细节。
2.需求识别阶段确认的流程均为部门级流程 需求人员在进行流程分析应遵循如下方法：（1）业务流程确认：一个流程为一个业务事件，一般是外部角色发起或系统内部主动发起（比如时间事件或状态事件），发起后会触发一系列业务活动。（2）角色及业务活动确认：流程图中的每个泳道都必须对应到角色，每个角色对应多个业务活动。
需求人员在确认业务活动时一定要保证活动的粒度，一个业务活动一定是由一个角色完成且每个业务活动都是有价值的活动。比如项目输入项目名称是一个执行步骤，这个动作没有价值，项目经理查询项目信息就是一个业务活动。
在需求描述时针对线下活动或新增活动应该应标识区分。（3）业务活动间关系及数据确认：确定所有业务活动的前后置关系，并明确流程间的传递的数据实体。
（4）流程整体瓶颈分析：一般若某个角色业务活动工作量较大，或流程涉及高级领导，一般都会造成瓶颈，这种情况需求人员应想办法分散工作量提出流程优化建议。3.针对统计查询类需求及接口类需求，按照上述业务活动确定原则分析、确定角色，并明确每个角色所执行的业务活动即可。
三、数据实体分析 针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件和查询展现两类数据实体、接口类需求需要分析接口传递数据实体，具体分析包含如下内容：1.明确数据实体：确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。2.明确所有数据实体间关系：实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它数据实体。
3.明确数据实体字段：针对新增数据或改造数据实体需要明确新增字段的名称、字段类型、是否必填、字段取值方式（人工输入、系统自动继承自其它数据实体、系统自动计算需要明确计算公式）。4.数据权限分析：需要分析不同角色在数据权限方面的差异，若涉及纵向多级用户，要说明对于集团/省/地市用户的数据隔离。
四、角色及使用场景分析 一般来说每个业务活动是对用户使用场景的抽象，每个业务活动可能包含多个场景，分析使用场景时应按照业务活动为主线逐个进行分析，每个业务活动分析时应包含如下内容：1.明确活动执行角色。2.明确活动执行的前置条件和后置条件。
3.明确不同场景：一个业务活动可能包含正常的使用场景、备选使用场景和异常使用场景；4.明确每个场景的执行步骤：描述执行步骤时应使用简单的语法，主语明确语义易于理解，每个步骤不应该在任何一方（执行角色、系统）停留两部以上，重点描述如何交互。5.业务规则和约束：明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则（比如项目周期时长超过90天必须提交二级领导审批），或与数据实体相关的数据规则（需求交接单拒收时候必须填写拒收原因，且拒收原因不能超过500字）。
五、系统功能分析。
