需求分析的工作方法

① 培训需求分析的方法有哪些

1、问卷调研法。

问卷调研法是最普遍也最有效的收集资料和数据的方法之一。一般由培训部门设计一系列培训需求相关问题，以书面问卷的形式发放给培训对象，待培训对象填写之后再收回进行分析，获取培训需求的信息和数据。

2、访谈法。

访谈法也是数据收集的一种重要方法。它是指为了得到培训需求的数据和信息，与访谈对象进行面对面交流的活动过程。这个过程不只是收集硬性数据，比如事实、数据等，包括印象、观点、判断等信息。

3、小组讨论法。

小组讨论法是指从培训对象中选出一部分有代表性且熟悉问题的员工作为代表，通过讨论的形式调查培训需求信息。小组讨论法的形式比较灵活，可以是正式的也可以是非正式的，可以通过头脑风暴、组织对照等多种方式进行。

培训需求分析的三个层次：

1、必须在岗位任职人员的个体层次上进行分析。在这一层次上，培训部门、培训岗位主管共同对企业员工进行需求分析，确定参加培训的人员和培训内容。

2、是在组织层次上的培训需求分析，它是从客观的角度对组织近中期的目标，以及培训效果转换的组织氛围和企业整体人力资源存量进行分析，设计员工的培训计划。

3、是在战略层面上的分析。战略分析不是集中在个体、组织、部门现在有效工作所需要的知识、技能和能力上。例如，未来需要多少或什么类型的工作人员、组织是否现在正经历和将要经历能够影响从事工作方式的巨大变化等。

② 需求分析的十个步骤

1、概念明确----2、需求分析目的------3、如何识别需求---4、判断需求真伪----5、分析[ 用户故事评估框架、马斯洛框架、营销框架定位]---6、评判价值----7、砍需求能力---8、分类----9、排优先级----10、提升需求分析能力

一、什么是产品需求?

1、想要 vs 需要 vs 需求

“想要”(Want)是用户外在表达出来的，而“诉求”(Need)是用户内在的心理预期。产品需求满足的是用户的内在诉求，这是根本。

想要(Want)是外在的、具体的、有指向性的解决方案。

需要(Need)，或者如我们前面说到的“诉求”，是内在的、原始的最终动机。

需求(Demand)是满足内在需要的同时，在可控成本内实现外在想要的解决方案。

二、需求分析的目的

需求分析，本质是动机的分析，目的在于预测用户未来的行为。需求分析阶段的产出 物，需要回答用户要什么、为什么要，还要回答以后什么情况下还可能要类似的东西、这种情

况有什么特点、如何人为的制造这种情况、

需求重要，是因为它是用户行为的动机;需求是分层的，说出来的一个样，实际是另一个样。

用户需求分析，是为了通过分析动机，准确预测用户的行为。不同的需求，代表   了不同的动机，注定会产生不同的行为，应当看做不同类型的用户。

在需求分析中考虑竞争性，是为了比竞争对手预测得更准确，这是我们在后面要说的。

【知识点】需求= 购买欲望 + 购买力 = 需要 + 目标产品 + 购买力

三、如何识别需求？

       分析完需求，那我们如何去发掘新需求呢?这里就涉及如何识别需求。 识别需求可以从三个方面去考虑，分别是视角、效率、体验。

       1、视角

       先说视角。作为产品经理，我们要具备多样化的视角来审视需求和产品，分为用户视角和产品视角。

        比如:开头我们提到的关于微信朋友圈可见范围的例子，相比于之前三天可见和半年可见，增加了一个月可见范围。

        在这个设计里，用户往往会站在自我的角度说，“不想让别人看我的朋友圈”，这是用户视角。而产品视角是考虑群体和整体，是“让用户更小压力去发朋友”。这种视角差异，最终的方案也会有差别。

        用户视角满足的是“想要”(Want)，产品视角实现的是“需要”(Need)。

        2. 效率

        另一个识别需求的维度就是效率。在最优效率的前提下，满足尽可能多的用户需求。

        我们还是用一个例子来说明，用过微信公众号赞赏功能的人都知道，如果自己赞赏过作者，那自己的头   像就会始终排在最前面。

        如果自己没有赞赏过，那每次进入文章，且赞赏人数超过 24 人后，底部的赞赏头像都不是固定顺序展示的。

        3. 体验

            最后一个识别需求的维度就是体验，关于体验，做产品的同学就比较熟悉了。体现在信息架构设计、流程设计、交互设计还有文案设计等方面。

            体验也是一个很虚的指标，很难量化，每个人的认知和感受都会因为习惯、文化、个人倾向产生差别。任何细节的体验设计，都会给用户传递一个认知，而我们要明白的是，独立个体的认知差异是很大的。

            比如:对于“快车”这个概念，刚出来的时候，大众是无认知的，只能找到对标，比如出租车和专车，而快车是介乎于两者之间的一种服务。

            如何更好的设计快车体验呢，其实用价格比专车低、比出租车干净舒服、且车多三个认知来传递给用户，就能让用户快速接受并理解。

