网上科普有关“需求分析的十个步骤”话题很是火热 ，小编也是针对需求分析的十个步骤寻找了一些与之相关的一些信息进行分析
，如果能碰巧解决你现在面临的问题，希望能够帮助到您。

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 Product)，利用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格式，可能......

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

需求分析的最终结果是产生什么

你好
，今天我来详细介绍交互设计师的输出物–交互文档的相关细节，其实 ，UX设计师在今天看来
，仍然算是一个新兴职位，所以我多讲一些UX设计师的职位背景和相关工作内容 ，作为本篇文章的背景
。

一
、交互设计师的工作内容

UX设计师的存在
，使原本产品经理工作中的原型制作工作逐步转让给UX设计师，使产品经理更关注需求的战略层面 ，更能进行战略层面的设计。同时
，UX设计师也分担了UI设计师的布局设计、跳转设计等非本职工作，使开发流程中的角色更加专注自己的工作 。

交互设计师 ，UX设计师
，有的公司也称之为UE设计师
。具体的工作内容可以认为有：

需求消化，使其可实现化 ，并制作对应的交互原型；

规定数据格式 、样式，规定数据的展示方式
、字段限制；

规定控件的使用规范；

从功能流程的高度
，梳理功能的页面层级；

规定数据的前后台交互；

规定临界状态；

页面切换动效的规定和模拟等等。

不同的公司对交互设计师的工作内容可能有不同的界定，但是一般情况下 ，上述是大部分交互设计师的主要工作内容 。在这样一份工作中
，交互设计师基本上是填补了从产品经理到UI设计师之间的空白，从开发角度和设计角度对一款产品的细节进行补完
。

二、 交互设计师的输出物

作为交互设计师的输出物 ，交互文档是联系开发流程上下游的重要文件
，它需要具备良好的可读性 、唯一性和时效性。

可读性指的是不论产品经理
、设计师还是开发人员，都需要读得懂；

唯一性指的是 ，针对某个开发需求
，必须有且只有一个交互文档 。针对某个项目，其对应的交互文档也必须是独一份（可以是一个交互文档的集合）
。即使存在多个版本 ，旧的版本必须标注为“归档备查 ”
，并且明确备注过时时间；

时效性指的是，某个需求或者某个项目 ，尚在使用中的交互文档，必须是最新的
，符合当前需求要求和产品输出的。

本文着重介绍的即是交互文档的构成和它的写法（基于中国移动交互文档规范） 。

三、交互文档的构成

综合国内IT行业的从业环境，基于Axure的原型制作可能更便于打通开发上下游。

大概碍于Axure做出来的原型不是那么美观和便捷 ，部分产品经理和UX设计师可能已经转战Sketch等交互设计软件
，或者使用Flinto来模拟交互动效
。但因为这些软件大多无法跨平台，考虑到很多公司并没有能力全面采用MAC办公 ，所以这里推荐使用Axure进行原型制作。

交互文档一般由以下部分构成：

1. 交互文档说明及日志

说明交互文档所针对项目或者功能；

日志记录它的创建时间 、修改时间及修改原因和内容；

记录文档的编写人和最新的更新时间 。

请点击输入描述

交互文档说明示例

请点击输入描述

交互文档更新记录/日志示例

交互文档的Title有效地保证了交互文档的唯一性
，即该文档对应的是XX项目或XX项目的XX功能；

通过编写人
、版本号、创建时间和更新时间，方便在文档内容存疑时 ，找到对应的时间节点和该文档的负责人
，便于对接和修正；

在更新记录中，需要有效地标明版本号 、更新时间、更新内容和修改人 ，便于文档内容出现存疑时
，定位到是哪一部分出现了问题，该部分的对接人是谁 ，并且明确时间节点，便于版本的追溯和责任的厘清
。

2. 文档内容结构

大致包括模块名称
、功能流程图、页面说明 、页面跳转关系图等。

请点击输入描述

交互文档构成结构示例

在文档内容的结构中
，必须保证交互文档的说明和日志是位于头部，便于随时查阅；

在正式内容中需要灵活运用Axure中的图层 ，如分组和页面图标等 。一般我们认为将页面说明和页面跳转关系统一归到一个功能流程或者一个分组下
，这样旣合乎逻辑也可以保证文档内容的层次感，便于查阅时的定位和展开；

始终坚持“一个页面只描述一个功能”的原则 ，这样可以保证单个文档页面中的内容量适当
，便于查阅
。

