本文适合：刚入行被"需求变更"折磨过的新工程师、想系统性学习需求分析方法论的产品经理、带团队做交付项目经常被客户"打脸"的项目负责人。
你将收获：软件需求四步法的完整拆解、九种用户调研方法的适用场景对比、NABCD竞争性需求分析模型、功能分析四象限法、需求管理在AI时代的新变化。
写在前面
前七章从个人技术讲到团队流程，解决的是"怎么干"的问题。第八章开始进入"干什么"的问题——需求分析。
邹欣老师在微软的实战经验告诉我：项目失败的第一大原因，从来不是技术不行，而是需求没搞对。 用户说的不一定是想要的，想要的不一定是需要的。需求分析的本质，是把用户脑子里的"模糊感觉"翻译成团队可以执行的"明确规格"。
第四版在这一章融入了AI时代需求获取的新手段，值得重点关注。
章际衔接：从"怎么干"到"干什么"
|
维度 |
第七章（实战中的软件工程） |
第八章（需求分析） |
|
核心问题 |
团队怎么协作把事干成 |
团队要干的事到底是什么 |
|
视角 |
方法论与流程 |
用户与价值 |
|
关键产出 |
MSF框架、团队模型 |
需求规格、功能优先级 |
|
比喻 |
"作战手册" |
"情报侦察" |
一句话衔接： 前面教你"怎么打仗"，这章教你"打什么仗、先打哪个仗"。
01 | 软件需求：四步法
1.1 需求从哪里来
软件团队要找到需求，不是坐在办公室里等需求从天上掉下来。需求来自四个方向：
|
来源 |
说明 |
举例 |
|
利益相关者 |
最终用户、客户、市场分析师、监管机构 |
纪检干部希望审批流程简化 |
|
管理机构 |
合规要求、行业标准 |
数据安全法要求用户数据加密存储 |
|
企业自身 |
商业目标、产品战略 |
公司要打造"河南模式"标杆产品 |
|
技术团队 |
技术演进带来的新可能 |
AI能力成熟后可以自动生成会议纪要 |
1.2 需求四步法
|
步骤 |
名称 |
核心动作 |
我的理解 |
|
1 |
获取和引导需求 |
找到利益相关者，挖掘并引导他们表达需求 |
不是"问"需求，是"挖"需求 |
|
2 |
分析和定义需求 |
规整、量化、定义优先级 |
把"模糊感觉"变成"明确规格" |
|
3 |
验证需求 |
通过原型、报告与利益相关者确认 |
别自己以为搞对了，要回去对一遍 |
|
4 |
管理需求 |
生命周期内持续管理需求变更 |
需求不是一次性的，是活的 |
1.3 软件需求的四种类型
|
类型 |
说明 |
举例 |
|
产品功能需求 |
必须实现的具体功能 |
审批流程在线流转 |
|
开发过程需求 |
对开发过程的要求 |
安全等级保护三级合规 |
|
非功能需求 |
性能、安全、可用性等 |
页面加载3秒内、7×24可用 |
|
综合需求 |
跨模块、跨系统的约束 |
与OA系统数据互通 |
我的实战感悟
做党政平台这几年，最深的教训就是——用户说的"我要一个审批功能"和实际需要的"我需要一个能流转、能追踪、能归档的审批闭环"完全是两码事。 用户只说他看到的"冰山一角"，需求分析的功夫在"水面以下"。
需求获取不是记录用户说什么，而是理解用户为什么这么说。
一句话提炼
需求四步法：获取要"挖"、定义要"量化"、验证要"对回"、管理要"持续"。
02 | 利益相关者：谁的需求才算数
2.1 五类利益相关者
|
利益相关者 |
关心什么 |
需求特征 |
|
最终用户 |
好不好用、效率高不高 |
功能需求为主 |
|
客户/采购方 |
值不值、能不能交差 |
商业需求为主 |
|
市场分析师 |
竞争力、差异化 |
战略需求为主 |
|
监管机构 |
合规性、安全性 |
约束需求为主 |
|
软件团队 |
可行性、技术成本 |
实现需求为主 |
2.2 谁的需求优先级最高？
没有标准答案。但有一个原则：不同阶段，不同利益相关者的话语权不同。
· 项目立项阶段 → 客户和市场分析师说了算
· 需求细化阶段 → 最终用户说了算
· 技术选型阶段 → 软件团队说了算
· 验收交付阶段 → 监管机构和客户说了算
我的实战感悟
我们平台涉及省、市、县三级用户，需求经常"打架"——省里要全面覆盖，市里要灵活配置，县里要简单好用。这时候不能谁级别高就听谁的，要回到业务价值判断：哪个需求带来的业务价值最大，就先满足哪个。然后向其他方解释"为什么暂时放后面"。
管理利益相关者，本质是管理期望。
一句话提炼
利益相关者不止"用户"一个角色。搞清楚"谁的需求算数"，比"需求是什么"更重要。
03 | 用户调研：九种方法各有所长
3.1 九种方法速查表
|
方法 |
做什么 |
适合什么场景 |
成本 |
|
焦点小组 |
一群目标用户代表集体讨论 |
探索性需求收集 |
中 |
|
深入面谈 |
一对一深度访谈 |
理解深层动机和痛点 |
高 |
|
卡片分类 |
把需求做成卡片反复归类排序 |
需求结构化整理 |
低 |
|
用户调查问卷 |
大规模定量调研 |
验证假设、统计偏好 |
低 |
|
用户日志研究 |
用户记录日常使用体验 |
发现隐性需求 |
中 |
|
人类学调查 |
深入用户工作现场观察 |
理解真实工作场景 |
高 |
|
眼动跟踪 |
追踪用户视线焦点 |
界面优化 |
高 |
|
快速原型调研 |
做原型让用户试用 |
验证功能方向 |
中 |
|
A/B测试 |
两种方案对比测试 |
优化细节决策 |
中 |
3.2 怎么选
不同阶段搭配不同方法：
|
阶段 |
推荐方法 |
目的 |
|
需求探索期 |
焦点小组 + 深入面谈 |
发现需求 |
|
需求定义期 |
卡片分类 + 用户调查问卷 |
结构化需求 |
|
需求验证期 |
快速原型 + A/B测试 |
验证方向 |
|
持续优化期 |
用户日志 + 眼动跟踪 |
发现改进点 |
3.3 人类学调查：被低估的方法
书里专门提到"人类学调查"（Ethnographic Study）——听起来学术，其实就是去用户的工作现场待着，看他怎么干活。
这个方法被严重低估。很多团队做需求调研只靠"开会+问卷"，但用户在会上说的是"理想自我"，在现场做的才是"真实行为"。
我的实战感悟
我带团队做党政平台时，最有效的一次需求调研不是开会，而是去一个县级单位办公室坐了两天。我发现干部们实际工作中有大量"表格来回填"的重复劳动——这个痛点他们在需求会上从来没提过，因为他们觉得"这就是正常工作"。
用户不知道什么是"可以更好的"，因为他们习惯了"不好的"。
一句话提炼
九种调研方法不是选一个，而是按阶段组合用。最有效的方法往往是"去现场"，不是"开会议"。
04 | NABCD模型：竞争性需求分析框架
4.1 五个字母
|
字母 |
含义 |
核心问题 |
我的理解 |
|
N |
Need（需求） |
用户到底需要什么？ |
痛点要够痛，不是"锦上添花" |
|
A |
Approach（做法） |
你打算怎么做？ |
不是技术方案，是解决思路 |
|
B |
Benefit（好处） |
给用户带来什么价值？ |
要可量化——省多少时间、降多少成本 |
|
C |
Competitors（竞争） |
竞品怎么做的？ |
知己知彼，找到差异化 |
|
D |
Delivery（推广） |
怎么交付到用户手中？ |
再好的功能用户用不上等于零 |
4.2 NABCD的用法
NABCD不是写文档的模板，而是思考需求的框架。它逼你回答五个问题，任何一个答不好，这个需求就不该做。
我特别关注的是 C（竞争） 这一项——很多团队做需求分析时完全不看竞品，闭门造车。结果做出来的东西"有需求、有方案、有价值"，但竞品三年前就做了，还做得更好。
我的实战感悟
我们平台做"扫码入企"功能时，先调研了外省已有方案——发现某省的"扫码"只是把纸质登记搬到了线上，企业反映"反而更麻烦了"。我们吸取教训，设计了"一码通行+自动填报+数据穿透"的方案，拿到了差异化优势。
竞品分析不是为了抄，是为了知道"哪里不能抄"。
一句话提炼
NABCD逼你在动手前想清楚：需求真不真、做法行不行、价值够不够、对手强不强、交付通不通。
05 | 功能分析四象限法：先做哪个
5.1 四象限
拿到一堆需求后，怎么排优先级？四象限法按"重要程度"和"实现难度"两个维度划分：
|
象限 |
特征 |
策略 |
|
第一象限 |
重要 + 容易 |
优先做——高价值低成本 |
|
第二象限 |
重要 + 困难 |
规划做——核心功能，需投入资源 |
|
第三象限 |
不重要 + 容易 |
顺手做——有资源时做 |
|
第四象限 |
不重要 + 困难 |
不做——低价值高成本 |
5.2 为什么有效
四象限法好用的原因是它把"优先级"从一维变成了二维。只看"重要性"会忽略成本，只看"难度"会忽略价值。两个维度交叉，决策就清晰了。
我的实战感悟
平台需求多到做不完的时候，我让团队把所有需求贴到四象限图上。结果发现——团队花大量时间做的需求有一半落在"不重要+困难"的第四象限。这些需求往往是领导"拍脑袋"提的，看起来高大上，实际使用率极低。
不是所有需求都值得做。学会说"不做"，比学会说"做"更难。
一句话提炼
四象限法的核心不是"先做什么"，而是"先不做什么"——砍掉第四象限，资源就够用了。
06 | AI时代的需求分析（第四版新增视角）
6.1 AI如何改变需求获取
第四版结合AI时代趋势，需求分析出现了新变化：
|
维度 |
传统方式 |
AI辅助方式 |
|
用户调研 |
人工访谈、问卷 |
AI分析用户行为日志、自动生成画像 |
|
需求挖掘 |
依赖用户表达 |
AI从海量数据中发现隐性需求 |
|
需求文档 |
人工编写PRD |
AI辅助生成需求规格初稿 |
|
需求验证 |
原型 + 用户反馈 |
AI模拟用户场景进行预验证 |
|
竞品分析 |
人工调研 |
AI自动抓取和分析竞品信息 |
6.2 AI不能替代什么
AI能帮你"看到更多"和"分析更快"，但不能替代三件事：
1.价值判断——AI能发现需求，但不能判断哪个需求更值得做
2.利益协调——AI不能帮你处理"省里要全覆盖、县里要简单化"的矛盾
3.创新突破——AI擅长总结已有模式，但真正的创新需求往往来自"用户自己都没意识到"的痛点
我的思考
我们团队现在用AI做用户行为日志分析，确实比人工快十倍——能快速发现"哪个功能使用率低""哪个流程卡在哪一步"。但分析结果出来后，"要不要改、怎么改、先改哪个"还是得人来做决策。
AI是需求分析的"放大镜"，不是"决策者"。
一句话提炼
AI让需求获取更快、更广、更数据化，但价值判断和利益协调仍然是人的核心职责。
07 | 需求管理：需求是活的
7.1 需求变更不可避免
书中强调：需求不是一次性确定的，而是在整个生命周期中持续演进的。原因有三：
1.用户会变——用户用了V1之后才知道自己真正要什么
2.环境会变——政策调整、竞品升级、技术突破
3.认知会变——团队对业务的理解会随深入而变化
7.2 需求管理的核心原则
|
原则 |
说明 |
|
变更可控 |
每次变更有记录、有评审、有影响评估 |
|
优先级可调 |
新需求进来后重新排序，不是"后到先做" |
|
影响可追溯 |
改一个需求，知道影响哪些模块、哪些测试 |
|
版本可回溯 |
需求文档有版本管理，随时可回看历史 |
我的实战感悟
我们平台踩过最大的坑——没有需求变更管理流程。客户随时提需求，开发随时接需求，结果版本发布前一晚还在改代码，上线就是事故。后来建立了"需求变更评审会"机制：每个变更必须评估影响范围、开发成本、测试回归量，超过阈值必须领导审批。
没有管理的需求变更，就是失控的失控。
一句话提炼
需求管理的核心不是"不让变"，而是"变要可控"——每一步变更有记录、有评审、有评估。
干货复盘
|
本章核心概念 |
一句话理解 |
常见误区 |
|
需求四步法 |
获取挖、定义量化、验证对回、管理持续 |
"需求调研就是开个会" |
|
利益相关者 |
谁的需求算数比需求是什么更重要 |
"只听用户的" |
|
九种调研方法 |
按阶段组合用，去现场最有效 |
"发个问卷就够了" |
|
NABCD模型 |
需求真不真、做法行不行、价值够不够、对手强不强、交付通不通 |
"有需求就值得做" |
|
四象限法 |
核心是"先不做什么" |
"领导说的都重要" |
|
AI辅助需求分析 |
放大镜不是决策者 |
"AI能替我做需求决策" |
|
需求管理 |
变要可控，不是不让变 |
"需求定了一就不能改" |
本章最大收获： 需求分析的本质不是"收集"，而是"翻译"——把用户脑子里的模糊感觉翻译成团队能执行的明确规格。四步法教你流程，九种方法教你手段，NABCD教你思考，四象限教你取舍，需求管理教你应对变化。最关键的一句话：用户说的不一定是想要的，想要的不一定是需要的——需求分析的功夫，全在"问"和"答"之间。
下篇分享第九章：项目经理。如果这篇笔记对你有帮助，欢迎转发给也在学软件工程的朋友。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_40967106/article/details/164854075
