3、需求分析实战：如何从产品需求中提取软件需求？编写SRS（软件需求规格说明书）的模板

好，咱们进入第三章。前两章聊了架构文档的定位和顶层设计，今天来点实际的——怎么从一堆产品需求里，把软件需求给“拎”出来。

说实话，我见过太多团队，产品经理扔过来一份几十页的Word，开发直接上手写代码。结果呢？做到一半发现理解偏差，返工。这种事，我踩过的坑至少有三四次。后来我养成一个习惯：不管项目多急，必须先写一份SRS（软件需求规格说明书）。

为什么？因为产品需求是“做什么”，软件需求是“怎么做”。这两者之间，隔着一道鸿沟。

3.1 产品需求 vs 软件需求：到底差在哪？

先看个例子。产品经理说：“设备要能在10秒内完成自检。”这是产品需求。软件需求呢？你得拆成：

• 上电后MCU初始化GPIO、ADC、UART，耗时不超过2秒
• 依次检测各传感器通信是否正常，每路检测时间不超过1秒
• 汇总状态并上报，总耗时不超过10秒

你看，产品需求是“目标”，软件需求是“路径”。

说白了，产品需求是“甲方的话”，软件需求是“工程师的图纸”。

3.2 提取软件需求的四步法

我自己的习惯是，拿到产品需求后，按四步走：

1. 拆解功能点——把每一条产品需求拆成原子功能
2. 识别非功能约束——性能、功耗、安全、实时性
3. 定义接口与交互——输入输出、通信协议、数据格式
4. 编写可测试的验收标准——每条需求都能被验证

举个例子。产品需求：“设备支持蓝牙配网。”拆解后：

• 功能点1：蓝牙广播设备信息
• 功能点2：接收手机端WiFi SSID/密码
• 功能点3：连接WiFi并返回状态
• 非功能约束：配网过程不超过60秒
• 接口定义：蓝牙GATT服务UUID、特征值格式
• 验收标准：手机App发送正确SSID后，设备3秒内返回连接成功

3.3 SRS模板：我用了十年的结构

下面这个模板，是我从第一个嵌入式项目就开始用的，迭代了不下二十次。你直接拿去用，基本不会有大问题。

# 软件需求规格说明书（SRS）

## 1. 引言
  1.1 目的
  1.2 范围
  1.3 定义与缩写
  1.4 参考资料

## 2. 总体描述
  2.1 产品视角
  2.2 用户特征
  2.3 假设与依赖

## 3. 功能需求
  3.1 模块A：传感器采集
    3.1.1 功能描述
    3.1.2 输入/输出
    3.1.3 处理逻辑
    3.1.4 异常处理
  3.2 模块B：通信管理
    ...（同上结构）

## 4. 非功能需求
  4.1 性能需求
  4.2 功耗需求
  4.3 安全需求
  4.4 可靠性需求
  4.5 可维护性需求

## 5. 接口需求
  5.1 外部接口（硬件引脚、通信协议）
  5.2 内部接口（模块间API、消息队列）

## 6. 验收标准
  6.1 功能验收用例
  6.2 性能验收用例

注意，第3章“功能需求”是核心。每个模块都要写清楚：输入是什么、输出是什么、处理逻辑是什么、异常了怎么办。

3.4 实战案例：从产品需求到SRS片段

假设产品需求是：“设备支持远程固件升级，升级过程中不能断电。”我们提取软件需求：

写成SRS片段：

### 3.3 固件升级模块

**功能描述**：通过蓝牙接收固件包，完成固件更新。

**输入**：
- 蓝牙GATT特征值：0xFFE1
- 数据格式：包头(2B) + 包序号(2B) + 数据(256B) + CRC16(2B)

**处理逻辑**：
1. 接收数据包，校验CRC
2. 写入备用Flash分区
3. 全部接收完成后，校验整体固件哈希
4. 校验通过，切换启动分区并复位

**异常处理**：
- CRC校验失败：丢弃该包，请求重传，最多重试3次
- 电压低于3.0V：暂停写入，保存当前包序号，等待电压恢复
- 整体哈希校验失败：不切换分区，保持旧固件运行

你看，这样写出来，开发人员拿到手就知道怎么干，测试人员也知道怎么测。

3.5 需求提取的核心流程

下面这张图，是我每次做需求分析时都会在脑子里过一遍的流程。画出来更清楚。

这个流程，说白了就是“翻译”——把产品经理的语言，翻译成工程师的语言。翻译得好不好，直接决定项目能不能顺利交付。

3.6 几个容易踩的坑

• 需求描述太模糊——比如“响应要快”，改成“从触发到输出不超过50ms”
• 忽略边界条件——比如“数据正常处理”，但没写“数据为空时怎么办”
• 遗漏非功能需求——比如只写功能，没写功耗、内存上限、看门狗超时时间
• 验收标准不可量化——比如“系统稳定”，改成“连续运行72小时无重启”

嗯，今天就到这儿。记住一句话：需求分析做得越细，后面写代码越顺。别急着动手，先把SRS写好。