四、接收需求判断真伪

真需求要满足三个条件

            1. 该用户属于目标用户

            2. 需求必须符合产品定位

            3. 需求能够实现

五、如何分析需求

1、采用用户故事的方式进行分析

    需求是结合用户表达的外在欲望、内在的核心诉求以及可用成本的综合评估。

    基于这个定论，我整理了一句话，可以作为需求分析的一个评估框架—— 我们为谁用什么方法解决了一个什么问题?

    在这句话里，“谁”指的就是我们的目标用户，我们需要明确用户画像;“问题”对应的是前文提到的需求，而“方法”就是我们基于需求提供的产品方案。

    我们为谁用什么方法解决了一个什么问题?其实就是在反问我们自己，作为产品经理，你在为哪类人服务，他们的核心诉求是什么，你设计了一个什么产品方案去满足他们的需求。

用户分析，我们可以从用户身份和用户特征两个角度出发，用户是什么人群，年龄、性别、地区等都是构建用户画像的基本素材。

目标用户有什么样的特征，比如职业特征、文化特征等，这些都能帮助我们进一步理解用户。

其次是需求场景，说白了，就是用户是在什么环境和状态下来使用我们的产品。

“场”是时间加空间，“景”是情景和互动。当用户停留在这个空间的时间里，情景互动触发并裹挟用户的意见就是场景。

可以用比较通用的马斯洛需求理论对用户需求进行分析，评估满足的是哪个层级的

需求，或者是通过用户体验五层模型来划分需求层级。

用户价值是从体验和效率两方面来衡量的，一个需求能改善现有体验，那就能提升用户价值，能提高使用效率，也能提升用户价值。

如何衡量体验是否有提升呢，可以用新体验减去旧体验的方式，例如针对某个体验改进，简单粗暴的做法就是新旧体验相减得到的用户投诉率，如果为正，说明用户价值有提升。

而效率则可以通过用户完成某一任务的平均时长来衡量，例如在电商产品中，用新旧总平均成交转化时长的差值来衡量提单效率是否有提升。

商业价值就比较直观了，关乎于成本和利润，互联网传统的商业化方式包括了广告、游戏、会员等。目前也有很多做增值服务和第三方能力输出服务的，这都是商业化手段，同时也会对应到一些产品需求上。

2、马斯洛框架和营销层方式结合起来

做需求调研和分析，最尴尬的结局就是:用户以为自己说清楚了，我们以为自己听清楚了，结果两边就这样整差了。

 在产品上线之前，甚至在进入产品设计阶段之前，我又怎么能知道我做的需求分析已经足够深了呢?

  行业给出的一般方法是MVP(MinimumViable Proct)，利用MVP收集线上实际数据。 但MVP只能告诉你，你是错了还是对了，依然解决不了“为什么”以及“应该怎样”的问 题。况且MVP还有覆盖度的问题，怎么设计才能让MVP覆盖所有“应该”被测试的场景呢?

到了1959年以后，马斯洛认为“人本”的导向会产生“自由主义”倾向，从而产生自私、不负责任、不顾他人、自我放纵等自我中心倾向。于是，马斯洛于1969年发表了论文《Z理论 ——两种不同类型的自我实现者》，并依照“超人本心理学”(Trans-HumanisticPsychology)将需求层次理论拆解为三个次理论:X理论、Y理论和Z理论。

依次为:

Z理论

                       最高需求(超越性灵性需求)

Y理论

                       自我实现需求

                       尊重需求

                       社会需求

X理论

                        安全需求 生理需求

营销学中的需求分层

在科特勒老师的《营销管理》(15th Global Edition)中，给出了这样一个案例:

表明了的需求:顾客需要一个便宜的汽车;

真正的需求:顾客需要一个养车比较便宜的汽车，而不是价格便宜的汽车;

未表明的需求:顾客希望零售商提供较好的服务;

愉快的需要:顾客希望零售商给装配车载GPS系统;

秘密的需要:顾客希望朋友们将TA看作是懂行的消费者;

有了前面两套框架，我们就守住了需求的来源和表达过程。但是两套框架的用法正好截然相 反:马老师的框架是“5:1”——从五个层次里选一个当前所在的层次;但营销学的需求理论 是“1:5”——拿到一个需求从五个方面来分解。

我们用卖苹果的例子还原一下需求分析的过程:

用户说:“我要买一个苹果”。此时千万不要直接就套上马老师的需求层次了，因为这根本就不是一个“根本性”的需要，而是一个结合了具体产品——苹果的具体需要。

这时应当用的是营销中的五个分类:

                       表明了的需要:我要一个苹果;

                       真正的需要:可能是解决饿肚子，可能是解决馋，更有甚者是解决低血糖的症状等

  等;

                       未表明的需要:如果为了填饱肚子，就需要个大的;如果为了解馋，就需要味道好

  的;如果为了解决低血糖，就需要一个更甜的;

                       愉快的需要:吃饱了、解馋了、头不晕了(低血糖的症状之一)当然开心，如果买一

  送一、免费加工成苹果汁、还能额外加点糖，有可能就更好了;

                       秘密的需要:可能是工作繁忙，接下来还要赶往别处，实在没时间吃别的了;又或者

  是最近吃胖了，需要用水果当饭吃;

