2. 需求分析与规格定义：从用户需求到技术规格书的转化

做嵌入式系统这么多年，我见过太多项目死在需求阶段。有的团队拿到一句话需求就开始画原理图，有的把用户说的每句话都当圣旨。结果呢？要么做出来的东西没人用，要么开发到一半发现根本实现不了。

说白了，需求分析就是把「客户想要什么」翻译成「工程师能做什么」。这个翻译过程，才是真正的技术活。

2.1 用户需求的三个层次

我习惯把用户需求分成三层，这样不容易漏东西：

举个例子。有个客户跟我说要做「智能门锁」，这是业务需求。我追问下去，才知道他们真正想要的是「员工用手机蓝牙开门，管理员能远程授权」。你看，这才是用户需求。再往下拆，才是「蓝牙连接距离≤10米」「授权响应时间<2秒」这些功能需求。

2.2 功能需求定义：画清楚边界

功能需求定义，核心是回答一个问题：系统到底做什么，不做什么？

我一般用用例图（Use Case）来梳理。但这里有个坑——很多人画用例图只画正常流程。我曾经在一个项目中，客户说「设备要能OTA升级」，我们只设计了正常升级流程。结果量产之后发现，升级过程中断电怎么办？升级包校验失败怎么办？这些异常场景全没考虑。

所以我现在做功能需求，一定会列一个功能清单表：

优先级我习惯用P0/P1/P2来标。P0是必须实现的，没有就不能交付。P1是重要但可以延期。P2是锦上添花。这样排下来，就算项目砍时间，也知道先砍什么。

2.3 非功能需求定义：决定系统成败的隐形指标

功能需求决定系统能不能用，非功能需求决定系统好不好用。很多项目功能都实现了，但客户就是不验收，问题往往出在非功能需求上。

嵌入式系统常见的非功能需求包括：

• 性能：响应时间、吞吐量、实时性
• 可靠性：MTBF（平均无故障时间）、可用性（99.9%还是99.99%）
• 功耗：待机电流、工作电流、电池续航
• 安全性：数据加密、访问控制、防篡改
• 可维护性：远程升级、日志诊断、故障恢复
• 环境适应性：温度范围、防护等级（IP等级）、EMC

2.4 从需求到技术规格书的转化流程

技术规格书（Technical Specification）是给工程师看的。它要把用户语言翻译成技术语言。我一般按这个流程走：

1. 需求分类：把收集到的需求按功能/非功能分类，去掉重复和矛盾
2. 量化指标：把「响应要快」变成「从触发到输出≤100ms」
3. 确定接口：定义输入输出信号、通信协议、电气特性
4. 约束条件：成本上限、尺寸限制、功耗预算、认证要求
5. 验收标准：每个需求都要有可测试的通过条件

下面这张图是我做需求转化时常用的框架：

2.5 技术规格书的模板结构

一份好的技术规格书，应该让任何一个工程师拿到手就能开始干活。我常用的模板包含这些章节：

1. 修订记录：版本号、修改人、修改日期、修改内容
2. 概述：产品背景、适用范围、术语定义
3. 系统架构：硬件框图、软件分层、模块划分
4. 功能规格：每个功能的详细描述、输入输出、时序要求
5. 非功能规格：性能指标、可靠性、功耗、环境要求
6. 接口定义：电气接口、通信协议、机械尺寸
7. 约束条件：成本、认证、法规要求
8. 验收标准：测试方法、通过条件、测试环境

2.6 避坑指南：需求阶段常见的五个坑

做了十几年嵌入式，我总结了几条血泪教训：

• 坑一：需求太模糊。「系统要稳定」——什么叫稳定？MTBF多少？可用性几个9？不量化就是空话。
• 坑二：忽略异常场景。只考虑正常流程，不考虑断网、断电、传感器故障。我曾经有个项目，客户说「设备要能联网」，我们只设计了正常联网流程。结果现场网络不稳定，设备反复重连把服务器打挂了。
• 坑三：非功能需求后置。等硬件选型完了才说功耗不够、尺寸放不下。非功能需求一定要在规格书阶段就定死。
• 坑四：需求变更不控制。客户今天说加个功能，明天说改个参数。没有变更流程，项目永远做不完。
• 坑五：验收标准不明确。「差不多就行」是最坑的。每个需求都要有明确的通过条件，能测、能验证。

嗯，需求分析这个阶段，花的时间越多，后面开发越顺。我见过最极端的项目，需求分析做了两个月，开发只用了三周。听起来不合理？但人家一次通过验收，没有返工。你想想看，是花两个月想清楚再干划算，还是边干边改划算？