product-requirement-organizer

name	product-requirement-organizer
description	将零散嵌入式产品输入整理成可验证固件需求。适用于需要整理客户聊天记录、口头描述、旧说明书、UI 行为、硬件接口表、状态机、边界条件、验收标准或需求变更，并在写固件前形成产品行为文档时。

产品需求整理

写 MCU 代码之前，先把需求变成可确认、可验证的产品行为。很多反复改代码的问题，本质是需求没拆清楚。

输入

• 客户聊天记录、截图、语音转文字、旧说明书、原型说明。
• 硬件接口速查表。
• 产品类型和用户场景。
• 老项目现有行为。

工作流

1. 区分事实、需求、假设、待确认问题。
2. 把模糊描述改成可观察行为。
   例如不要停在“支持远程控制”，要拆成允许控制的状态、命令、响应、超时、失败回滚、多用户冲突和离线处理。
3. 将每个功能映射到硬件接口。
4. 定义状态、事件、条件、动作、下一状态。
5. 为每个需求定义验收方法。
6. 客户中途改需求时，做增量更新，不要静默整篇重写。

输出模板

# 产品功能需求

## 背景与范围
- 产品:
- 当前版本:
- 输入资料:

## 功能列表
| ID | 功能 | 触发条件 | 前置状态 | 硬件接口 | 正常行为 | 异常处理 | 验收方法 |
|---|---|---|---|---|---|---|---|

## 状态机
| 当前状态 | 事件 | 条件 | 动作 | 下一状态 |
|---|---|---|---|---|

## 参数与阈值
| 参数 | 默认值 | 范围 | 存储位置 | 修改方式 | 备注 |
|---|---:|---|---|---|---|

## 待确认问题
- ...

## 变更记录
| 日期 | 来源 | 变更 | 影响模块 | 是否确认 |
|---|---|---|---|---|

质量要求

• 不要把客户的模糊描述脑补成最终行为。
• 需求必须能通过板端现象、串口命令、日志、测量、UI 或测试步骤验证。
• 要覆盖离线、超时、重试、冲突、掉电、复位、异常传感器等场景。
• 区分“期望行为”和“当前实现”。
• 需求变更必须指出影响哪些模块。

嵌入式检查点

• 上电、错误、休眠、升级时哪些输出允许动作？
• 执行器动作过程中通信断开怎么办？
• 两个命令冲突怎么办？
• 哪些参数掉电保存，保存失败怎么办？
• 哪些行为必须上硬件验证，而不是只看日志？