第1章 认识场景化需求条目：定义、价值、与功能需求的区别、典型应用场景

场景化需求条目是产品需求文档（PRD）中一种以用户真实使用场景为锚点，描述「谁、在什么情境下、想达成什么目标、遇到什么障碍、期望系统如何响应」的精确化需求表达方式。它不是孤立的功能罗列，而是将业务问题、用户行为和系统行为串联成一个可验证、可追溯的叙事单元。

1.1 场景化需求条目的价值

1.2 与功能需求的核心区别

功能需求关注“系统做什么”，场景化需求关注“用户为什么做、怎么做、做完后带来什么结果”。

• 粒度不同：功能需求可分解为按钮、接口、数据库字段；场景化需求以用户任务为粒度。
• 测试驱动性：场景化需求天然可转化为验收测试用例；功能需求需要二次编写测试场景。
• 沟通成本：场景化需求让非技术人员（业务、设计、测试）直接参与评审，降低认知偏差。

1.3 典型应用场景

1. 新业务需求分析：财务月末对账效率低下→访谈出纳人员后，拆解出“系统自动匹配银行流水与订单明细”的场景条目。
2. 需求优先级排序：基于场景发生频率与业务影响度（如每日高频场景优先、紧急合规场景加塞）。
3. 验收标准制定：每条场景化需求条目直接产出3~5条验收通过条件。
4. 跨团队对齐：产品、开发、测试、业务通过同一场景描述进行需求评审。

1.4 场景化需求条目的结构模板

【场景编号】SC-001
【角色】仓库管理员
【前置条件】已登录系统，当日已有未发货订单
【触发事件】每天17:00系统自动触发 / 或用户手动点击“导出”
【用户目标】获取当日17:00前所有未发货订单明细，用于仓库拣货单打印
【系统响应】生成CSV文件（含：订单号、商品SKU、数量、收货地址）
【后置条件】文件保存至下载目录，记录操作日志
【验收标准】1. 文件字段与模板一致；2. 数据截止到当日17:00；3. 响应时间<3秒

1.5 场景化需求条目的拆解流程

从原始业务问题到最终需求条目，通常需要经过以下步骤：

• ① 用户访谈/业务调研：收集真实痛点和行为细节。
• ② 场景建模：梳理正常流程、异常流程、扩展流程。
• ③ 需求拆解：将场景转化为可落地的最小需求单元。
• ④ 方案表达：用模板化语言书写条目。
• ⑤ 指标验证：定义可量化的验收标准。

下图展示了场景化需求条目在需求生命周期中的位置：

1.6 为什么场景化需求条目是产品需求的核心交付物？

PRD的传统形态是“功能规格说明书”，但现代产品开发（精益、敏捷、DevOps）要求需求能够：

• 快速验证：每个场景条目可在3~5天内开发、测试、上线并观察业务指标。
• 自动化追溯：场景条目与用户故事、测试用例、代码分支建立关联。
• 活文档：需求条目随产品迭代不断更新，而非一次性写完就废弃。