4、需求分析与规格定义：用户需求收集、功能/非功能需求、需求文档编写与评审流程
嵌入式项目与纯软件项目最大的差异在于：需求一旦固化到硬件原理图、PCB Layout 或底层驱动架构中，返工成本将呈指数级上升。一次 GPIO 复用冲突、一个电源域遗漏、一条 I2C 地址冲突，都可能在样机调试阶段才暴露，导致改板、重做驱动、延期交付。因此，需求分析与规格定义阶段的目标，不是“写一份好看的文档”，而是通过系统化的收集、分类、建模和评审，将模糊的用户期望转化为可验证、可追踪、可实现的工程规格基线。本章将围绕用户需求收集方法、功能/非功能需求拆解、需求文档编写规范以及评审闭环四个核心模块展开，并结合一个车载传感器节点的实际案例，演示从原始需求到规格基线冻结的完整路径。
需求分析不是文档撰写任务，而是风险识别与成本控制的第一道闸门。在嵌入式项目中，需求缺陷的修复成本随着开发阶段推进呈 10 倍递增：需求阶段修复成本为 1，设计阶段为 3-6，编码阶段为 10，测试阶段为 15-40，量产阶段则可能超过 100。因此，本章所有方法都围绕“尽早暴露问题、量化验收标准、冻结变更基线”这三个核心目标展开。
4.1 用户需求收集：从模糊期望到原始需求列表
4.1.1 核心原理：嵌入式需求的特殊性
嵌入式系统的用户需求往往不是由最终用户直接提出，而是来自产品经理、系统工程师、硬件团队、算法团队、生产制造部门以及外部法规标准。需求收集的关键在于识别“真正的约束”而非“表面的功能描述”。例如，用户说“设备要能快速启动”，这只是一个模糊期望；嵌入式工程师必须追问：冷启动时间是多少？从待机唤醒呢？是否包含操作系统加载时间？供电电压跌落时是否允许复位？这些追问才能将期望转化为可测量的工程参数。
4.1.2 收集方法与操作流程
推荐采用“五步收集法”确保覆盖全面性：
- 干系人识别与访谈：列出所有影响项目成功的角色（产品、硬件、软件、测试、生产、认证），逐一进行结构化访谈，记录原始表述，不做过早过滤。
- 现场环境调研：对于工业或车载类项目，必须到实际使用场景中观察温度、振动、电磁干扰、供电波动、操作习惯等环境因素。例如，一个安装在发动机舱的传感器，环境温度范围可能达到 -40°C ~ +125°C，这直接决定元器件选型和散热设计。
- 竞品与法规分析：收集同类产品的功能清单、性能指标，同时检索相关行业标准（如 ISO 26262 功能安全、IEC 61000 EMC 标准、GB/T 28046 车载电子环境条件）。
- 技术预研与可行性初判：由嵌入式架构师对关键需求（如特定通信速率、功耗指标、存储容量）进行初步技术评估，标记高风险项。
- 输出原始需求列表：每条需求使用统一编号（如 UR-001），记录来源、提出日期、优先级（Must/Should/Could）、状态（待确认/已确认/已拒绝）。
4.1.3 案例拆解：车载环境传感器需求收集
某 Tier 1 供应商启动“车规级温湿度传感器模块”项目，用于车载空调系统。初始需求仅一句话：“做一个能测温度和湿度的模块，通过 LIN 总线发给空调控制器。”通过五步收集法，团队获得了以下关键信息：
- 环境约束：工作温度 -40°C ~ +85°C（安装在仪表板内），湿度范围 0~100% RH（无凝结），需满足 ISO 16750 振动标准。
- 性能指标：温度精度 ±0.5°C（-10°C ~ +60°C），湿度精度 ±3% RH（20%~80% RH），响应时间 < 2s（63% 阶跃）。
- 电气约束：供电 12V 车载电池（波动 6V~16V，含抛负载），静态电流 < 100μA（KL30 常电），LIN 通信波特率 19200bps。
- 生产约束：需支持在线校准（SMT 产线自动写入校准系数），PCB 尺寸 ≤ 20mm × 15mm。
- 法规要求：满足 CISPR 25 辐射发射 Class 3，ESD 接触放电 ±8kV。
这些信息直接改变了后续设计：需要选用车规级传感器（如 SHT35 的 AEC-Q100 版本），增加 TVS 管和 LC 滤波，预留校准接口，并重新评估 LIN 收发器的选型。如果没有系统化收集，这些约束将在硬件设计完成后才暴露，导致至少一轮改板。
4.2 功能需求与非功能需求：分类与量化
4.2.1 核心原理：两类需求的本质差异
功能需求（Functional Requirement, FR）描述系统“做什么”，例如“读取温度传感器数据”“通过 LIN 总线发送报文”。非功能需求（Non-Functional Requirement, NFR）描述系统“做得怎么样”，例如“温度测量精度 ±0.5°C”“系统启动时间 < 100ms”“在 85°C 环境下连续工作 1000 小时无故障”。在嵌入式项目中，NFR 往往比 FR 更决定架构走向：一个要求 10ms 控制周期的电机驱动项目，与一个允许 100ms 响应的温控项目，其 MCU 选型、RTOS 配置、中断优先级设计完全不同。
4.2.2 分类方法与量化技巧
建议使用以下分类框架，并在需求文档中为每条 NFR 明确“可测量指标 + 测试方法”：
| 需求类别 | 子类 | 示例（嵌入式场景） | 量化方式 |
|---|---|---|---|
| 功能需求 | 数据采集 | 每 10ms 读取一次 ADC 值，分辨率 12bit | 采样率、分辨率、通道数 |
| 数据处理 | 对原始数据进行滑动平均滤波，窗口长度 8 | 算法类型、窗口大小、延迟 | |
| 通信交互 | 通过 CAN 2.0B 发送 8 字节数据帧，ID=0x123 | 协议类型、帧格式、周期 | |
| 非功能需求 | 性能 | 中断响应时间 < 5μs；任务切换时间 < 10μs | 时间单位、负载条件 |
| 功耗 | 待机电流 < 10μA；运行平均电流 < 50mA | 电流值、供电电压、温度条件 | |
| 可靠性 | MTBF ≥ 100,000 小时；看门狗超时时间 1s | 统计指标、复位策略 | |
| 环境适应性 | 工作温度 -40°C ~ +85°C；湿度 95% RH 无凝结 | 温度/湿度范围、持续时间 |
4.2.3 实战场景：NFR 冲突的权衡
在一个便携式医疗设备项目中，用户要求“连续监测 24 小时”和“每 100ms 通过 BLE 发送一次数据”。这两个需求存在直接冲突：BLE 广播功耗较高，若以 100ms 间隔持续发送，电池容量需要 1000mAh 以上，导致设备体积超标。通过需求评审，团队与产品经理协商后调整为：正常模式每 500ms 发送一次，检测到异常事件时切换为 100ms 快速模式，持续 30 秒。同时增加“事件触发阈值”这一功能需求。这一权衡既满足了临床监测的实时性要求，又将平均功耗降低了 60%，电池容量缩减至 400mAh。该案例说明，NFR 的量化过程本身就是架构优化的起点。
4.3 需求文档编写：结构、粒度与可追踪性
4.3.1 核心原理：SRS 是设计、测试、验收的共同基线
需求规格说明书（Software Requirements Specification, SRS）不仅是给开发人员看的，更是硬件工程师、测试工程师、项目经理、客户代表共同签署的合同性文件。一份优秀的 SRS 应具备三个特征：唯一性（每条需求有唯一编号，无歧义）、完整性（覆盖所有功能、性能、接口、约束）、可验证性（每条需求都有明确的测试方法）。在嵌入式项目中，SRS 还应包含硬件相关约束，如 MCU 选型限制、引脚分配原则、电源域划分等，因为这些约束直接影响驱动开发。
4.3.2 文档结构与编写流程
推荐采用以下章节结构，并遵循“自顶向下、逐层细化”的编写顺序：
- 引言：项目背景、术语定义、参考文档。
- 总体描述：系统架构图、硬件拓扑、用户特征、运行环境。
- 功能需求：按模块分组（如电源管理、传感器驱动、通信协议、诊断功能），每条需求包含：编号、描述、优先级、输入/输出、异常处理。
- 非功能需求：性能、功耗、安全、EMC、环境、可靠性、可维护性。
- 接口需求：硬件接口（引脚定义、电平标准）、软件接口（API 原型、数据结构）、通信协议（帧格式、时序图）。
- 验证标准：每条需求对应的测试方法、测试工具、通过判据。
- 附录：需求追踪矩阵、风险登记表、待确认问题清单。
FR-012：作为系统，当 LIN 总线空闲超过 50ms 时，应进入低功耗模式（待机电流 < 100μA）。
验收标准：使用电流探头测量 KL30 引脚电流，在 LIN 总线空闲 50ms 后，电流值应降至 100μA 以下，且通过 LIN 唤醒帧可在 10ms 内恢复正常通信。
4.3.3 案例拆解：需求追踪矩阵（RTM）的构建
以 4.1.3 节的车载传感器为例，RTM 片段如下：
| 需求编号 | 需求描述 | 设计来源 | 测试用例 | 状态 |
|---|---|---|---|---|
| UR-003 | 温度精度 ±0.5°C（-10°C ~ +60°C） | 选用 SHT35 传感器，校准系数存储于 EEPROM | TC-TEMP-001：恒温槽 5 点校准测试 | 已确认 |
| UR-007 | 静态电流 < 100μA | KL30 供电回路增加 MOSFET 开关，MCU 进入 STOP 模式 | TC-PWR-002：万用表串联测量 24h 静态电流 | 已确认 |
| UR-012 | LIN 通信波特率 19200 ± 1% | 使用 MCU 内部时钟，校准 OSC 寄存器 | TC-LIN-001：LIN 总线分析仪抓取报文，检查同步间隔场 | 待验证 |
RTM 的价值在于：当需求变更时（例如客户要求将温度精度提升至 ±0.3°C），可以立即定位受影响的传感器选型、校准算法、测试设备，从而评估变更成本。没有 RTM 的项目，需求变更往往导致“改了代码但忘了改测试”或“换了硬件但驱动未适配”的严重脱节。
4.4 需求评审流程：角色、检查单与基线冻结
4.4.1 核心原理：评审是质量门禁而非形式流程
需求评审的目标是在投入详细设计之前，发现需求的歧义、缺失、冲突和不可实现性。嵌入式项目的评审必须包含硬件工程师和驱动工程师，因为很多需求问题只有在软硬件交界处才能暴露。例如，“支持通过 I2C 接口连接外部 EEPROM”这一需求，硬件工程师需要确认 I2C 地址是否冲突、上拉电阻是否足够；驱动工程师需要确认是否支持 100kHz/400kHz 模式、是否需要时钟延展处理。
4.4.2 评审流程与检查单
建议采用“两轮评审 + 一轮确认”的流程：
- 第一轮：内部技术评审（参与人：嵌入式架构师、硬件负责人、驱动负责人、测试负责人）。重点检查技术可行性、软硬件接口一致性、测试可验证性。
- 第二轮：干系人评审（参与人：产品经理、客户代表、生产代表）。重点检查需求是否符合市场预期、生产可制造性、法规符合性。
- 确认与基线冻结：所有评审意见关闭后，SRS 进入基线管理，后续变更必须走正式变更控制流程（CCB）。
评审检查单（节选）：
- 每条需求是否唯一编号且无歧义？是否包含“应/不应”等强制性词汇？
- 所有性能指标是否量化？是否明确了测试条件和测量仪器精度？
- 硬件接口定义是否完整（引脚号、电平、时序、上拉/下拉）？与原理图是否一致？
- 异常处理是否覆盖：传感器失效、通信超时、供电跌落、看门狗复位？
- 是否定义了启动/停止/待机/唤醒等状态及其转换条件？
- 是否包含 EMC、ESD、温度循环等环境测试要求？
- 硬件影响：需要增加一个自检电路（如传感器加热器驱动），MCU 需额外占用 1 个 GPIO 和 1 个 ADC 通道。
- 驱动影响：新增自检状态机，扩展 LIN 报文内容，增加 DTC 码表。
- 测试影响：新增 3 个测试用例（自检正常、自检失败、自检超时）。
- 教训一：不要相信“默认理解”。任何口头确认的需求都必须书面化并纳入 SRS，否则后期无法追溯。
- 教训二：NFR 必须与 FR 同步评审。功耗、时序、精度等指标应在需求阶段就与硬件选型联动，而不是等驱动写完再测试。
- 教训三：评审会议必须有决策。每次评审应输出明确的“通过/有条件通过/不通过”结论，并指定问题关闭责任人。
- 教训四：需求变更不可怕，可怕的是无流程的变更。建立 CCB 和 RTM，让每次变更的成本和影响可视化。
- 教训五：需求文档是活文档。虽然基线冻结，但应定期（如每两周）回顾待确认问题清单，避免问题积压到设计阶段。
4.4.3 案例闭环：从需求变更到基线更新
回到车载传感器项目，在 SRS 基线冻结两周后，客户提出变更：增加“传感器自诊断功能”，要求模块在每次上电时执行内部自检，并通过 LIN 总线上报诊断结果（DTC 码）。该变更涉及：
通过 RTM 定位到受影响的 5 条需求，团队评估变更成本为：硬件改版 1 次（增加 2 个阻容元件）、驱动开发增加 3 人天、测试增加 2 人天。变更控制委员会（CCB）批准后，SRS 升级至 V1.1，RTM 同步更新，所有受影响的设计文档和测试计划在 3 天内完成修订。这一过程如果没有基线管理和 RTM，将导致硬件、驱动、测试各自为政，最终在集成测试阶段出现“自检功能与 LIN 报文格式不匹配”的严重问题。
4.4.4 总结复盘：需求阶段的五个关键教训
需求分析与规格定义阶段的核心交付物不仅是 SRS 文档，更是团队对项目目标的统一认知。当硬件工程师、驱动工程师、测试工程师对“什么是完成”有完全一致的理解时，后续的开发工作才能高效推进。本章所述的方法论已在多个量产项目中验证，建议读者根据自身团队规模裁剪使用，但“量化、追踪、评审”这三个原则不可省略。