第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 个前提?⑥ 排除项是否涵盖了常见的蔓延风险点?
① 场景中的“用户”是否具体?② 目标是否可量化?③ 验收条件是否包含“输入-输出”或“状态变化”?
④ 优先级是否与业务价值匹配?⑤ 假设是否列出了最关键的 3~5 个前提?⑥ 排除项是否涵盖了常见的蔓延风险点?
最佳实践: 每完成一个需求卡片,立即使用验收条件反向检查用户场景是否可覆盖。若验收条件无法直接对应场景中的“想要……”,说明要素间逻辑断裂,需修正。