📚 课程目录第4章需求分析与规格定义

4. 需求分析与规格定义：需求文档撰写、功能规格书、验收标准制定

说实话，很多嵌入式项目翻车，不是死在代码上，而是死在需求没讲清楚。我见过太多团队，硬件画完板子、软件写到一半，客户突然说“我要的不是这个功能”。嗯，这时候改，成本就大了去了。

所以这一章，咱们聊聊怎么把需求写清楚、规格定明白、验收标准设到位。说白了，就是让所有人——客户、硬件、软件、测试——对“到底要做什么”达成共识。

4.1 需求文档：把“人话”翻译成“技术话”

需求文档是项目的起点。它的作用，是把客户嘴里那些“我要一个智能温控器，反应快点，别太贵”这种模糊描述，变成可执行的技术条目。

我的习惯：拿到原始需求后，先列一个“需求澄清清单”，把每个模糊词都问一遍。“快点”是多快？“别太贵”是多少成本预算？不问清楚，后面全是坑。

4.1.1 需求文档的核心结构

一份好的需求文档，至少包含以下部分：

项目背景与目标：为什么要做这个产品？解决什么问题？
用户角色定义：谁在用？操作员？维护工程师？终端消费者？
功能需求：系统必须做什么。每条需求独立、可验证。
非功能需求：性能、功耗、成本、尺寸、环境适应性等。
约束条件：必须用某款MCU？必须兼容某协议？
假设与依赖：我们假设什么条件成立？依赖哪些外部资源？

关键原则：每条需求必须满足“SMART”原则——具体的、可衡量的、可达成的、相关的、有时限的。比如“系统响应快”就不合格，“从按键按下到LED亮起不超过50ms”才算合格。

4.1.2 需求优先级：MoSCoW法

资源永远有限，需求必须排优先级。我个人常用MoSCoW法：

优先级	含义	举例
Must have	必须有，否则产品无法交付	温度传感器必须能读取-20°C~85°C
Should have	应该有，但可以找替代方案	应该支持OTA升级
Could have	可以有，但不影响核心功能	可以增加语音播报功能
Won't have	这次不做，留到下一版	本版本不支持蓝牙Mesh组网

你想想看，如果所有需求都是“Must have”，那项目永远做不完。优先级排序，是项目经理最重要的技能之一。

4.2 功能规格书：把需求变成设计输入

需求文档是给所有人看的。功能规格书，则是专门给开发团队看的。它把每一条需求，拆解成具体的功能模块、接口定义、行为逻辑。

我曾经在一个项目中，需求文档写了“设备异常时报警”。结果硬件工程师认为报警就是LED闪烁，软件工程师认为要蜂鸣器响，测试工程师认为要同时发短信。你看，这就是规格没写清楚的后果。

4.2.1 功能规格书的核心要素

模块划分：系统拆成几个子系统？每个子系统的职责是什么？
接口定义：模块之间怎么通信？SPI？I2C？UART？协议格式是什么？
状态机描述：系统有哪些状态？状态之间如何切换？触发条件是什么？
异常处理：通信超时怎么办？传感器失效怎么办？看门狗触发后怎么恢复？
时序要求：任务响应时间、采样周期、数据刷新率等。

避坑指南：我曾经见过一份规格书，写了“系统应具备低功耗特性”。结果硬件选了低功耗MCU，软件却每100ms轮询一次传感器，整机功耗根本下不来。低功耗不是一句口号，要写清楚：休眠电流<10µA，平均功耗<100µW，唤醒时间<5ms。

4.2.2 用状态机描述行为逻辑

嵌入式系统本质就是一个状态机。我建议在规格书中，用状态图或状态表来描述核心逻辑。下面是一个智能门锁的简化状态机：

状态：IDLE -> 等待用户输入
       AUTH -> 验证指纹/密码
       OPEN -> 开锁动作
       ALARM -> 连续5次验证失败

状态转换：
  IDLE: 收到按键中断 -> AUTH
  AUTH: 验证通过 -> OPEN
  AUTH: 验证失败 < 5次 -> IDLE
  AUTH: 验证失败 >= 5次 -> ALARM
  OPEN: 开锁完成 -> IDLE
  ALARM: 管理员复位 -> IDLE

状态机写清楚，代码实现的时候基本就是照着翻译，不容易漏逻辑。

4.3 验收标准：怎么才算“做完了”？

验收标准是项目交付的“裁判员”。没有验收标准，开发说做完了，测试说没通过，客户说不满意——三方扯皮，项目烂尾。

验收标准必须和需求文档一一对应。每条需求，都要有一条或几条验收用例来证明它被实现了。

4.3.1 验收标准的分类

类型	说明	示例
功能验收	每个功能是否按规格工作	按下按键1，LED以1Hz频率闪烁
性能验收	是否达到性能指标	从触发到响应 < 100ms
边界验收	极端条件下是否稳定	温度85°C时仍能正常采集数据
异常验收	异常场景下行为是否正确	通信中断后，本地数据不丢失
可靠性验收	长时间运行是否稳定	连续运行72小时无死机

我的建议：验收标准最好在需求阶段就写出来，而不是等到开发完了再补。因为写验收标准的过程，本身就是在检查需求是否清晰。如果你写不出验收用例，说明这条需求还不够具体。

4.4 需求变更管理：唯一不变的就是变化

项目进行到一半，客户说“加个功能”，老板说“换个方案”，这种事太常见了。需求变更不可怕，可怕的是没有流程。

我个人的做法是：

变更申请：必须书面提出，口头说的不算。
影响评估：改这个需求，对进度、成本、质量有什么影响？
变更评审：项目经理、技术负责人、客户一起决策。
变更实施：更新需求文档、规格书、验收标准、开发计划。
变更追溯：所有变更记录存档，方便后期回溯。

我曾经踩过的坑：有个项目，客户在开发中期口头说“把屏幕从2.4寸换成3.5寸吧”。我心想不就是换个屏嘛，结果硬件要改PCB布局，软件要重写LCD驱动，结构要重新开模，整个项目延期了两个月。从那以后，任何变更都必须走流程，哪怕只是换一颗电阻。

4.5 本章知识体系总览

下面这张图，把需求分析与规格定义的核心流程串起来了。你可以把它当作本章的“思维导图”。

4.6 本章小结

需求分析与规格定义，是嵌入式项目最容易被忽视、也最容易出问题的阶段。很多人觉得“写文档浪费时间”，急着开工。但以我的经验，前期花1周把需求理清楚，后期能省下1个月的返工时间。

记住三件事：

需求文档：把“人话”翻译成“技术话”，每条需求SMART化。
功能规格书：把需求拆成模块、接口、状态机，让开发有据可依。
验收标准：在开工前就想好“怎么才算做完”，避免扯皮。