需求确认方法有哪些

① 如何确定课程的培训需求

制定培训需求调查计划
培训需求调查计划是保证培训需求调查顺利开展的前提，制定一个完整的培训需求调查计划，主要有以下几个步骤：
1.确定培训需求调查目标
调查工作应达到一个什么样的目标，一般而言，是完全确立某种培训的需要。但由于在培训需求调查中会有各种客观或主观的原因，培训需求调查的结果并不是完全可信的。因此，要尽可能排除其他因素的影响，提高培训需求调查结果的可信度。
2.选择培训需求调查方法
培训需求调查方法包括面谈法、重点团队分析法、工作任务分析法、观察法、问卷调查法等等。
根据企业的实际情况以及培训中可利用的资源选择一种合适的培训方法。一般来说，工作任务安排非常紧凑的企业员工不宜对其采用面谈法；而专业技术性较强的员工一般不用观察法。
3.明确培训需求调查内容
分析培训调查应得到什么资料，除去手中已有的资料，就是调查内容。调查内容不宜太广泛，对一项内容应进行多角度调查。一般来说，培训需求调查的内容包括企业全体员工基本情况分析，员工知识、技能和态度分析；培训环境因素的分析等等。
制定一份合理的培训需求调查计划有利于培训需求调查工作的开展。而制定一份调查计划就必须确定目标、选择方法和明确内容。
实施培训需求调查工作
有效地实施培训需求调查工作是获取培训需求信息的关键。在开展培训需求调查时，应明确以下问题：
1.了解受训员工现状
(1)了解员工在组织中的位置。不同职位的员工有不同的培训需求。
(2)以前是否受过培训，要尽可能避免内容相同的培训。
(3)员工有过什么样的培训。
(4)培训的形式有哪些。培训形式上的选择应该尽可能地丰富，这样才能提高培训效果。

② 沟通如何确认对方的需求

收集信息和发现需求时 开始和结束谈话 控制谈话方向时 制止别人滔滔不绝的谈话时 征求别人意见 不明白或不相信需要确认时提出建议时处理异议时有效应用两种提问方式: 通 常, 我 们 会 用 开 放 式 问 题 开 头, 一 旦 谈 话 偏 离 你 的 主 题, 用 封 闭 性 问 题进 行 限 制, 如 果 发 现 对 方 有 些 紧 张, 再 改 用 开 放 式 问 题。 避免无用的问题：引导性问题多重问题 积极聆听的作用： 为了获得更多信息 帮助把谈话继续下去 处理不同的意见 有效发表自己的意见 保持沟通气氛的友好  反省自己是否做过: 当别人讲话时,你在想自己的事 听别人讲话时,不断比较与自己想法的不同点 打断别人的讲话 为讲演者结束他的讲演 当别人讲话时谈论其他的事情 忽略过程而只要结论 仅仅听那些自己想听的或希望听的事和内容 是否人的外观或他们的说话方式给你客观的听造成困难是否很容易被其他的背景或声音分散注意力

③ 我们应当怎样做需求确认：评审与签字确认会

