需求分析与功能拆解：把模糊想法变成能动手的硬件
说实话，我见过太多团队拿着一个「我想做个智能家居中控」的想法就开始画板子、写代码。结果呢？三个月后做出来的东西，用户说「这不是我要的」。问题出在哪？不是技术不行，是需求压根没理清楚。
这一章，我们就聊聊怎么把老板嘴里那句「做个能联网的传感器盒子」变成一张清晰的功能清单、一个可执行的开发计划。
从模糊到具体：需求分析的三个步骤
我自己的习惯是，拿到一个需求先做三件事：追问场景、限定边界、量化指标。你想想看，如果客户说「我要一个低功耗的温湿度采集器」，那「低功耗」是多低？一年换一次电池还是三天充一次电？这差别大了去了。
需求转化清单（我每次必问的问题）
- 谁在用？—— 是工厂工人还是家庭主妇？操作习惯完全不同。
- 在什么环境下用？—— 室内 25°C 还是户外 -20°C 到 60°C？
- 数据怎么用？—— 本地显示就行，还是要上云做分析？
- 供电方式？—— 电池、USB、还是 PoE？
- 响应速度？—— 实时控制还是每小时上报一次？
举个例子。之前有个客户说「我要做一个智能花盆，能自动浇水」。听起来很简单对吧？但当我追问「花盆放在阳台还是室内？」「用户希望多久加一次水？」「如果传感器坏了怎么办？」的时候，客户沉默了。最后我们定义出来的需求是：基于土壤湿度阈值触发水泵，每次浇水 5 秒，缺水时通过 LED 闪烁提醒用户手动加水。你看，这才是能动手的需求。
功能模块划分原则：高内聚、低耦合
做硬件和做软件一样，模块划分不好，后期调试就是灾难。我记得有一次做一个多传感器采集终端，因为把 WiFi 模块和传感器驱动写在了同一个文件里，结果换了一个 WiFi 芯片，整个代码都得重写。嗯，从那以后我坚持一个原则：一个模块只做一件事，模块之间通过明确的接口通信。
对于嵌入式系统，我通常把功能拆成这几层：
| 层级 | 包含内容 | 典型接口 |
|---|---|---|
| 感知层 | 传感器、ADC、信号调理 | I2C / SPI / 模拟电压 |
| 处理层 | MCU、算法、状态机 | UART / GPIO 中断 |
| 通信层 | WiFi / BLE / LoRa / 以太网 | AT 指令 / 协议栈 API |
| 执行层 | 电机、继电器、显示屏 | PWM / GPIO 高低电平 |
| 电源层 | 电池管理、LDO、DC-DC | 电压 / 电流检测 |
划分的时候记住一句话：能独立测试的模块才是好模块。如果你写了一个函数，必须接上所有外设才能验证它对不对，那这个模块的划分就有问题。
MVP 定义：先做 20% 的功能，解决 80% 的问题
很多硬件工程师有个毛病——总想把所有功能都做上去。「万一用户需要呢？」「先留着吧，反正 PCB 上多放几个电阻也不费事。」结果呢？项目周期拖长，bug 变多，最后连核心功能都没做好。
我个人对 MVP 的理解是：用最快的速度、最低的成本，验证产品最核心的价值假设。对于硬件产品，MVP 不是「功能少一点」，而是「只做那些没有就无法验证产品是否成立的功能」。
硬件 MVP 的筛选标准
- 核心功能：没有这个功能，产品就是个摆设。比如智能锁的「开锁」功能。
- 验证功能：用来回答「用户真的需要这个吗？」比如智能锁的「远程授权临时密码」。
- 锦上添花：可以放到 V2.0 的功能。比如智能锁的「语音欢迎词」。
MVP 只做前两类，而且第二类要尽量简化。
我曾经帮一个团队做便携式空气质量检测仪。他们原本的计划是：检测 PM2.5、甲醛、TVOC、温湿度，还要有 WiFi 上传、OLED 显示、语音播报。我让他们砍到只剩 PM2.5 检测 + 三色 LED 指示 + 按键切换模式。两周就出了原型，拿去给目标用户试用。结果发现用户最关心的根本不是精度，而是「能不能告诉我现在要不要开窗」。你看，MVP 帮你省了多少弯路。
功能拆解实战：以「智能温控风扇」为例
我们拿一个具体的例子走一遍流程。假设需求是：「做一个能根据温度自动调速的风扇」。
第一步：需求转化
- 温度范围：0~50°C，精度 ±1°C
- 调速方式：PWM 控制无刷直流风扇
- 显示：当前温度和转速档位（3 档 LED 指示）
- 供电：5V USB 供电
- 用户交互：一个旋钮设定目标温度
第二步：模块划分
- 温度采集模块：DS18B20 单总线传感器
- 控制模块：STM32F103 读取温度、执行 PID 算法
- 执行模块：MOSFET 驱动 + 12V 风扇（通过升压模块供电）
- 显示模块：3 个 LED + 1 个 RGB LED（指示状态）
- 输入模块：电位器 + ADC 读取目标温度
- 电源模块：5V 输入 → 3.3V 给 MCU，5V 给传感器，升压到 12V 给风扇
第三步：MVP 定义
MVP 版本只做：温度读取 + 固定阈值比较 + 三档风速切换。没有 PID，没有 OLED 显示，没有手机 App。原型用面包板搭建，代码不到 100 行。
// MVP 版本核心逻辑（伪代码）
while(1) {
temp = read_ds18b20();
if(temp < 25) set_fan_speed(OFF);
else if(temp < 30) set_fan_speed(LOW);
else if(temp < 35) set_fan_speed(MED);
else set_fan_speed(HIGH);
delay(1000); // 每秒更新一次
}这个原型做出来之后，我们让用户试用了三天。反馈是：「能不能让风速平滑变化，不要突然从低速跳到高速？」 好，这就是 V1.1 要加 PID 的原因。如果没有 MVP，你可能直接花两周写 PID 算法，结果发现用户根本不在乎平滑度，他们更在意噪音。
知识结构图：需求到功能的完整链路
下面这张图总结了从模糊需求到具体功能的拆解流程，以及 MVP 的筛选逻辑。你可以把它贴在工位旁边，每次开始新项目前扫一眼。
避坑指南：我踩过的几个坑
我曾经犯过的错，希望你别重蹈覆辙
- 需求没写下来就开工—— 口头沟通的「低功耗」和文档里的「休眠电流 < 10μA」是两码事。白纸黑字写下来，双方签字确认。
- 模块划分太细—— 每个传感器一个独立模块？没必要。把功能相近的硬件放在一起，比如所有 I2C 设备挂同一条总线，减少 PCB 走线和代码复杂度。
- MVP 砍得太狠—— 有一次我把显示功能都砍了，结果原型做出来用户根本不知道设备在干什么。MVP 可以简化，但不能让用户无法理解设备状态。
- 忽略电源模块—— 很多人把电源当成「最后再搞」的事情。结果传感器供电不稳，数据跳来跳去。电源模块应该和核心功能一起进入 MVP。
好了，这一章的内容就这些。记住：好的硬件产品不是功能堆出来的，是需求理出来的。下次拿到一个模糊需求，先别急着开 Altium Designer 或 Keil，拿张纸，按上面的流程走一遍。你会发现，后面的事情顺多了。