4. 嵌入式项目生命周期

说实话，我见过太多项目栽在需求阶段。不是技术不行，是需求本身就没写明白。你想想看，一个连目标都描述不清的项目，怎么可能做得好？

需求规格说明书（SRS），就是那个把所有人拉到同一张桌子前的文档。它不光是给开发看的，测试、项目经理、客户，甚至法务都可能翻它。所以，写SRS不是写作文，是立契约。

4.1 高质量SRS的骨架：别让它散架

我个人的习惯是，先搭框架，再填肉。一个标准的嵌入式SRS，至少得包含这几块骨头：

• 引言与范围：这产品是干啥的？给谁用？边界在哪？别上来就写功能，先画个圈。
• 总体描述：产品视角、用户特征、假设与依赖。我记得有一次，客户没提环境温度，结果产品在高温车间直接罢工。嗯，这就是假设没写清楚的代价。
• 具体需求：功能需求、接口需求、性能需求、安全需求。这是正文，也是最容易吵架的地方。
• 非功能需求：功耗、响应时间、可靠性、可维护性。嵌入式里，非功能需求往往比功能需求更致命。
• 附录与术语：把那些缩写和专有名词列清楚，省得后期扯皮。

4.2 需求优先级划分：MoSCoW方法，别什么都想要

项目资源永远是有限的。客户说“我全都要”，但时间、成本、人力摆在那。这时候，MoSCoW方法就是你的砍刀。

MoSCoW把需求分成四类：

分类	含义	嵌入式场景举例
M - Must Have	必须有，否则系统无法交付	看门狗定时器、基本通信协议、安全关机
S - Should Have	应该有，但可以找变通方案	OTA升级、日志记录深度、高级诊断
C - Could Have	可以有，但锦上添花	炫酷的LED动画、语音提示、远程配置界面
W - Won't Have	这次不做，但可能以后做	机器学习预测、云端大数据分析

怎么用？我建议你拉上客户、产品经理、开发负责人，一起过一遍需求清单。每个人手里三张票，投给“Must Have”。如果超过半数人觉得某需求是M，那就放进去。否则，往下放。

4.3 需求验证与确认：别等写代码才发现错了

需求写完了，不代表就对了。验证和确认是两回事：

• 验证（Verification）：我们是不是正确地写出了需求？——检查语法、完整性、一致性。
• 确认（Validation）：我们写的是不是客户真正想要的？——跟客户过一遍，看他们点头还是摇头。

我常用的方法有几种：

1. 同行评审：拉上3-5个工程师，逐条读SRS。别找太熟的人，容易放水。我曾经让一个刚入职的实习生评审，他问了个问题：“这个中断优先级写反了吧？”好家伙，救了一条命。
2. 原型法：嵌入式里，做个简单的UI原型或者状态机模拟。让客户点一点，比看文档管用得多。
3. 测试用例前置：在写代码之前，先写测试用例。如果测试用例写不出来，说明需求不清晰。这是我最喜欢的一招。
4. 需求跟踪矩阵（RTM）：把每个需求编号，跟设计、代码、测试用例一一对应。谁改了需求，一目了然。

4.4 知识体系：一张图看懂需求管理

下面这张图，是我自己总结的需求管理流程。从原始想法到最终验收，每一步都绕不开。

你看，这个流程不是线性的。验证不通过，就得回到分析阶段重新梳理。我见过太多项目，验证阶段发现需求错了，但为了赶进度硬着头皮往下做。结果呢？返工成本是原来的10倍不止。

4.5 实战清单：写SRS前问自己几个问题

每次动笔写SRS之前，我都会过一遍这个清单。你也试试：

• 这条需求，测试能写出明确的通过/不通过标准吗？
• 如果砍掉这条需求，系统还能正常运行吗？
• 客户看到这条需求，会不会说“这不是我想要的”？
• 这条需求跟其他需求有冲突吗？比如一个要低功耗，一个要高算力。
• 有没有遗漏边界情况？比如掉电、通信中断、非法输入。