本文主要是对 ToB 系统，软件需求分析过程的学习知识，经验及总结。
什么是需求
需求 = 预期 - 现状
需求是用户的预期和现状之间的差距。
信息系统需求 ： 用来描述业务/客户对系统的目标要求，包含对系统在功能、行为、约束（性能）等方面的要求。
需求分类 = 功能需求 + 数据需求 + 非功能需求（技术分类）
客户/业务 常常提出的都是 方案级需求，我们更应探寻问题级需求。
用户本质需求 = 傲慢 + 嫉妒 + 贪婪 + 懒惰 + 色欲 + 暴怒 + 暴食
KANO 模型
KANO模型 = 基本型需求 + 期望型需求 + 兴奋型需求 - 无差异型需求 - 反向型需求
- 基本型需求 需求满足时，用户不会感到满意。需求不满足时，用户会很不满意。用户不说也要做到。 如系统的稳定、可靠、不闪退。
- 期望型需求 需求满足时，用户会感到很满意。需求不满足时，用户的不满意显著增加。用户清楚知道。如系统要流畅、好用。
- 兴奋型需求 该需求超过用户对产品本来的期望，使得用户的满意度急剧上升。用户不知道。如打车的红包，酒店WIFI
- 无差异型需求 需求被满足或未被满足，都不会对用户的满意度造成影响。如赠送无价值的代金卷
- 反向型需求 需求与用户的满意度呈反向相关，满足该要求，反而会使用户的满意度下降。如弹窗广告。
全力满足基本型需求，尽量满足期望型需求，争取满足兴奋型需求
价值需求
- 系统为客户解决了什么问题，创造了哪些机会
- 该系统最关键的干系人是谁
- 重要干系人的关注点，以及顾虑（阻力点）
详细需求
- 功能需求 为了给客户提供业务，管理，维护等支持，应提供哪些功能
- 数据需求 涉及的问题域都有哪些数据，数据间关系如何
- 非功能需求 业务环境的约束 和 质量要求 （例如 内网部署 信创等）
功能需求
业务支持
思考
- 根据目标和干系人关注点，系统涉及的业务流程
- 是否需优化流程
- 本系统是否要全流程都支持
- 哪些业务可以模型化（复用该系统经验，通用）
管理支持
思考
- 管理层用户希望实现哪些管理/审批/控制类需求
- 希望系统做哪些辅助决策
- 实现上述要求，需什么数据，如何获得。
维护支持
思考
- 谁来维护 （维护人角色，岗位）
- 维护任务清单
从维护场景出发，例如 排错 场景，而不是 日志功能。
数据需求
- 系统问题域中的业务数据
- 他们之间的关系
- 每个业务数据的具体构成
非功能需求
系统所处环境存在的约束和质量要求。
该步骤可以用质量树梳理，质量场景分析法来确认。
不可盲目定性，定量，以偏概全。如简单的说高可用，可并发，或随便写个支持1亿QPS，或是所有XX都如何如何。
业务驱动需求
从技术角度思考需求，是方案级需求。 从用户视角思考需求，是问题级需求。
业务人员提需求，往往都是提出方案，你应该这里加个字段，那里排个序，但是我们应更进一步思考，探讨，这背后的问题是什么。
本质原因是 业务/客户 并非解决方案专家。他们提的方案不一定是好的方案。
业务或者客户如果提出的是 方案级需求，直接实现某个功能这种，直接开发完成后，可能仍然不是客户想要的，还是得改。沉没成本较高。
需求分析流程
- 收集需求：对用户需求进行收集整理
- 分析需求：对需求进行分析，挖掘用户真实需求
- 需求评估：筛选过滤掉不可行的需求
- 需求设计：针对用户需求提出解决方案
- 验证/确认需求：需求审查 + 需求会签 + 需求评审
需求收集渠道
需求收集渠道 = 公司业务 + 竞品分析 + 头脑风暴 + 可用性测试 + 问卷调查 + 用户反馈 + 运营数据分析
- 公司业务 通过公司业务发展方向，挖掘信息系统建设需求，通过功能支持业务开展
- 竞品分析 通过对同行业或跨行业、类似产品的分析，分析优缺点、获取参考需求
- 头脑风暴 邀请一群人围绕一个特定的兴趣领域自由的讨论、产生新的观点
- 可用性测试 向用户提供Demo简易版本试用，观察并了解用户的使用体验，收集优化建议
- 问卷调查 对于无法面对面沟通的、大范围的客户，以问卷方式开展需求收集活动
- 用户反馈 提供用户反馈机制，通过收集用户上报的意见建议作为系统优化需求采集途径
- 运营数据分析 通过监控系统运营过程中的指标、使用量等数据，发现功能运行变化的趋势，识别未来优化方向
5W2H找到需求本质
需求的本质 = 用户真实的需求，寻找的方法 = 刨根问底法（5W2H）
用户在 什么场景下 通过什么任务 完成什么 目标
- 用户：群体，角色，特点，规模或数量（who）
- 场景：任务发生的环境和具体事件，时间（when）空间与地点（where）事件（what）
- 目标：why
- 任务：为了达成目标，用户的操作流程（how），愿意投入的代价（how much）
客户需求常见问题
- 用户更倾向于直接提出解决方案，而非问题
- 描述需求的时候，不自觉加工自身观点
- 需求在不同阶段，用户给出不同的需求观点
避免上述问题
- 可以通过5W2H寻找本质
- 思考业务价值
- 该需求是否匹配用户预期，符合产品定位
需求沟通原则
需求沟通目的是理解用户的需求，不要过多考虑其他，比如需求是否能实现
需求沟通原则 = 同级别人员沟通；否则沟通结果变成领导一个人的意见
在讨论需求过程中，是否要挖掘客户潜在需求？ 只挖掘问题，不挖掘方案。因为在问题级的探讨，客户是理性的；而在方案级的探讨，客户是感性的。
沟通方式及技巧
- 正式或者非正式的访谈
- 现场演示、观摩
- 确定沟通的主题范围
- 沟通过程中适当的引导
- 准确的记录沟通的结果并在后续完成结论确认
寻找解决方案
解决方案 = 积极 + 转移 + 否定 + 脑洞 + 拆解
例如，如何提升公司内网新闻的阅读量
积极：如何让用户每天阅读，如何让用户更方便的阅读
转移：如何让系统提醒用户阅读，如何让其他系统提醒用户阅读
否定：如何让用户不得不阅读
脑洞：如何让用户没有网络也能阅读
拆解：用户首日什么样的行为能提高次日阅读率
需求描述
构成需求的要素
需求 = 用户 + 场景 + 诉求 + 任务
| 目标 | 用户 | 场景 | 诉求 | 任务 |
|---|---|---|---|---|
| 增加导出功能 | 内勤 | 方便汇总 | 计算数据 | 数据导出 |
价值评估
需求的价值 = 用户价值 + 产品价值 + 商业价值 - 反向损失
评价一个需求是否值得提出，是否具有实施的价值，可以考虑从用户价值、产品价值、商业价值 来进行评估，如果找不到也可以从反向损失来评估
-
用户价值 覆盖用户的群体范围，能给用户带来什么样的好处，能够满足用户什么需求，能够为用户解决什么样的痛点
-
产品价值 这个需求对产品、系统各项运营指标能产生什么样的影响
-
商业价值 需求对公司经营方向、产品战略、业务发展、监管合规的正向的支持 力度。是否存在商业潜力
-
反向损失 如果不实施该需求，那么会对公司产生哪些损失、风险
需求优先级方法
ROI（投入产出比）
投入时间 预期价值 四象限
需求优先级：P0 > P1 > P2 > P3
ICE
ICE 是三个单词的简称
Impact 预期影响 Confidence 自信程度 指对这个功能上线后对目标达成的效果的预测 Easy 实现难度
| 需求 | 预期影响 | 自信程度 | 实现难易 | 综合打分 |
|---|---|---|---|---|
| 1 | 3 | 4 | 5 | 12 |
| 2 | 1 | 2 | 3 | 6 |
需求优先级 2 > 1
重要紧急四象限
比较简单的需求可以用该方式。
需求验证
需求验证 = 需求审查 + 需求会签 + 需求评审
目标是发现尽可能多的错误，减少因为需求的错误而带来的工作量浪费
主要手段是评审
重点要从用户角度进行审查
验证时注意表达方式
你这个地方有问题 -> 替换为 -> 我怎么没看懂呢？你是否可以解释一下
你这个地方错了 -> 替换为 -> 按我的理解，这里的描述与实际情况不太一样，建议确认一下
业务报表需求分析
业务报表分析 = 厘清报表的使用场景 + 报表的内容 + 输出的相关要求
一、明确报表的使用场景
核心是厘清三个问题：谁使用、为什么用、使用频率如何。
二、分析报表的内容
报表的本质是“内容”，即生成报表之前要输入什么条件，从哪里得到所需数据源，生成哪些数据项及其格式、计算方法。
数据来源：直接列出该报表应该从哪些数据表中获得基础数据。另外，还应该说明统计口径，也就是对哪些数据进行统计。
报表中的数据项、格式、计算方法：逐一列举报表中各个数据项，以及每个数据项的格式、计算方法。
三、输出的相关要求
首先，用一张“表头”来呈现报表的输出要求； 其次，还要考虑报表的展示细节，如分页、汇总、排序字段，以及输出到PC还是手机上等等
用户激励
用户激励 = 内在激励 + 外在激励。外在激励和内在激励是两个心理学的名词
外在激励：驱使人的行为发生改变的外部因素，比如获得奖金、名誉等奖励
内在激励：驱使一个人内心获得饥渴感、满足感、愉悦感的内部因素。如学习新知识、成就感
设计用户激励第一步：考虑如何用外在激励和内在激励来交替地持续激励用户
例如：排行榜，分享打卡（运动炫耀，工作炫耀），达成目标领取小奖励（可以是知识类奖励，知识图谱之类）
设计用户激励第二步：定义获得能力并努力降低门槛。
例如：每日工作任务：不需要新手保险业务员思考每天干什么？只要按照任务提示，做好客户沟通、交流，就可以完成销售工作。
后评估
目的：通过不定期的对需求实施效果的评估，来发现功能应用情况的变化，了解用户行为的调整，发现用户需求的迁移，以便于提出优化方向或者做出下线安排。
后评估内容 = 目标达成率 + 用户活跃度 + 使用量 + 业务转化率 + 功能响应时间 + 用户满意度
目标达成率：评估需求实现后，是否完成预期目标，达成目标效能。如未达成需要评估差距以及原因
用户活跃度：使用该功能的用户群体和数量是否与预期一致，偏差原因
使用量：用户的点击率或者功能的使用比率，评价该功能是否符合实际场景
业务转化率：通过该需求实现的系统功能，对于业务提升或者转化的效率是否符合预期
功能响应时间：系统功能在使用过程中，对用户请求的响应时间，是否会提升操作者的效率
用户满意度：用户对于系统功能在使用过程中的操作体验是否满意
