运用什么方法进行需求分析

❶ 需求分析的方法

原型法：获取一组基本需求之后，快速构造出一个能够反映客户需求的初始系统原型。

让用户看到未来系统的概貌，以便判断哪些功能是符合要求的，哪些还需要改进。

按照信息的流向、结构和内容三个方面将现有的需求分析建模方法划分为结构化分析方法，Jackson分析方法和面向对象分析方法。

通过E-R图提供表示实体、属性和联系的方法，描述显示世界中的概念模型，不涉及这些实体在系统中的实现方法。

通过数据流图描述逻辑模型，表示数据在系统内的变化；分层表示信息流和功能的细节。

行为建模采用动态分析方法，直观地分析系统的动作，最常用的动态分析方法包括状态迁移图，时序图和Petri网。

状态迁移图通过描述状态以及导致系统改变状态的事件来表示系统的行为，指明了系统如何在状态间移动。

❷ 论述项目需求分析的技术与方法

1、筛掉明显不合理的需求

这个阶段的判断标准就是需求的合理性，用你的经验、专业知识，甚至是直觉，过滤掉大部分需求。比如，当前技术不可能实现的或意义不大的、投入产出比低的、明显不合理的需求。

因为从各种不同渠道会收集到大量的需求，为了提高效率，你不得不这么做。当用户量达到一定规模后，光每天收到的用户反馈就够你喝一壶的。甚至因此，你不得不做一个用户帮助和反馈系统，来帮助你过滤和初步加工需求。

有个简单的判断方法：这需求做了会怎样？不做又会怎样？

如果做不做没多大区别，甚至做了会起到负效果，那就不需要犹豫了，可以直接过滤掉这条需求。

2、挖掘用户的潜在需求和动机

这是用户需求进化为产品需求的关键一步。

用户需求：need，用户想要的。

产品需求：solution，解决方案。可以是推荐算法优化、界面布局调整、新功能点，甚至是新产品等等

以上是用户需求和产品需求的定义，用户需求是用户想要的东西，产品需求是满足用户需求的解决方案。用户毕竟不是专业人士，考虑问题的出发点是用户自身，这就需求产品经理去挖掘用户的潜在需求和动机。

最着名的例子就是：If I had to ask customers what they want,they will tell me:a faster horse.“如果我当年去问顾客他们想要什么,他们肯定会告诉我：一匹更快的马.’”

如果福特先生不去挖掘用户背后动机的话，可能就去研究马的配种问题了，而不会有福特汽车了。

那么如何挖掘用户潜在需求和动机？

用户需求的产生，带有很强的不确定性，受环境、情绪等各种因素影响。所以光看表面描述不行，得有代入感的去感受。可以通过以下几个要素进行场景分析：

用户需求=谁（用户特征）+在什么情况下+想满足什么？

比如你是Todo list产品经理，调研过程中，某用户反馈添加过程太麻烦了，没法批量添加。追问为什么需要批量添加后，对方回答，她是一名学生，想要把课程表导入到list中，方便查看。

这时候你就明白了，对方是一名大学生，在添加操作的环节遇到了麻烦，她是想要添加课程表。

这时候你就可以马上找到解决方法：可以利用OCR技术，只需扫描一下，直接将整张课程表导入进来。

再深入思考一下！添加课程表就是最终的目的吗？

显然不是，对方添加课程表后，一是为了方便查看，二是为了上课时间快到时提醒她上课。那么就可在导入后，行程一个可视化的日程表，提前提醒上课。

这就是需求挖掘过程。

3、需求归类整理

挖掘到用户的真实目的后，会发现，多个看似不同的需求背后，原来是出于同一个目的。这就可以将这几个需求归纳为同一个。

接着可以通过如下维度归类整理需求：

1）判断是否有价值：广度、频率、强度

如果使用人数很多、频率很高、需求也很强烈，那当然是好需求。如果这三者都不沾边，可以判断为无价值需求，可过滤掉。

❸ 传统需求分析方法包括哪些主要特点是什么

传统需求分析方法：结构化分析方法。

主要特点：结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。

因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制。

通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。

当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。

需求分析原则

为了促进软件研发工作的规范化、科学化，软件领域提出了许多软件开发与说明的方法，如结构化方法、原型化法、面向对象方法等。这些方法有的很相似。在实际需求分析工作中．每一种需求分析方法都有独特的思路和表示法，基本都适用下面的需求分析的基本原则。

1、侧重表达理解问题的数据域和功能域。对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。

2、需求问题应分解细化，建立问题层次结构。可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。

3、建立分析模型。模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。

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

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

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

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

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

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

以下面的案例说明：

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

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

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

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

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

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

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

下面的案例说明：

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

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

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

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

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

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

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

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

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

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

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

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

以下面的案例说明：

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

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

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

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

这里不一一展开。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

举例说明：

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

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

分析：

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

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

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

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

❺ 如何进行软件需求分析

软件需求分析免费下载

链接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

❻ 需求分析的主要方法是什么

1.1 需求的背景

