本文目录一览：
- 1、需求分析的步骤有哪些
- 2、需求分析方法主要包括哪些
- 3、需求分析有哪些方法
- 4、如何在产品设计过程中描述一个完整需求场景
- 5、论述项目需求分析的技术与方法
- 6、交互设计师是怎么分析需求和场景分析的
需求分析的步骤有哪些
一、需求识别
需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。
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字）。
五、系统功能分析
需求分析方法主要包括哪些
结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。
面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人员的要求非常高。
需求分析有哪些方法
三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法。
结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。
面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人员的要求非常高。
如何在产品设计过程中描述一个完整需求场景
需求定义
在最起初，项目需求源自于业务方的愿景和战略。产品团队应在最初的需求评审会上给出清晰的目标描述，这其中包括了需要解决的问题、提供的服务和达到的目标。同时，还应提供需要关注的关键数据指标，比如常见的意向UV、UV点击率、购买转化率等。
在这个阶段，用户体验团队，尤其是用户研究员和交互设计师，需要完成的是根据产品团队所提出的需求，进行全面完整的需求分析。这其中包括了用户场景分析、产品现状走查、数据分析和竞品分析等。
用户场景分析：细分目标用户类型、明确使用场景（who/when/where/what）、定位痛点、需求点、决策点，确定场景优先级。
产品现状走查：具体的方式可以是用户访谈、用户测试、用户体验地图、眼动追踪和KANO分析等，用于了解产品的功能、性能、内容和体验。
数据分析：包括全流程各环节数据、业务转化漏斗、用户行为数据和竞品相关数据。
竞品分析：分别从范围层（功能对比）、结构层（功能结构与流程）、框架层（界面信息布局）三个方面进行分析研究。
需求设计
进入到设计阶段，交互设计师首先需要根据具体需求完成交互初稿、原型设计和最终交互定稿方案，交付物在完成组内交互评审后，与产品经理对接，完成评审确认。与此同时，视觉设计师可以进行风格探索尝试、素材搜集整理和初稿的构思设计。在交互方案确认后，视觉设计师开始视觉层面的定稿设计，完成后需要交付给交互设计师和产品经理分别进行评审，确认后完成视觉资源输出（包括切图标注等）。
交互初稿设计：分别从范围层（确定展示功能和功能优先级）、结构层（确定功能结构与流程及页面数量）、框架层（梳理页面元素、确定页面元素优先级与基本布局）三个方面进行设计。
交互原型设计：明确关键页面流程、基本交互操作，完成可用性分析/测试（包括用户场景自查、用研专家快速评估、快速反复测试及评估等）。
交互定稿设计：生成交互文档（包括详尽的交互说明、埋点要求及说明等）、高保真原型。
视觉定稿设计：产出设计定稿图，进行可用性测试（包括专家测试及评估，快速反复可用性测试及评估等）。
需求开发
交互定稿完成后，交互设计师需与产品经理、相关开发团队成员一起进行技术评审，完成整体方案的开发估时。
在视觉方案最终确认后，视觉设计师需与产品经理、相关开发团队成员一起进行需求方案宣讲和技术评审，确认开发团队的最终排期。设计部门需配合开发联调 UI 视觉样式，提前确保设计质量。
产品提测
通过交互全流程走查、视觉还原走查、提出界面实现上的视觉问题 (UI bug)、提测阶段全面解决，来保证设计稿精确还原。
产品上线
对上线数据进行验证，进行数据的收集、分析和总结，了解各种数据指标及相应的意义，利用数据分析结论指导设计。收集、分析、决策用户反馈，对整体项目进行总结复盘，为下一阶段迭代优化做准备。
论述项目需求分析的技术与方法
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因为是图片应用，所以可以查看大图。
4因为用户是年轻女性，所以可能会留指甲，因此要减少点、戳的操作
5需要有个提醒用户本月花销数额的地方
6需要有个收藏夹，用户可以把物品放入收藏夹，还可以查看收藏夹。
当然，你还会发现产品设计中有个逻辑矛盾：如果我们的应用是希望用户间推荐服饰的话，就不应该强调她的花费数额，否则就会影响用户的使用热情。
但是，这是产品经理的事情，而不是交互设计师的事情。对于交互设计师，最多只是建议一下就好了，千万不要越俎代庖，在交互设计中修改产品设计。
第二步，根据上面的分析进行交互设计
1因为用户需要看到大量推荐，所以需要用到分页，使用瀑布流的方式，手指上下滑动即可展示新图片
2用户需要查看大图片，所以默认展示缩略图，点击缩略图可以查看大图
3在右上角展示本月花销额，如果有变化的话，有小段的动画提示。
4在右上角放置收藏夹，用户长按物品图片后，拖动物品进入收藏夹；如需查看收藏夹，点击收藏夹入口即可。
第三步，优化交互设计方案
1瀑布流的设计是ok的，无需优化
2
点击查看大图的设计，考虑到之前分析的，应该减少点击操作，所以优化为两个手指反向滑动时即可查看大图；但是刚刚也分析过，用户需要单手操作，那么如果两个手指操作时，如何持握呢？再考虑到用户是在家里使用的，所以可以把设备放在桌子上、腿上，所以这个设计是可以的。因此把查看大图的交互优化为两个手指反向滑动。
3考虑到收藏夹的位置和展示物品较远，拖动起来不方便，优化为长按物品时在物品附近浮出收藏夹，将物品就近拖入收藏夹。
4考虑到收藏夹入口如果在页面常显的话，不能占用很大位置，否则就影响了用户视觉焦点；但如果缩小尺寸后点击起来很不方便。所以把收藏夹放入右侧抽屉菜单，用户向左滑动即可打开抽屉。
5考虑到用户消费额增加时小段动画也会打扰用户，将消费额也放入右侧抽屉，用户消费时有个小幅度的抖动，用户打开抽屉后才能看见消费额。
第四步，将交互设计方案交给产品经理
如果他觉得ok则通过，如果他觉得不好就重复1-3步。