需求分析常用方法

❶ 简要阐述需求分析的几大技巧

• 进行有效的需求分析需要：制定计划和方案。要进行有效的需求分析，需要有具体的计划和方案，需要根据目前自己掌握的情况来确定自己的具体工作内容。有了计划和方案，更利于自己高效完成工作，也知道朝着什么方向努力。

  

❷ 项目管理中做需求分析常用的工具有哪些

1、理解需求捕捉时的主要方法：

用户故事、业务概念分析、最小原型法;

2、理解需求分析/需求建模的主流方法：

User Story
用户故事、UseCase用户用例、数据流图、有限状态集图、实体/关系图从PMBOK书里的介绍来看，可以用访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、观察、原型法、标杆对照、文件分析等等

❸ 项目需求分析的分析方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

❹ 需求分析有哪几个步骤

一、需求获取阶段
在需求获取阶段，需要做好收集和管理两件事。

这些需求既有产品经理主动挖掘的，也有从用户、运营、业务方、领导等渠道被动获取的，无论哪个渠道来的需求，都需要有一个正式的地方进行管理，也就是我们通常所说的需求池。

不过，对于多方关注的重点需求，通过需求池来向各方同步就不太合适了：

一是因为需求池内容太多、太杂，向业务方、领导汇报的时候会有很多干扰信息，难以快速抓住重点；
二是因为需求池里面可能有些需求不适合完全公开。
这时我们就需要使用《事项跟踪表》来单独跟进，形式上用Excel、PPT都可以。

而放在《事项跟踪表》里的需求，也要在需求池里记录下来，即需求池是做全量需求管理的，《事项跟踪表》是做重点需求跟进、汇报的。

二、需求分析阶段
1. 分析内容
需求分析主要从需求要素、定位、分解、优先级四个方面进行。

1）需求要素分析

需求要素分析是从需求本身出发，不考虑其他因素。

这些要素包括：内容、用户/角色、频次、价值、场景-动机、强度六个方面，这些要素的含义大家应该都比较清楚了，这里说一下分析各个要素的目的是什么：

分析需求内容，是为了弄清楚需求是什么；
分析需求用户/角色，是为了弄清楚需求为谁服务；
分析需求频次、强度，是为了弄清楚需求对用户的重要性、紧迫程度；
分析需求场景-动机，是为了弄清楚需求真伪、用户目的，更深入的理解需求；
分析需求价值，是为了弄清楚需求值不值得做。
2）定位分析

需求的定位分析是分析需求对产品当前阶段目标的意义。

分析需求的定位，有以下两个目的：

一是作为优先级排期的判断条件之一，如果需求与产品当前阶段的目标密切相关，则需要作为高优先级上线；
二是为了框定需求范围。每个需求的实现程度都有深有浅，可以很简单，也可以很复杂，了解了需求之于产品的定位，就能判断需求要做到什么程度。如果一个需求对产品很重要，那就需要做得很丰富，如果只是辅助需求，则需要适当轻量。
3）需求分解

原始需求的颗粒度往往较粗，不利于后续的分析、设计、开发等工作，所以我们需要对这些颗粒度较粗的原始需求进行分解，分解为一个个完整、独立、可实现的子需求。

4）优先级分析

优先级分析是以拆解后的子需求为单位进行的，根据各类优先级的判断方法、原则，初步评估各个子需求的上线顺序及时间。

2. 常见问题
需求分析应该是大家从入行那天就知道要做的事，但大多数同学在做需求分析时会犯以下三个比较常见的错误。

1）缺乏系统性

这是在分析中最常见的问题，即很多同学在分析需求时没有系统性的框架，导致很多方面没有分析到、考虑到，从而对需求认识不全面。

2）缺乏深度

对需求某些要素认识比较浅，不够细致深入，例如在分析需求的用户时，没有对用户分层、切片，对各个分层的用户也缺乏足够的了解，导致对用户只有一个笼统、模糊的认识，最后自然无法深入进去。

不过分析是否有深度的定义其实很难把握，也缺乏明确的判断标准，需要随着分析者思维能力的提升、信息量的提升来加强。

❺ 需求分析的步骤有哪些

一、需求识别
需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。

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字）。

五、系统功能分析

❻ 需求分析有哪两种主要分析方法

从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
(1)功能分解方法。
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
(2)结构化分析方法。
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
(3)信息建模方法。
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。

❼ 需求收集的常见方法有哪些

需求收集的常见方法有：

1、用户访谈：找寻目标用户并近距离接触，最好是以会面的形式，也可以采取电话沟通等途径增进了解，目的是通过交谈了解用户真实感受。

