需求分析

它是什么

需求分析是把一句模糊想法，拆解成「为谁解决什么问题、目标是什么、有什么约束、怎样算完成」的过程。它的产出是可验证的需求与验收标准，而不是一份越长越好的文档。

为什么需要它

模糊需求会在开发中反复返工：做偏了、漏了边界、或完成标准无法判断。需求分析把共识提前到动手之前，让设计、开发和测试对「做什么、不做什么、怎么验收」有同一份依据。

它如何工作

先确认问题和目标用户，再区分「用户需求」与「产品需求」：用户需求是问题，产品需求是解决方案。接着补充约束（时间、权限、数据、合规）和验收条件，最后用优先级决定先做哪一部分。整个过程强调可验证，而不是术语堆砌。

必须澄清的误会

需求分析 ≠ 用户研究。 用户研究是采集素材的方法（访谈、观察、数据），需求分析是对素材做判断的过程，前者提供原料。

需求分析 ≠ 产品需求文档。 需求分析产出判断与取舍理由，PRD 产出发给团队的文档，两者是「想清楚」与「写下来」。

真实例子

「给客服加个 AI」不是需求。分析后变成：坐席在处理退款类问题时，能在一个界面看到该客户最近 90 天的订单与适用政策，并标出政策版本；命中退款场景时提供可编辑的回复草稿。完成标准是坐席找到政策的时间下降，而不是「用了 AI」。

什么时候适合与不适合

适合：需求模糊、涉及多方、或错误代价高。慎用：改动很小、团队已高度对齐、或还在探索方向时，过早写详细需求会锁死错误方案。需求分析是降低返工风险的手段，不是流程形式。

亲自试一下

拿一个你正在做的功能，写下三句话：①谁在什么情况下遇到什么问题；②我们提供什么来解决；③完成后怎样验证它真的解决了。如果第三句写不出可观察的标准，就说明需求还没分析清楚。

接下来学什么

把分析结论写进 PRD，并用验收标准和用户故事让需求可交付、可验证。

来源与修订

需求工程的定义与流程依据 IREB 的需求工程框架 [S1] 与需求分析的通用描述 [S2]。本版区分用户需求与产品需求，不把「需求分析」等同于写文档。