2. 嵌入式系统基础
做嵌入式项目这么多年，我越来越觉得需求分析是整个项目的“地基”。地基没打好，后面架构设计得再漂亮，也经不起推敲。今天咱们就聊聊需求分析最基础的三件事：需求怎么分类、怎么获取、怎么排优先级。
一、需求分类：功能、非功能与约束
很多刚入行的工程师拿到需求文档，第一反应就是“这个功能怎么做”。但实际项目中，真正让团队翻车的往往不是功能本身，而是那些藏在角落里的非功能需求和约束条件。
我个人习惯把需求分成三类，这样梳理起来特别清晰：
| 需求类型 | 定义 | 嵌入式项目典型例子 |
|---|---|---|
| 功能需求 | 系统“做什么” | 采集传感器数据、控制电机启停、上报状态到云端 |
| 非功能需求 | 系统“做得怎么样” | 响应时间≤50ms、功耗<100mW、MTBF≥50000小时 |
| 约束条件 | 项目“必须遵守什么” | 使用STM32F4系列、成本≤80元、通过CE认证 |
关键认知：功能需求决定系统能不能用，非功能需求决定系统好不好用，约束条件决定项目能不能落地。三者缺一不可。
我在项目中遇到过最典型的翻车案例：一个智能门锁项目，功能需求全部实现——指纹识别、密码开锁、远程授权，样样都跑通了。结果量产前发现，电池续航只有3天，因为没人提过“待机功耗≤50μA”这个非功能需求。嗯，后来整个团队加班三个月改硬件方案，教训深刻。
1.1 功能需求——系统的“骨架”
功能需求描述的是系统与外界交互的行为。说白了，就是用户按下一个按钮，系统应该发生什么。在嵌入式领域，功能需求通常可以拆解为：
- 输入处理：按键扫描、传感器读取、通信数据接收
- 逻辑运算：状态判断、算法计算、协议解析
- 输出控制：LED显示、电机驱动、数据发送
- 通信交互：UART/SPI/I2C/CAN等总线数据交换
我的习惯：写功能需求时，我会用“用户故事”的格式来写。比如“作为用户，我希望按下解锁键后，门锁在1秒内打开”。这样写出来的需求，测试人员一看就知道怎么验证。
1.2 非功能需求——系统的“血肉”
非功能需求往往比功能需求更难定义，也更容易被忽略。你想想看，一个数据采集器，功能上能采数据就够了，但如果采样率达不到要求、数据丢包率太高、或者环境温度一高就死机，那这个产品就是废的。
嵌入式系统常见的非功能需求包括：
- 性能：响应时间、吞吐量、实时性
- 可靠性：MTBF、故障恢复时间、数据完整性
- 功耗：工作功耗、待机功耗、电池寿命
- 安全性：数据加密、防篡改、安全启动
- 可维护性：OTA升级能力、日志记录、调试接口
避坑指南：我曾经接手过一个医疗设备项目，需求文档里只写了“系统需要稳定运行”。结果验收时客户要求连续运行30天不能重启。我们用的RTOS任务栈深度没算够，跑到第7天就崩了。所以非功能需求一定要量化，别用“稳定”“快速”“可靠”这种模糊词。
1.3 约束条件——项目的“镣铐”
约束条件不是系统本身的行为，而是项目必须遵守的外部限制。这些限制往往来自客户、法规、成本或技术平台。常见的约束条件有：
- 硬件约束：指定MCU型号、内存上限、PCB尺寸
- 成本约束：BOM成本上限、开发预算
- 时间约束：交付日期、里程碑节点
- 法规约束：FCC/CE认证、RoHS要求、医疗标准
- 接口约束：必须兼容现有系统的通信协议
约束条件一旦确定，基本就是“死命令”。我在做工业控制器项目时，客户要求必须用某款国产MCU，理由是供应链安全。虽然那款芯片性能一般，但这就是约束，架构设计必须围绕它来展开。
二、需求获取方法：访谈、问卷与观察
需求不会自己从天上掉下来。怎么把客户脑子里的想法、现场的实际需求、甚至他们自己都没意识到的需求挖出来，这是门手艺活。
我常用的三种方法，各有各的适用场景：
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 访谈 | 关键干系人、复杂需求 | 深度挖掘、可追问 | 耗时、样本少 |
| 问卷 | 大量用户、统计需求 | 覆盖面广、效率高 | 无法深入、回收率低 |
| 观察 | 现有流程、隐性需求 | 发现真实行为 | 可能干扰操作 |
2.1 访谈——聊出来的需求
访谈是我最推荐的方法，尤其是面对关键客户或领域专家时。一对一的对话能让你捕捉到很多文档里写不出来的细节。
做访谈时我一般会准备一个半结构化的提纲：
- 开场：了解对方角色、使用场景、当前痛点
- 核心：针对具体功能提问，“如果这个功能没有，你会怎么处理？”
- 深挖：追问“为什么”，找到真正的动机
- 收尾：确认优先级，“这三个功能如果只能选两个，你放弃哪个？”
小技巧：访谈时别光听对方说，多观察他们的肢体语言和语气。有一次客户嘴上说“这个功能无所谓”，但说到竞品有这个功能时明显语气变了。我追问下去才发现，这其实是他们的核心需求。
2.2 问卷——广撒网，捞大鱼
当用户群体很大，比如消费类产品，访谈就不现实了。这时候问卷是高效的选择。但问卷设计得好不好，直接影响结果质量。
我总结了几条问卷设计的原则：
- 问题要具体：别问“你希望系统快一点吗？”，要问“你能接受的最长响应时间是多少秒？”
- 选项要互斥：每个选项之间不能有重叠
- 留出开放题：最后加一题“还有什么想补充的？”
- 控制长度：超过20题，回收率会断崖式下降
2.3 观察——看见真实的需求
这个方法最容易被忽略，但往往最有价值。用户说的和实际做的，经常是两回事。
我记得有一次做工厂设备监控项目，客户说“操作很简单，看一眼就会”。结果我去现场观察了一整天，发现工人操作时经常需要翻看纸质手册，因为界面上的图标他们看不懂。这就是隐性需求——需要更直观的人机交互设计。
观察法特别适合：
- 发现现有流程中的低效环节
- 了解用户真实操作习惯
- 识别安全风险和易错点
- 验证访谈和问卷中获取的信息
三、需求优先级：MoSCoW法
需求收集完了，问题也来了——资源有限，时间紧迫，不可能所有需求都做。怎么排优先级？我强烈推荐MoSCoW法，简单实用，团队沟通成本低。
MoSCoW把需求分为四类：
| 分类 | 含义 | 占比建议 | 例子 |
|---|---|---|---|
| M - Must have | 必须有，否则项目失败 | 约30% | 系统能正常启动、核心功能可用 |
| S - Should have | 应该有，但可以找替代方案 | 约30% | 日志记录、高级配置功能 |
| C - Could have | 可以有，锦上添花 | 约20% | 炫酷的动画效果、额外主题 |
| W - Won't have | 这次不做，以后再说 | 约20% | 与本次版本无关的功能 |
核心原则：Must have是项目的底线，少一个都不能交付。Should have是重要但不紧急，可以延期。Could have是锦上添花，有时间再做。Won't have是明确放弃，避免团队分心。
使用MoSCoW法时，我建议团队一起做排序，而不是项目经理一个人拍脑袋。因为不同角色对“必须”的理解可能完全不同——开发觉得“必须”的，市场可能觉得“可有可无”。
我曾经在一个项目中，销售坚持要把某个功能列为Must have，说客户特别看重。结果我们花了两周做完，客户验收时根本没提这个功能。后来复盘发现，销售只是听竞品提过这个功能，就以为客户也需要。所以，MoSCoW的决策依据一定要来自真实的需求调研，而不是猜测。
四、知识体系总览
下面这张图把本章的核心内容串起来了，方便你对照理解：
这张图把需求分析的三个核心维度串在了一起。你从中心出发，向左看需求分类，向右看优先级排序，中间是获取方法。实际项目中，这三个步骤是迭代进行的——你可能会在访谈中发现新的约束条件，或者在排优先级时发现某个需求需要重新调研。
我的建议：刚开始做需求分析时，别追求一步到位。先画一个粗框架，然后不断细化。就像画电路原理图一样，先搭架构，再填细节。
好了，需求分析的基础就聊到这儿。记住一句话：需求分析做得越扎实，后面架构设计就越顺畅。别急着写代码，先把需求搞清楚，这是我在无数项目中用血泪换来的经验。