时间过得真快，经过一系列需求研讨、需求分析和整理确认，我们整理出了需求列表，编写出了需求规格说明书，一切似乎该到结束需求分析阶段的时候了。但是，敏捷大师的一句话让我们彻底心凉到了骨头里。敏捷大师说了，我们不可能在需求分析阶段完成所有的需求分析工作，它将延续到设计、开发，甚至测试阶段。 一直以来，我对这句话非常困惑。既然需求分析阶段不能完成所有的需求分析工作，那么完成多少才算结束呢？80%？60%？或者更少？大师没有给出一个标准。大师就是大师，生活在太空里的，我们慢慢理解吧。经过多年的实践，我慢慢理解了。我们说这种需求分析工作不可能完全完成，或者说日后用户的需求会变，其实并不是毫无规律可循的。通常，用户对需求的变更只发生在某些固定的范围内，弄清楚了这些范围，我们的问题就迎刃而解了。 1. 整体需求不变，具体细节变化。我们说需求是分层次的，整体框架、功能模块、每个操作的细节。如果用户变更到了将整个框架都推翻了，这个项目就别做了。所以整体框架是必须在需求分析阶段完成的，是日后不可能改变的。功能模块可能要变，但通常是某个部分在变，而更多的是那些具体操作的细节在变。 2. 界面风格与操作易用性是最容易发生变更的。我们说用户看到软件以后不满意，其实主要是对界面风格与操作性不满意，而不是软件功能。界面不够美观，操作不方便，不符合用户的操作习惯，都是造成用户不满意的地方。 3. 增加其它功能。软件是对现实的模拟，而现实也是复杂多变的。我们与用户在进行业务流程分析时，也许一些流程没有考虑到，或者还有特殊情况需要处理。这些是客户要求增加功能的主要动因。 OK，万事俱备只欠东风，当所有工作都完备以后，我们的需求分析工作开始进入最后收尾的阶段。我们说，需求分析阶段的产出物是需求列表与需求规格说明书，而最终结束的里程碑无疑就是需求评审会了，或者说与用户的签字确认会。 需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。从理论上说，需求评审会应当由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理，还有公司相关领导参加。但实际上，让如此多不同角色的人聚集在一起开会是不现实的。因此，我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实。 处理外部问题，必先要从内部统一思想。先召开一个内部评审会，听听系统架构师、设计人员、测试人员、QA经理对需求分析工作的意见，然后由领导讲讲话，布置一下后面的工作，是十分有必要的。按照我的经验，系统架构师这时的作用相当重要，他应当仔细阅读需求，仔细思考技术是否可行，以及预测该系统是否能够达到用户方领导对该项目制订的目标。如果答案是否定，立即进行调整。 最后就是与用户的外部需求评审会了。外部需求评审会，也可称为签字确认会议，就是与用户就需求规格说明书进行评审，最后签字确认。用户签过字的东西，不可能完全抑制住用户的变更，但至少从很大程度上抑制住了用户的大改。然而，在召开外部需求评审会之前，我们建议大家就需求规格说明书，先与各个单位或部门的用户代表讨论并确定下来，避免在最终的签字确认会上出现分歧，影响工作进度。毕竟大家都不容易，工作一大堆，聚在一起不容易。 经过数月的分析讨论，最终在一片和谐的气氛中，双方领导在需求规格说明书上签字，项目开始进入一个新的轮回。在这个轮回中，是焦头烂额、不胜其苦，还是如履薄冰、最终顺利交付，是与许多因素有关的。但我想说，一份高质量的需求分析必定起到决定性的作用，必定为日后的软件开发扫清了许多许多的地雷。 我们应当怎样做需求分析我们应当怎样做需求调研：初识我们应当怎样做需求调研：拜访我们应当怎样做需求调研：研讨会我们应当怎样做需求调研：需求研讨我们应当怎样做需求调研：迭代我们应当怎样做需求调研：需求捕获（上）我们应当怎样做需求调研：需求捕获（下）我们应当怎样做需求分析：功能角色分析与用例图我们应当怎样做需求分析：业务流程分析（上）我们应当怎样做需求分析：业务流程分析（下）我们应当怎样做需求分析：用例说明我们应当怎样做需求分析：查询报表分析我们应当怎样做需求分析：子用例与扩展用例我们应当怎样做需求分析：行动图和状态图我们应当怎样做需求分析：业务领域分析我们应当怎样做需求分析：原文分析法我们应当怎样做需求分析：领域驱动设计我们应当怎样做需求分析：非功能需求我们应当怎样做需求确认：需求列表我们应当怎样做需求确认：一个需求列表的实例我们应当怎样做需求确认：快速原型法我们应当怎样做需求确认：需求规格说明书（全文终）

④ 如何精准确定用户的需求

实事求是的说，发现用户真正的需求比较难。人的心理都不一样，你这样想，人家不一定这样想。
比如说，我们每天都在用的微信，有的人觉得设计的挺好，有的人就觉得不能传送大的文件，不如QQ。等等，想发现用户真正的需求，可以从以下几点着手
1、观察他的社交软件，用心体会客户是怎样的人，有着怎样的爱好。
2、用心交流，发现客户需求。
3、可以通过做调查问卷发现需求。

⑤ 1、 什么是培训需求 2、 确定企业培训需求的方法有哪些 3、 各种方法的使用范围

