tsaiguohua 产品需求整理
写 MCU 代码之前，先把需求变成可确认、可验证的产品行为。很多反复改代码的问题，本质是需求没拆清楚。
输入
- 客户聊天记录、截图、语音转文字、旧说明书、原型说明。
- 硬件接口速查表。
- 产品类型和用户场景。
- 老项目现有行为。
工作流
- 区分事实、需求、假设、待确认问题。
- 把模糊描述改成可观察行为。
例如不要停在“支持远程控制”，要拆成允许控制的状态、命令、响应、超时、失败回滚、多用户冲突和离线处理。 - 将每个功能映射到硬件接口。
- 定义状态、事件、条件、动作、下一状态。
- 为每个需求定义验收方法。
- 客户中途改需求时，做增量更新，不要静默整篇重写。
输出模板
# 产品功能需求
## 背景与范围
- 产品:
- 当前版本:
- 输入资料:
## 功能列表
| ID | 功能 | 触发条件 | 前置状态 | 硬件接口 | 正常行为 | 异常处理 | 验收方法 |
|---|---|---|---|---|---|---|---|
## 状态机
| 当前状态 | 事件 | 条件 | 动作 | 下一状态 |
|---|---|---|---|---|
## 参数与阈值
| 参数 | 默认值 | 范围 | 存储位置 | 修改方式 | 备注 |
|---|---:|---|---|---|---|
## 待确认问题
- ...
## 变更记录
| 日期 | 来源 | 变更 | 影响模块 | 是否确认 |
|---|---|---|---|---|
质量要求
- 不要把客户的模糊描述脑补成最终行为。
- 需求必须能通过板端现象、串口命令、日志、测量、UI 或测试步骤验证。
- 要覆盖离线、超时、重试、冲突、掉电、复位、异常传感器等场景。
- 区分“期望行为”和“当前实现”。
- 需求变更必须指出影响哪些模块。
嵌入式检查点
- 上电、错误、休眠、升级时哪些输出允许动作？
- 执行器动作过程中通信断开怎么办？
- 两个命令冲突怎么办？
- 哪些参数掉电保存，保存失败怎么办？
- 哪些行为必须上硬件验证，而不是只看日志？