名词百科
什么是 PRD 需求文档？
一句话定义
PRD（Product Requirements Document，产品需求文档）是描述产品要做什么、为谁做、怎么判断做完的文档，是开发、测试与业务方对齐的依据。
它到底是什么
PRD 的核心不是「写得长」，而是可判断：每条需求都要能被回答「做完了没有」。写「优化用户体验」无法验收，写「列表页在弱网下 3 秒内展示首屏」可以。
它同时是变更的依据。需求变更是常态，有文档才能判断哪些是原范围、哪些是新增，进而谈工期与费用。
怎么运作的
背景与目标：为什么做、解决什么问题、成功怎么衡量。缺这段，后续所有取舍都失去依据。
用户与场景：谁在什么情况下使用，走什么流程。用场景串起功能，比列功能清单更容易被理解。
功能说明：每个功能的入口、操作、状态、异常处理、权限。异常与权限最容易被漏，也最容易在上线后暴露。
非功能要求：性能、兼容性、数据量、安全要求。这些往往是验收争议的来源。
验收标准：可执行的判断条件。没有这一节，验收就会变成主观判断。
容易混的几个概念
- 需求文档与原型：原型表达界面与流程，PRD 补充规则与边界。
- 技术方案：研发侧的实现设计，与 PRD 视角不同。
- 用户故事：轻量的需求描述形式，颗粒度小于完整 PRD。
- 合同附件：对外的需求范围说明，通常由 PRD 提炼而成。
常见问题
PRD 要写多细？
细到「开发和测试对同一个功能的理解一致」为止。过细会消耗大量时间在无人看的章节上，过粗会在开发中反复澄清。判断标准是澄清次数。
敏捷开发还需要 PRD 吗？
需要，但形式可以更轻。可以用需求条目加验收条件替代长文档，关键是每一条都可判断、可追溯，而不是有没有那份文件。
J 项目运维 · 同组词条
需求调研需求调研是通过访谈、观察、数据分析等方式弄清用户真正要解决的问题；需求分析是把调研结果整理成可开发、可验收的规格。调研找问题，分析定方案。原型图原型图是产品界面的低保真示意，表达布局与元素位置；线框图更强调结构骨架，通常不含视觉细节。两者用于在开发前确认信息架构与流程。迭代迭代是按固定周期交付一部分可用功能的工作方式；版本管理是对不同发布版本的内容、时间与兼容性进行规划与控制。功能测试功能测试是验证软件功能是否符合需求规格的测试，测试用例是描述输入、操作步骤与预期结果的文档，是功能测试的执行依据。性能测试性能测试是评估系统在特定负载下的响应时间与资源消耗；压力测试是逐步加压直到系统崩溃，用于找出容量上限与瓶颈位置。安全测试安全测试是检查系统是否存在可被利用的漏洞的测试活动；渗透测试是模拟攻击者视角，尝试实际攻破系统，以验证防护是否有效。BUG管理BUG 是软件中不符合预期的缺陷；缺陷管理是记录、分级、分配、跟踪与验证缺陷直至关闭的流程，通常借助缺陷跟踪系统实现。灰度发布灰度发布是把新版本先开放给小部分用户，观察运行情况后再逐步扩大范围的上线方式。它用于降低全量发布带来的风险。