1.培训需求：简单说就是你的客户需要什么。想要什么。缺什么。然后你们公司打算补充说明。有什么地方需要改进的，同时又没有什么好的方法。这个就是培训需求了。
2.方法其实很多，一般建议先了解一下他们企业的背景，企业文化，所在行业，企业性质，然后电话联系，确认对方是不是需要培训，如果需要培训，大概的时间是什么时候，打算在那些方面得到提升或者改进，打算投入的费用是多少（这个很重要，高了还好，要是低了，就很麻烦。基本上要花很长时间。），确认对方的意向，最后在是问卷调查，员工面谈。
3.电话：范围最大，只要对方有意向，有时间都可以去联系
调查表：这个属于拜访的时候的利器，可以让你从客户手中的到很多资料。
拜访：拜访这种情况最好的前提是客户能够让有分量的人出来和你沟通。要不再怎么沟通都是扯淡，没有什么意思。最好是直接把公司老板弄出来和你沟通。基本上这个就是一锤定音了。

⑥ 软件工程中常用的需求分析的方法有哪些

一、过滤需求的方法
做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。

这不是一个贬义词，反而是体现后端产品价值判断的基础。

过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。

1. 用户场景模拟法
后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。

如果不能帮助用户，那么这个需求就可能是伪需求。

以下面的案例说明：

背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。

需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。

分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。

因此，该需求是个伪需求，应该被过滤掉。

2. 功能归属分析
专门的系统做专职功能，有助于合理的产品体系建设。

因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。

如果不属于该系统范畴，那么直接说服需求方更换方案。以

下面的案例说明：

背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。

需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。

分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。

所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。

之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；

其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。

结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。

否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。

二、拆分和聚合的方法
1. 拆分需求法
业务用户提出一个需求，很可能只是短短的一段话。

但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：

先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。

每个需求点再当做一个子需求进行调研，最后再聚合在一起。

以下面的案例说明：

背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。

需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。

该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：

自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。

这里不一一展开。

2. 聚合需求法
拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：

由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。

然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。

三、利用辅助功能调研需求
调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。

比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。

最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：

背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。

需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。

分析：需求是很明白的，也有它的意义，但有风险。

因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。

因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。

于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。

测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。

四、“拔萝卜带出泥”的方式调研需求
调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。

举例说明：

背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。

需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。

分析：

第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……

第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……

通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。

罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。

⑦ 如何进行需求管理

需求管理源于业务需要，始于需求挖掘，继而需求分析，需求定义，需求验证。周而复始。

一，业务需要说明需求产生的原因，可能是高层制定的目标，中层对工作流程的调整，基层碰到无法解决的问题，用户需要，外部环境变化，竞争对手策略变化或者政府政策调整等。
需求人员在明确业务需要时，首先明确干系人，其次获取干系人要求/需求。可以采用的方法包括：行业基准（竞品），业务规则分析（产品分析），头脑风暴，焦点小组，功能分解，根源分析等。
二，需求挖掘阶段的目标是找出干系人的真实需求。单方面的口头描述或者规范章程都可能与实际需求相差甚远，因此需要需求人员收集各方面需要，交叉验证，合理推导，发掘出用户的实际需求。
工作步骤：确认干系人，收集实际情况，整合多方面信息，确认实际需要。方法包括：访谈，观察，问卷，焦点小组，头脑风暴，可用性测试，竞品分析，数据分析，文档分析，咨询专家等。
三，需求分析阶段则是对已经收集的真实需求进行规整，包括两部分内容，组织整理需求和对需求排优先级。
组织整理需求采用相同粒度描述需求，并描述需求间关系。主要方法包括：功能分解，业务规则分析，数据模型，流程模型，范围模型，用户经历，场景和用例，组织模型。
需求优先级划分通过定义需求的优先级，为计划安排提供有价值的参考。可以参考的定义维度包括：时间，预算，业务价值，业务和技术风险，实施难度，成功可能性，规范和政策，与其他需求的关系，与干系人的协议，紧急程度等。可采用3/4级优先级定义，或者MoSCoW模型定义，其中M=必须 S=应该 C=能够W=将要。
四，需求定义主要工作为根据前期整理的相关文档整理需求说明。输出包括：业务需要，需求陈述，组织整理后的需求以及需求优先级。需求说明主要包括：业务需要，业务需求和系统需求。·
五，需求验证包括需求检验和需求确认，即需求过程中的检查和需求完成的测试。
需求跟踪矩阵是个好东西，可以在需求分析阶段产出。

⑧ 确定信息需求的三个步骤

收集需求，分析需求的重要性，确定需求。

1、需求优先级的定义应根据当时的环境和实际情况，是否有足够的理论支持和数据支持，满足需求后的分析结果是否清晰等。当定义一个需求是否被确定为一个明确的需求时，这些都被考虑在内。

