第3章 需求描述结构化模板:六要素法

适用场景

本章节适用于产品经理、业务分析人员在需求澄清阶段,将零散的原始需求转化为结构化的、无歧义的描述文档。典型场景包括:

  • 产品需求文档(PRD)编写前的需求拆解
  • 跨部门需求评审前的需求细化
  • 敏捷史诗(Epic)与用户故事(User Story)的撰写
  • 外包或合作开发需求传递时的边界对齐

前置条件

  • 已完成需求收集并与干系人达成初步共识
  • 产品经理已识别关键用户角色和核心业务流程
  • 具备基础的需求管理工具或模板(如 Confluence、Excel、Jira 等)

操作步骤

严格按照“六要素”顺序逐一填充,避免跳跃或遗漏。每个要素的说明与示例如下:

步骤 要素 定义与填写要求 示例
1 用户场景 描述谁在什么情境下需要做什么,采用“作为……,想要……,以便……”句式。 作为库存管理员,想要在手机端扫描条码自动录入出入库数据,以便减少人工差错。
2 业务目标 需求要解决的具体业务问题或达成的可量化指标,通常与KPI或OKR关联。 将库存盘点准确率从 95% 提升至 99.5%,单次盘点时间缩短 40%。
3 验收条件 可测试、可验证的完成标准,通常用“若……则……”或给定输入输出定义。 扫描任意商品条码后,系统在 0.5 秒内显示商品名称、库存量,并自动更新数据库。
4 优先级标记 使用 MoSCoW 法则(Must/Should/Could/Won't)或 P0-P3 标记业务紧迫程度。 P1(Must):条码扫描录入;P2(Should):支持批量扫描。
5 边界假设 实现需求所依赖的外部条件、系统环境或第三方服务,若不成立则需求需重新评估。 假设手机摄像头支持 720p 以上分辨率;假设仓库 Wi-Fi 覆盖率不低于 90%。
6 排除项 明确本次需求明确不包含的功能或场景,避免后期范围蔓延。 本需求不包含电子秤自动称重功能;不包含 PDA 设备管理功能。

填写顺序建议

先写用户场景和业务目标定方向,再列验收条件;然后标注优先级,补充边界假设,最后用排除项划清界限。产品经理需将每一条需求独立以六要素形式记录,形成需求卡片。

输入输出物

类型具体内容
输入原始需求记录(会议纪要、用户反馈、调研报告)、业务流程图、用户画像
输出《结构化需求描述卡片》(每张卡包含完整六要素)、需求评审预审材料

责任边界

  • 产品经理:负责六要素的完整性和准确性,组织内部初审。
  • 业务方/需求提出方:确认用户场景、业务目标、验收条件是否符合真实业务诉求。
  • 开发团队代表:评估边界假设和排除项的技术可行性,识别潜在风险。

记录材料

  • 《六要素需求模板》(建议工具内固化,字段含:需求ID、版本号、填写人、填写日期)
  • 《需求澄清沟通记录》(含未达成一致项的待办清单)
  • 《需求变更登记表》(若后期调整要素内容,需记录变更原因及审批人)

异常处理

常见异常与应对:
  • 要素缺失(如未写排除项):退回补充,并标记需求为“待完善”,不可进入评审。
  • 验收条件模糊(如“性能良好”):要求给出具体阈值或可测指标,否则定义为不符合交付标准。
  • 边界假设与排除项矛盾(如假设含A,排除项又排除A):由产品经理与业务方重新协商,修改至逻辑一致。
  • 优先级冲突:触发优先级投票或由产品负责人裁决,更新到需求列表中。

验收标准

单个需求卡片满足以下所有条件方可进入下一阶段:

  • 六要素均填写完整,无空白项。
  • 用户场景包含具体角色、动作和业务价值。
  • 业务目标包含定量或定性可验证指标。
  • 验收条件可被测试用例覆盖。
  • 优先级标记有明确的分类依据。
  • 边界假设与排除项无内部矛盾。
核查清单(自检用): 用下面六个问题快速核验需求卡片质量:
① 场景中的“用户”是否具体?② 目标是否可量化?③ 验收条件是否包含“输入-输出”或“状态变化”?
④ 优先级是否与业务价值匹配?⑤ 假设是否列出了最关键的 3~5 个前提?⑥ 排除项是否涵盖了常见的蔓延风险点?
需求描述结构化模板:六要素关系图 需求卡片 六要素聚合 用户场景 业务目标 验收条件 优先级标记 边界假设 排除项 建议填写顺序:场景→目标→验收→优先级→假设→排除项
最佳实践: 每完成一个需求卡片,立即使用验收条件反向检查用户场景是否可覆盖。若验收条件无法直接对应场景中的“想要……”,说明要素间逻辑断裂,需修正。