请点击输入描述

页面说明示例

在确定以上内容后，就可以保证这份交互文档结构是足够清晰的 ，是便于查阅的。接下来
，我们将讲解交互文档的正式内容应该如何写 。

我们用国内的一款软件摹客网页链接举例

1.产品概述

产品需求文档的第一部分，首先需要对整个项目的研发背景及整体规划进行说明 ，让阅读者可以快速理解需求背景和产品定位
。其次是对产品需求文档本身进行阐述
，在每一次修订后都需要进行记录，方便阅读者了解产品需求文档的修订更新。这一部分主要包括以下内容：

项目概述

词汇表

文档修订历史

版本说明等

2.功能范围

这一部分需结合用户
、业务规则及市场环境 ，对产品的用户和市场需求进行分析梳理，找出差异性和优势
，制定业务流程和需求清单 。可通过业务逻辑图、流程图 、产品结构图等图表，让产品逻辑和功能以最简单的方式陈列出来 ，团队成员可根据这一部分了解用户信息
、行为信息等
，也有助于对产品进行进一步的理解
。

3.功能详情和原型

首先是列举功能总表，将产品功能进行逐条梳理 ，每一条功能都能对应前面的产品目标。

其次是功能详情展示
，通过Mockplus等原型工具快速绘制原型，配合关键部分的批注说明 ，详细描述业务模块的展示、交互和数据逻辑
，以供开发人员查看和理解 。

4.全局说明

这一部分包括设计规范 、数据统计
、通用规则说明等信息，方便设计师和开发人员查看产品细节信息。

5. 测试需求

产品一般在正式上线前都有BETA版本或者内测版本 ，产品经理需要定制测试产品的功能或者性能
。

6.非功能性需求

非功能需求为用户常规操作产品时的极端情况
，涉及很多内容，包括产品性能、安全性 、可靠性
、拓展性等方面。

7. 产品运营和市场分析

完成产品开发并不是终点 ，产品的最终目的是要赢得市场 。产品上线后如何运营？建议的推广策略是什么？产品经理和运营人员该如何协作？等等问题
。

产品需求文档撰写技巧

如何高效完成产品需求文档的撰写？我们可以从以下四个方面展开说明：

理清文档结构

详尽叙述每一个细节

语义明确，没有歧义

搭配原型图或设计稿进行说明

1.理清文档结构

一份产品需求文档的内容往往多而复杂
，因此，产品经理在撰写产品需求文档时 ，必须理清文档的结构
，才能提升产品需求文档的可读性，让阅读者可以快速了解文档的思路和查阅重要信息。

将一份产品需求文档看做一个产品 ，首先需要梳理出它的结构
，如上文中所呈现的文档内容，然后再按顺序进行撰写 ，这样才能写出结构清晰
，层次分明的产品需求文档 。

2.详尽叙述每一个细节

当我们站在产品经理的角度思考问题时，往往会出现这样的误区：产品的这一功能模块逻辑非常简单 ，业内常见
，开发人员也一定能懂，不用再进行单独说明
。

产品经理对于产品的功能及逻辑往往非常了解 ，但如果从开发或测试人员的角度来看，往往对于许多产品的细节和逻辑关系都不太了解。因此产品经理在撰写产品需求文档时
，一定要做到事无巨细 。不仅需要详尽叙述页面逻辑、交互逻辑 、数据逻辑等所有细节，还需要从开发、测试等角度检查是否有遗漏或错误 ，才能保证后续开发工作有条不紊
。

3.语义明确
，没有歧义

在撰写产品需求文档时，要做到语义明确 ，不能出现让阅读者产生歧义的词汇或语句
，如：大概
、可能、似乎等词语。另一方面，对于产品定义的表述方式 ，必须做到全文统一 。比如在撰写一份APP的产品需求文档时
，前文写了“首页轮播图
”，后文就不能再使用“首页Banner” 、“横幅 ”等名称
。

4.搭配原型图或设计稿进行说明

产品需求文档往往包含大量文字描述 ，团队其他成员在阅读某些功能细节时
，往往无法完全理解文字内容。此时如果使用原型图或设计稿进行说明，就可以补充文字内容很难描述的信息 ，帮助阅读者快速理解产品功能和内在逻辑 。因此产品经理在撰写产品需求文档时，需要配合原型图或设计稿进行说明。

