2. 需求分类与结构化梳理
适用场景：当硬件产品团队完成原始需求采集后，进入第一轮结构化分类。本流程适用于产品定义阶段早期（T0～T1窗口），用于将零散的用户诉求、技术指标、合规约束映射到四大需求分组，为后续Roadmap优先级排序和资源配置建立统一框架。典型触发节点：市场调研结束、用户访谈记录完成、竞品分析报告交付之后。
2.1 前置条件
- 已完成《原始需求归档清单》（含用户原话、场景描述、来源、提出时间）。
- 项目团队已确认产品目标市场与法规准入范围（如CE、FCC、3C、UL等）。
- 配备至少一名硬件产品经理、一名系统架构师、一名法规认证工程师。
- 已建立需求分类模板（Excel或协作平台看板），包含四个分组标签。
2.2 责任边界
| 角色 | 职责 | 决策权 |
|---|---|---|
| 硬件产品经理 | 主持分类会议，判断需求归属，定义各组优先级权重 | 可裁定模糊需求归属 |
| 系统架构师 | 评估需求技术可行性，补充性能指标边界 | 对性能需求的可量化性负责 |
| 法规认证工程师 | 识别强制法规需求，标记合规风险项 | 一票否决未达标法规需求 |
| 体验设计代表 | 评审体验需求的用户价值与交互成本 | 建议但不强制 |
2.3 操作步骤
- 粗筛分组：将每一条原始需求按“满足什么属性”初分到功能/性能/体验/法规四个桶。功能需求回答“做什么”，性能需求回答“做到多好”，体验需求回答“人如何用”，法规需求回答“必须遵守什么”。
- 冲突检测与合并：同一需求可能同时跨组（如“充电速度越快越好”既属性能也属体验？），使用下表现行冲突表进行二次裁定：
- 层级化编码：为每条需求生成
GRP-{组编号}-{序号}编码，例如FUNC-001（功能）、PERF-012（性能）、EXP-007（体验）、REG-003（法规）。 - 附原始上下文：在编码旁保留原始需求原文、来源、提出时间，防止分类后信息失真。
- 初版分组Review：团队合议，确认每组边界，标注“待澄清”需求进入2.6异常处理。
操作陷阱提醒：
▪ 避免“把所有技术参数都放进性能需求”——耗电量、待机电流等既是性能约束也可能触发法规（如待机能耗法规）。
▪ 体验需求不要写成“界面美观”这类无法验证的描述，应拆解为可观察行为（如“用户单次设置操作≤3步”）。
▪ 法规需求必须精确到标准编号（例：IEC 62368-1:2023、GB 4943.1-2022），不能仅写“满足安全要求”。
▪ 避免“把所有技术参数都放进性能需求”——耗电量、待机电流等既是性能约束也可能触发法规（如待机能耗法规）。
▪ 体验需求不要写成“界面美观”这类无法验证的描述，应拆解为可观察行为（如“用户单次设置操作≤3步”）。
▪ 法规需求必须精确到标准编号（例：IEC 62368-1:2023、GB 4943.1-2022），不能仅写“满足安全要求”。
2.4 冲突检测与合并表
| 模糊需求示例 | 可能归属 | 最终裁定规则 |
|---|---|---|
| “希望充电速度越快越好” | 性能（充电功率） 体验（等待时间） | 以性能指标定义（如“30min充至80%”），体验作为验收前提（用户主观可接受） |
| “整机外壳不能发烫” | 性能（温升限值） 法规（IEC 62368温度要求） | 纳入法规需求（强制限值），性能需求作为研发目标 |
| “APP连接后自动同步数据” | 功能（自动同步） 性能（同步延迟） | 功能需求定义行为，性能需求定义延迟指标（如<10s） |
2.5 输入输出物
输入物：
▪ 《原始需求归档清单》（版本号V1.0+）
▪ 《目标市场准入标准清单》（含目标国家/地区法规列表）
▪ 《竞品需求分类参考表》（可选）
输出物：
▪ 《需求分类结构化清单》（四组，含编码、原始上下文、状态标记）
▪ 《分类会议纪要》（含模糊需求裁定记录）
▪ 《待澄清需求池》（进入异常处理）
▪ 《原始需求归档清单》（版本号V1.0+）
▪ 《目标市场准入标准清单》（含目标国家/地区法规列表）
▪ 《竞品需求分类参考表》（可选）
输出物：
▪ 《需求分类结构化清单》（四组，含编码、原始上下文、状态标记）
▪ 《分类会议纪要》（含模糊需求裁定记录）
▪ 《待澄清需求池》（进入异常处理）
2.6 异常处理
- 类别归属模糊：若团队在15分钟内无法达成一致，标记为
PENDING-TBD，暂归入“待澄清需求池”，后续由产品经理发起专项澄清（与用户/技术专家二次访谈）。 - 法规需求缺失：法规工程师发现关键标准未覆盖时，立即升级至产品总监，启动法规差距分析，增加临时强制需求分组，同时更新准入清单。
- 体验需求无法量化：退回给体验设计代表，要求在5个工作日内转换为可测量的用户行为指标（如“用户满意度评分≥4.0/5.0”）。
- 需求重复/冲突：合并同类需求，保留最完整描述；原始来源皆附加在新记录
Duplicate-Origin字段中。
注意：法规需求分类出现争议时，法规认证工程师拥有“一票升格权”——即任何涉及安全或法规的风险项，即使团队争议，也应先按法规需求处理，后续再降级。不得因项目进度压力而弱化法规分类。
2.7 验收标准
- 所有原始需求（100%）均已分配到且仅分配到四个分组之一，无遗漏。
- 每条需求已获得唯一GRP编码，且编码与原始需求清单可双向追溯。
- 法规分组需求100%对标适用的标准编号（不能仅写“满足安全”）。
- 模糊/冲突需求完成裁定，并在会议纪要中记录裁定理由和参与人。
- 待澄清需求≤总需求的10%，且均已明确负责人和解决截止时间。
- 输出《需求分类结构化清单》通过至少1名系统架构师和1名法规工程师签字放行。
2.8 记录材料
| 记录名称 | 格式 | 保管位置 | 保留周期 |
|---|---|---|---|
| 需求分类结构化清单 | Excel / CSV | 产品共享盘 / Jira Epic | 项目结束+6个月 |
| 分类会议纪要（含模糊裁决） | Markdown / Confluence | 项目Wiki | 项目结束+3年 |
| 待澄清需求池 | Jira Issue / Trello | 产品Backlog | 需求澄清后归档 |
| 法规准入标记录 | PDF + 标准原文链接 | 合规知识库 | 产品退市前 |
模板参考片段：
实际项目中使用Excel分Sheet管理：Sheet1=功能需求（FUNC）、Sheet2=性能需求（PERF）、Sheet3=体验需求（EXP）、Sheet4=法规需求（REG），外加一个Sheet5=待澄清。每列包含：编码、原始需求、来源、提出时间、状态（已确认/待澄清/已合并）、备注。
实际项目中使用Excel分Sheet管理：Sheet1=功能需求（FUNC）、Sheet2=性能需求（PERF）、Sheet3=体验需求（EXP）、Sheet4=法规需求（REG），外加一个Sheet5=待澄清。每列包含：编码、原始需求、来源、提出时间、状态（已确认/待澄清/已合并）、备注。