需求的背景指的是动机，这一项实质上是换位思考，它能够帮助我们从业务方的角度，从使用场景、用户心理去理解需求。

在实际工作中，我们所接收到的“需求”常常是表述不清晰的、不完整的，甚至是具有欺骗性的。

一个问题会对应许多的解决方案，找到真正的需求，也正是我们的职责。

1.2 需求的受众

需求的受众需要注意的问题有两点：

谁是真正的受众；
受众人群是否具有代表性。
需求的来源很多，可能是用户、业务方等。我们需要分清楚谁才是真正的受众。

在一个需求里不同的角色认知和诉求是不同的，当信息带上了主观判断也就被污染了。

其次，则是覆盖度的问题。对于频次不够高或者人群不够有代表性的需求，投入产出比会是一个大大的问号。辨清受众，在评估需求的优先级和制定解决方案时，迷惑性会大大降低。

1.3 需求的目的

需求的目的指需要做什么，很多时候我们接到的“需求”其实是业务方过滤后的“解决方案”。

以“口渴”为例，此时业务方提出的需求是要制作一台饮水机，然而饮水机并不能解决问题。如果我们挖掘到背后的动机是“口渴”，那么我们可以从补充水分和减少水分的流失来着手提供解决方案。

1.4 需求的目标

在汉语辞典里的解释，目的是期望，而目标是成果。

目标更为具象，并且能够用数据指标来衡量，后续也能够指导需求的改进。

需求的本质是为了创造价值，而创造价值最直白的则是开源和节流。具象到目标，可以用创造的收益，提升的效率以及节省的资源等方面进行量化。

2. 因果关系分析法
、需求优先级的评定
最后一个环节是需求优先级的评定，我常用的方法是选取影响优先级的因素并设定比例，经过加权计算出优先级，分数越高优先级越高。

其公式如下：

优先级=因素1比例*因素1分值+因素2比例*因素2分值+….

表1-需求评估加权表

这张表，影响的因素主要有两项：投入产出比以及重要程度。

投入产出比个人认为是必选的，而重要程度中的维度可以根据实际情况去增加、减少。同理，加权中比例的设置也是如此。

❼ 如何做需求分析

你这个问题问的有点太大了，不知道怎么回答，需求的工作存在很多灵活性，很难整理出一个流程性的东西，我也是正在学习，最近在学习徐峰老师的《软件需求实践》，把我知道的拿出来分享，错了的话请大家纠正，但是不要喷我啊！妹子心里素质不行，嘿嘿
1、需求是有层次的，分为业务需求、用户需求以及系统需求，所以在进行需求分析时肯定是要根据不同层次阶段进行不同方式、内容以及侧重点的需求调研。
1）业务需求，一般是公司的高层提出的，就是我们这个系统的指导需求，这个需求比较空，但是却是整个系统需求的指导思想，在做需求时经常想想这个知道思想，可以防止需求跑偏。

2）用户需求，一般是公司的中层和操作层提出的需求。中层突出流程，就是整个框架，而操作层提出具体的细节性需求。就是往中层的框架里面添加需求细节。

3）系统需求，就是针对前两种需求调研之后得结果进行需求分析和业务建模之后，得到了系统开发的需求。

2、需求的步骤分为：需求定义（对应上面的业务需求）、需求捕获（对应上面的用户需求）、需求分析与需求建模（对应上面的系统需求）、需求验证、需求跟踪、需求管理。

3、做需求工程中可以使用的工具：AXURE（用来制作原型，让用户更直观的了解即将做成什么状态的系统，便于需求确认）、EA（是建模工具，用来绘制UML图，“一图抵千言”为了更好的表达需求和沟通需求）、word、Excel、Visio等工具。

❽ 需求分析常用方法

行为事件分析

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

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

用户留存分析

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

漏斗模型分析

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

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

行为路径分析

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

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

❾ 需求分析常用方法都有哪些，请举例说明

问卷调查法，是指设计方就用户需求中的一些个性化的、需要进一步明确的需求或问题，通过采用向用户问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。 这种方法适合于设计方和建设方、使用方都清楚项目需求的情况。因为建设方和使用方都清楚项目的需求，需要双方进一步沟通的需求或问题就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。显然对于乐百氏集团这样规模庞大的公司，简单的问卷调查是不能够满足准确获得需求的需要的。会议讨论法，是指设计方和用户相关人员召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于设计方不清楚用户的详细业务需求，但使用方清楚项目需求的情况。因为使用方清楚项目的需求，他们能准确地表达出他们的需求，而设计方有专业的需求，而我们有专业的软件开发经验，经过回忆讨论交流之后，能够对用户的需求进行准确描述和把握。这个方法对于准确的获得乐百氏公司的需求是一种不错的选择。在本案例中系统的设计人员也是这么做的，他们通过和乐百氏项目组经理的讨论，很快了解了乐百氏的运作过程的数据。界面原型法，是指设计方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于设计方和用户都不是非常清楚项目需求、只是大概了解用户需求的情况。因为设计方和用户方都不能非常准确的描述出客户的需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解