一款产品的原型图或设计稿通常会进行反复修改
，产品需求文档必须同步更新，才能让阅读者及时了解到项目的最新动态
。但如果每修改一次原型图或设计稿 ，产品经理都必须手动去替换文档中的配图内容
，那效率就太低了！其实，使用高效的产品需求文档撰写神器即可解决这一难题。

产品需求文档撰写神器

随着产品开发流程的不断发展 ，Office等传统办公软件已无法满足产品文档的撰写需求 。今天为大家推荐的
，是一款专门面向产品经理的文档工具——摹客
。除了上述图文同步的难题外，摹客还能解决审阅沟通
、版本管理等产品需求文档的写作困境 ，让产品经理可以更高效地创建专业的产品文档。一起来看看~

1.富文本撰写
，充分表达产品需求

摹客全新的富文本在线写作模式，符合产品经理日常编辑习惯 ，可以快速完成文档撰写 。撰写内容自动保存
，可随时查看历史版本，方便对比修改
。此外 ，产品经理也可以直接上传本地产品文档，会自动解析目录
，并生成文档树，方便查阅。

请点击输入描述

2.与原型图、设计稿深度结合 ，相互说明论证

产品经理在撰写产品需求文档时可插入设计稿
，当对设计稿进行了更新修改，可在文档中设置内容同步 ，无需重复插入 。另外
，团队成员在设计稿上打点评论时，也可以引用文档进行说明 ，让团队成员可以一目了然地查看相关信息
。

请点击输入描述

3.实时审阅
，高效沟通

文档编辑完成后可以通过链接一键分享给团队成员，团队成员可选中文字增加评论 ，对文档进行在线审阅
，清晰表达项目意见，实现产品开发团队的高效沟通。

请点击输入描述

4.追踪修改记录 ，备份历史版本

通常，产品需求文档的写作不会一步到位
，往往会根据团队成员的评审意见进行反复修改，因此会产生大量的迭代版本 ，对于产品经理来说
，如何管理产品需求文档的历史版本，是一个很大的难题 。在摹客

撰写产品文档 ，每一次修改都可以自动生成历史版本
，可以随时跳转查看和恢复，管理便捷
。

请点击输入描述

5.在线预览 、分享更便捷

在摹客中在线撰写或上传的产品需求文档 ，可通过链接快速分享给团队成员
，团队成员获得链接后可自由查看，当产品需求文档有修改时 ，团队成员仍可通过链接查看最新版本。

使用摹客等高效便捷的产品文档撰写工具
，可以简化产品文档撰写流程，提升产品经理的文档撰写能力 ，让产品经理事半功倍 。

项目需求收集的结果是什么

需求分析的最终结果是产生详细完备的需求文档和需求规格说明书，以确保在项目开发过程中能够满足用户的需求和期望。

1.定义基本信息

在需求分析的第一步
，需要定义项目的基本信息，包括产品名称
、版本信息、开发团队等
。

2.收集需求

根据项目的性质和用户群体 ，收集用户的需求和期望
，以确定项目的要求和目标。

3.分析需求

对用户提出的需求进行分析和整理，确定哪些需求是必须的 ，哪些是可选的
，并进行优先级排序和分类 。

4.编写用例（User Story）

根据用户需求编写用例，用例应该具有明确的场景 、角色
、动作和预期输出 ，以便于后面的开发人员理解和实现
。

5.确定功能和非功能需求

在分析和整理用户需求的过程中
，同时需要确定项目的功能和非功能需求（如性能、可维护性 、安全性等），以确保在开发过程中能够涵盖这些方面。

6制定系统设计方案

在需求分析的最后阶段 ，需要根据分析结果制定系统设计方案
，确定系统的技术架构
、开发工具和环境、后续支持等 。

7.评审 、修订和批准需求文档

需求分析结束后，需要对编写的需求文档进行评审、修订和批准 ，确保它们满足用户的需求和期望，并在后续的项目开发过程中起到指导作用
。

拓展知识：

需求分析是软件开发的关键步骤之一
，涉及到软件整个生命周期的各个环节。除了上述提到的常规步骤外，还有其他一些辅助手段如调研
、问卷调查、访谈 、竞品分析等 ，它们可以帮助分析人员更好地理解用户的需求和期望
，从而更加准确地进行需求分析和产品设计 。

一份需求规格说明书
。

需求收集过程的主要输出是需求规格说明文档，需求分析完成的标志是提交一份完整的软件需求规格说明书 ，因此结果就是一份规格说明书。

关于“需求分析的十个步骤
”这个话题的介绍
，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！