六、评判需求价值

1. 广度:受众人群以及受众面

2. 强度:用户对于需求的迫切程度

3. 频率:间隔时间及可持续性

七、砍需求能力

                        1. 对需求进行价值评估和量化

                        2. 关联性较强的需求进行整合

                         3. 排列优先级

所有对产品的价值判断，都基于对行业、市场的探知程度;对人性的认识和了解程度(发现没有，把握人性始终贯穿产品的各个层面)

八、对需求分类

九、对需求排优先级

能用是基本要求，能用的标准是产品功能完整、没有异常、逻辑闭环，如果功能或流程缺失，或者产品有bug，那是达不到能用的标准的。

易用对应一些锦上添花的需求，在满足能用的前提下，做流程优化和交互优化，使产品达到用户体验良好的状态。

爱用是让用户形成习惯和依赖，例如我们在朋友圈里发布了很多内容，随着内容增多，我们的离开成本就越高，并且每次都能收到朋友圈的正向反馈，这个闭环就能形 成习惯和依赖。

传播能力使产品具备价值可扩散的属性，满足用户需求并获得市场认可后，需要将价值外延以吸引更多的用户，这是建立在基础功能完备、体验优良，并且满足用户价值 的前提下。

十、如何提升需求分析能力？

1. 倾听

首先是倾听，面对需求方，不论是用户还是运营还是工程师，首先做到先听，这是放下自我做产品的前提。

什么是事实? 客观的原因和现象是事实，基于现象去分析背后的原因，基于原因再形成观点。

2. 观察

其次是观察，观察是最好的洞察用户需求的方式，到用户身边去，看他们做了什么，行动往往反映了用户的真实诉求。

3. 同理心

       如何切身感受、设身处地呢?最简单的方式就是到用户的环境中去，感受用户不如变成用户。

只有切身感受，尤其是感受到了痛，你才真的理解了用户。

附记：

需求沟通:需求中的需求?

            至于怎么讲，我们还可以套用前面的框架——老板跟你说:“你做个需求分析”。

 那么:        

表明了的需要:老板需要你做一个需求分析;

真正的需要:老板可能在策划下一款新产品，或者要把一个竞争对手打掉，或者是老板的老板要求下来的，或者......

未表明的需要:时间呢?质量呢?形式呢?汇报对象呢?怎么，你不知道?快问啊!

愉快的需要:老板可能希望你从不同的视角(员工视角、跨行业视角、年轻视角等 等)给出不一样的答案;可能希望你直接做成他能用来汇报的ppt格式，可能......

秘密的需要:老板背负着公司巨大的业绩压力需要寻找突破口、老板“可能”也有自己升职加薪的小算盘......

③ 如何做需求分析

需求分析的目的是为了达成开发者和用户对需求信息的共同理解，对需求的分析不到位，可能会导致各角色对需求理解不一致、需求变更频繁，无法对需求做出估计等问题，给项目和团队带来负面影响。

需要分析的主要内容包括：

（1）功能分析：分析实现该需求所须提供的功能含义、工作内容；

（2）角色分析：分析该需求涉及的角色及在本需求内容的行为；

（3）业务流程分析：分析该需求涉及的业务流程、以流程图或用例图表示；

（4）数据分析：分析该需求涉及数据项的名称、含义、格式、规则；

（5）全线分析：定义各角色在该需求中的行为；

（6）界面分析：分析实现该需求的界面风格、表单样式及页面布局；

（7）性能分析：分析该需求的最大数据量、访问频度，定义用户访问时间等要求；

（8）耦合性分析：分析该需求和其他需求的相互关系及影响。

④ 需求分析常用方法

行为事件分析

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

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

用户留存分析

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

漏斗模型分析

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

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

行为路径分析

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

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

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

1.1 需求的背景

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

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

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

1.2 需求的受众

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

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

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

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

1.3 需求的目的

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

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

1.4 需求的目标

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

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

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

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

其公式如下：

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

表1-需求评估加权表

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

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

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

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

  

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

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

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

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

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

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

需求分析原则

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

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

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

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

⑧ 如何做好需求分析，需求调研

转载以下资料供参考

从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
原因
需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。
任务
简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。
过程
需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
方法
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。
追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。

需求分析20条法则
客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、 分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。
3、 分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、 要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、 开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、 开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、 描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、 允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、 要求对变更的代价提供真实可靠的评估
有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、 获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、 给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、 抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、 准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、 及时作出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、 尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、 划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、 评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、 需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、 遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、 尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人ONT>

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

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

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

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

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

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

以下面的案例说明：

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

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

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

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

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

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

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

下面的案例说明：

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

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

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

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

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

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

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

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

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

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

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

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

以下面的案例说明：

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

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

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

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

这里不一一展开。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

举例说明：

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

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

分析：

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

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

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

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

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

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