2、有四个要求优先：重要和紧急；重要和不紧急；紧急和不重要；不紧急和不重要。这四种情况也是我们处理需求优先的原则，即重要性＋紧迫性。

3、还应考虑需求的风险与价值之间的关系。高价值－高风险的功能需求应优先考虑，即优先考虑获得高价值回报，而早期处理可以有效地消除重大风险。

4、对于高值低风险的功能需求，所提供的价值是等价的，但由于风险较低，可以以后进行。

5、对于低价值低风险的功能需求，应该排在第三位，放弃它们对产品总价值的影响很小，而且风险也很低。

6、对于低值高风险的功能需求，显然最好尽量避免开发或推迟工作。

(8)需求确认方法有哪些扩展阅读：

信息需求的内容构成

1、信息要求，包括信息内容和形式的要求。信息的内容反映了信息所属的学科，如“生物信息”、“经济信息”、“环境保护信息”；信息的形式多种多样，如“知识信息”或“信息信息”、政策信息、市场信息或“产品信息”。

2、对信息源的要求，包括信息源的范围和载体形式。用户对这些方面有不同的要求。

⑨ 我们应当怎样做需求确认：快速原型法

常常听到许多朋友跟我埋怨，需求分析之难，就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的，一到软件上线的时候就不是那么回事了，这可没法整。但我们只要坐下来仔细分析就会发现，在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。但是，用户不是傻子，当你软件上线时，他拿到了实物了，知道软件做成啥样了，一旦不满意他就开始提变更了。所以，需求分析的症结就在与这个实物。 既然症结在此，毫无疑问，我们就应当在需求分析阶段拿出实物，用实物与用户确认需求，这就是快速原型法的基本思想。快速原型法，简称原型法（Prototyping），是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再提出一些新的需求以后，再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。 原型开发的快速与模拟到什么程度，是一对矛盾，我们要去把握。要快速开发，必然不可能和最终交付的软件系统一模一样，许多复杂问题被简化，非关键性流程被忽略，这就是所谓的模拟。因此，模拟到什么程度是关键，既能说明问题，又不耽误时间。根据我的经验，一般能拿出界面，并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能。 当用户拿到原型可以自己操作时，需求研讨的气氛立即变得不太一样了。当用户享受原型给他们带来体验的快感时，需求被源源不断地被提出来。这时候的需求，就不再是枯燥无味的文字游戏，而是生动形象的图形界面。日后，如果项目采用迭代开发，让用户看着软件一点儿一点儿地成长，这又是多么美妙的体验啊。与此同时，你与用户的信任也在一步一步建立起来，软件风险在降低，项目将朝着正确方向前进。 快速原型法是美妙的，它给你与用户带来了从未有过的体验。但美妙的同时，也会带来一些的尴尬，不必要的误会，我们一定要注意。最常见的误会就是让用户将原型误以为最终交付的系统。开发一个系统需要持续数月，但你倒好，几天就搞定了，为什么还要在这个系统上投入大量资金呢？如果对方领导开始有这样的想法时，双方就开发费用进行的谈判就有一些不妙了。所以在给用户看到原型前，一定要跟用户解释清楚。 既然是原型，必要的校验、非正常操作的处理通通都被忽略。因此，当演示原型出错时，用户你可千万不要较真哟！这丑话可得说在前头，否则用户跟你较起真来，你在用户心目中的形象可就要大打折扣了。 我们应当怎样做需求分析我们应当怎样做需求调研：初识我们应当怎样做需求调研：拜访我们应当怎样做需求调研：研讨会我们应当怎样做需求调研：需求研讨我们应当怎样做需求调研：迭代我们应当怎样做需求调研：需求捕获（上）我们应当怎样做需求调研：需求捕获（下）我们应当怎样做需求分析：功能角色分析与用例图我们应当怎样做需求分析：业务流程分析（上）我们应当怎样做需求分析：业务流程分析（下）我们应当怎样做需求分析：用例说明我们应当怎样做需求分析：查询报表分析我们应当怎样做需求分析：子用例与扩展用例我们应当怎样做需求分析：行动图和状态图我们应当怎样做需求分析：业务领域分析我们应当怎样做需求分析：原文分析法我们应当怎样做需求分析：领域驱动设计我们应当怎样做需求分析：非功能需求我们应当怎样做需求确认：需求列表我们应当怎样做需求确认：一个需求列表的实例我们应当怎样做需求确认：需求规格说明书我们应当怎样做需求确认：评审与签字确认会（续）