名词百科
什么是需求调研 / 需求分析？
一句话定义
需求调研是通过访谈、观察、数据分析等方式弄清用户真正要解决的问题；需求分析是把调研结果整理成可开发、可验收的规格。调研找问题，分析定方案。
它到底是什么
两者的分工是「发现」与「定义」。调研阶段要理解现状与痛点，允许模糊；分析阶段要输出明确的角色、场景、流程与验收条件，不能含糊。
最常见的问题是跳过调研直接分析：用户说「我要一个报表」，直接做报表，结果做出来没人用——真实需求可能是「老板每周要的数据能不能自动发给他」。
怎么运作的
调研方法：访谈（问清现状与例外情况）、现场观察（发现没说出口的环节）、数据分析（用现有数据验证问题规模）、竞品分析（看别人怎么解）。
分析产出：用户角色、使用场景、业务流程、功能清单、非功能要求（性能、权限、兼容性）。
关键技巧：多问「不做会怎样」来判断优先级；关注例外流程（正常流程往往最简单，例外才是真正的工作量）；区分「想要」与「需要」。
确认：分析结果要让业务方确认，尤其是流程与状态定义。误解在需求阶段的修正成本最低。
容易混的几个概念
- PRD：需求分析的输出文档，不是调研本身。
- 用户研究：更偏定性的用户理解，范围比需求调研宽。
- 业务分析：关注业务价值与流程，与系统需求分析侧重不同。
- 原型设计：需求的具象表达，帮助确认理解是否一致。
常见问题
需求调研要多久？
取决于业务复杂度与参与方数量。判断标准不是时长，而是「例外流程是否都问到了」。只聊正常流程的调研，通常会在开发中期返工。
业务方说不清需求怎么办？
用具体场景逼出细节：给一个真实案例，让他按现有方式走一遍，记录每一步用了什么工具、查了什么数据。抽象描述往往掩盖了真实的复杂度。
J 项目运维 · 同组词条
PRDPRD（Product Requirements Document，产品需求文档）是描述产品要做什么、为谁做、怎么判断做完的文档，是开发、测试与业务方对齐的依据。原型图原型图是产品界面的低保真示意，表达布局与元素位置；线框图更强调结构骨架，通常不含视觉细节。两者用于在开发前确认信息架构与流程。迭代迭代是按固定周期交付一部分可用功能的工作方式；版本管理是对不同发布版本的内容、时间与兼容性进行规划与控制。功能测试功能测试是验证软件功能是否符合需求规格的测试，测试用例是描述输入、操作步骤与预期结果的文档，是功能测试的执行依据。性能测试性能测试是评估系统在特定负载下的响应时间与资源消耗；压力测试是逐步加压直到系统崩溃，用于找出容量上限与瓶颈位置。安全测试安全测试是检查系统是否存在可被利用的漏洞的测试活动；渗透测试是模拟攻击者视角，尝试实际攻破系统，以验证防护是否有效。BUG管理BUG 是软件中不符合预期的缺陷；缺陷管理是记录、分级、分配、跟踪与验证缺陷直至关闭的流程，通常借助缺陷跟踪系统实现。灰度发布灰度发布是把新版本先开放给小部分用户，观察运行情况后再逐步扩大范围的上线方式。它用于降低全量发布带来的风险。