2、调查问卷：通过线上问卷的形式（有实体的也可以线下收集，但会增加统计工作量），设置一些有关产品功能、使用方面的问题。最终通过统计收集来的问卷信息，获取用户需求分布并直观解读各项数据情况。

3、可用性测试：制作高保真demo或可操作原型提供给目标用户试用，观察用户操作使用过程，并诱导用户说出操作原因。

4、数据分析：对前端、后端设置埋点，统计并记录用户与产品相关联的数据信息，如按钮点击、UV、PV等。

(7)需求分析常用方法扩展阅读：

需求收集阶段完成后，你就会惊喜的发现，需求铺天盖地而来，但面对五花八门的需求该如何取舍，这可就是一门学问了。

在需求分析阶段，我们要做的是对需求初步挖掘，目的是找出用户的实际心理需求。在此过程中，实现对需求从标到本的剖析，探究表象背后的真实目的。虽然看上去很高深，其实，最终的分析结果只决定该需求是否有被记录下来的必要。

就像用户需要一匹马（需求），在对用户进行全方位的了解之后，发现他其实是想更快的前往某地（目标）。而我们的工作，正是服务于那些有出行要求的人。我们有能力满足他们的需求，在此基础之上，让用户能通过我们提供的方式更好的出行。那么，这个需求就有必要被记录下来。

❽ 需求分析常用方法

行为事件分析

行为事件分析是根据运营关键指标对用户特定事件进行分析。通过追踪或记录用户行为事件，可以快速的了解到事件的趋势走向和用户的完成情况。

以用户投标的行为事件为例，出借人在完成投标过程中，所进行的注册、认证、开户、充值、投资等行为，都可以定义为事件，也是完成投标成功的一个完整事件。
确定投标行为事件后，我们可以根据事件属性细分维度：用户来源、性别、出生年月、注册时间、绑卡时间、首次充值时间、首次投资时间、标的ID，标名、期限、利率、还款方式等。然后从中找出符合指标的规律，并制定针对性的措施。

用户留存分析

用户留存分析是一种用来分析用户参与情况与活跃程度的模型。通过留存量和留存率，可以了解用户的留存和流失状况。比如用次日留存、周留存、月留存等指标来衡量产品的人气或粘度。以渠道访问的用户留存为例，我们对APP端有过访问行为的渠道用户进行留存分析。用户留存一般符合40-20-10法则，即新用户的次日留存应该大于40%，周留存大于20%，月留存大于10%才符合业务标准。我们做用户留存分析主要验证是否达到既定的运营目标，进而影响下一步的产品决策。

漏斗模型分析

漏斗模型分析是用户在使用产品过程中，描述各个阶段中关键环节的用户转化和流失率情况。比如在日常活动运营中，通过确定各个环节的流失率，分析用户怎么流失、为什么流失、在哪里流失。找到需要改进的环节，要重点关注，并采取有效的措施来提升整体转化率。

邀请人将活动专题页分享给好友，之后进行的注册、认证、开户、充值到投资，用漏斗模型分析一些关键节点的转化率。其中用户注册转化率为68%，实名认证转化率为45%，绑卡开户转化率为29%，线上充值转化率为17%，投资标的转化率为8%。
漏斗模型分析可以验证整个流程的设计是否合理。经过对比发现，访问到注册的转化率为68%，远低于预期的80%。这次运营策略是用户必须先注册才能领取新手福利。之后采取A/B测试的方式，优化为先领取新手福利再诱导用户注册。经过数据对比分析，注册转化率提升了20%。因此，通过对各环节相关转化率的比较，可以发现运营活动中哪些环节的转化率没有达到预期指标，从而发现问题所在，并找到优化方向。

行为路径分析

行为路径分析就是分析用户在产品使用过程中的访问路径。通过对行为路径的数据分析，可以发现用户最常用的功能和使用路径。并从页面的多维度分析，追踪用户转化路径，提升产品用户体验。

不管是产品冷启动，还是日常活动营销，做行为路径分析首先要梳理用户行为轨迹。用户行为轨迹包括认知、熟悉、试用、使用到忠诚等。轨迹背后反映的是用户特征，这些特征对产品运营有重要的参考价值。我们可以记录用户从注册、认证、开户、充值到投资的行为轨迹。通过分析用户的这些行为轨迹数据，来验证访问路径是否和预期指标的一致。

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

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

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

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

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

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

以下面的案例说明：

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

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

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

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

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

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

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

下面的案例说明：

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

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

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

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

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

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

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

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

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

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

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

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

以下面的案例说明：

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

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

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

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

这里不一一展开。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

举例说明：

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

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

分析：

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

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

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

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

❿ 需求分析有哪三种方法2，什么是面向数据结构方法

它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。

三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。