第3章 需求工程基础：需求层次与需求属性

各位同学，今天我们来聊聊需求工程里最基础、也最容易被忽视的两个概念——需求层次和需求属性。说实话，我见过太多项目翻车，根源就是这两个东西没理清楚。

先讲个我自己的经历。几年前参与一个安全气囊控制器项目，客户说“我要一个能正常点爆的气囊系统”。结果呢？我们按照系统级需求做了，交样时客户却说“不对，我要的是能在副驾放儿童座椅时自动关闭气囊”。你看，这就是需求层次没对齐的典型例子。

3.1 需求层次：从业务到软件的逐层分解

需求不是铁板一块。它是有层次的，就像剥洋葱。我个人习惯把需求分成四个层次：

层次	定义	安全气囊示例
业务需求	组织或客户的高层目标	“减少碰撞事故中的乘员伤亡率”
用户需求	用户使用系统时的具体期望	“驾驶员希望碰撞时气囊及时展开”
系统需求	系统整体应具备的能力	“碰撞发生后20ms内完成点爆”
软件需求	软件模块的具体功能	“加速度传感器采样频率≥2kHz”

3.2 业务需求：为什么做这个系统

业务需求是最高层。它回答的是“为什么”。说白了，老板为什么要投钱做这个？

我记得有一次评审，客户业务需求写的是“开发一款符合C-NCAP五星标准的安全气囊系统”。这其实已经偏了。真正的业务需求应该是“提升品牌在安全领域的市场竞争力”。你想想看，如果只盯着五星标准，那成本控制、平台复用这些事就没人管了。

3.3 用户需求：谁在用，怎么用

用户需求关注的是“谁用”和“怎么用”。这里说的用户不光是驾驶员，还包括维修工、生产线工人。

举个例子。用户需求里有一条：“维修技师能在5分钟内完成气囊模块的拆卸”。听起来简单吧？但我在项目里遇到过，设计时没人提这条，结果量产后的维修工时是15分钟。客户直接投诉。

用户需求常见的坑：

• 把用户需求写成系统需求（“气囊点爆时间≤15ms”其实是系统需求）
• 遗漏非典型用户（比如儿童、身材矮小的驾驶员）
• 忽略用户的操作环境（比如戴手套操作、光线不足）

3.4 系统需求：系统整体行为

系统需求是承上启下的关键层。它把用户需求翻译成工程师能看懂的语言。

比如用户说“希望气囊别误爆”，系统需求就要写成：“当车辆加速度未超过阈值时，气囊控制器不得输出点火信号”。

这里要注意，系统需求是黑盒视角。它只描述系统做什么，不描述内部怎么实现。我见过很多新手工程师，一上来就写“MCU检测到加速度超过阈值后调用点火函数”——这已经是软件需求了。

3.5 软件需求：具体实现细节

软件需求是最底层。它描述软件模块的具体行为。这里要精确到函数、接口、数据格式。

举个例子：

// 软件需求：加速度信号处理模块
// 输入：原始加速度数据（12位ADC值）
// 输出：滤波后的加速度值（单位：g）
// 处理逻辑：滑动窗口均值滤波，窗口大小=8
// 采样频率：2kHz
// 异常处理：连续3个采样点超出±50g范围时，置位传感器故障标志

嗯，这里要注意。软件需求不能写得太笼统。比如“处理加速度信号”这种话，等于没写。要写清楚输入输出、算法、时序、异常处理。

3.6 需求属性：功能、性能、接口、安全

说完层次，咱们聊聊属性。每个需求都有它的属性。我一般把需求属性分成四类：

属性	定义	安全气囊示例
功能需求	系统应具备的能力	“检测碰撞并点爆气囊”
性能需求	能力达到的程度	“点爆时间≤15ms”
接口需求	与外部交互的方式	“通过CAN总线发送状态帧”
安全需求	避免危害的条件	“误爆概率≤10^-9”

3.7 功能需求：做什么

功能需求是最直观的。它描述系统“做什么”。比如：

• 气囊控制器应能识别正面碰撞
• 气囊控制器应能识别侧面碰撞
• 气囊控制器应能记录碰撞事件

但功能需求容易犯的错是“过度细化”。比如“气囊控制器应能通过ADC读取加速度值”——这其实是设计细节，不是需求。功能需求只关心“能识别碰撞”，不关心怎么识别。

3.8 性能需求：做到什么程度

性能需求是功能需求的量化。没有性能指标的功能需求，基本等于没写。

举个例子：

• 功能需求：气囊应展开
• 性能需求：气囊应在碰撞发生后15ms内完全展开

你看，有了性能指标，测试才能做。我见过一个项目，功能需求写了“气囊应能保护乘员”，结果测试时发现保护效果不达标，但因为没有量化指标，双方扯皮了三个月。

3.9 接口需求：怎么连

接口需求描述系统与外部世界的交互。包括硬件接口和软件接口。

硬件接口例子：

• 气囊点火回路接口：2针连接器，额定电流2A
• 传感器接口：SPI通信，时钟频率4MHz

软件接口例子：

• CAN报文ID：0x123，周期100ms
• 诊断接口：UDS协议，支持0x22读取DID

接口需求最容易出的问题是“遗漏”。我记得有个项目，软件接口写了CAN通信，但没写波特率。结果A团队用了250kbps，B团队用了500kbps，联调时直接翻车。

3.10 安全需求：不出事

安全需求在汽车电子里是重中之重。它描述系统如何避免危害。

安全需求通常来自：

• 功能安全标准（ISO 26262）
• 法规要求（比如FMVSS 208）
• 客户特殊要求

举个例子：

• 安全需求1：当系统检测到内部故障时，应在10ms内进入安全状态
• 安全需求2：气囊误点爆的概率应低于10^-9次/小时
• 安全需求3：维修模式下，应禁用气囊点火功能

3.11 需求属性的交叉关系

实际项目中，一个需求往往同时包含多个属性。比如：

“气囊控制器应在碰撞发生后15ms内（性能）通过点火回路（接口）输出点火信号（功能），且误点爆概率≤10^-9（安全）”

你看，这一句话就包含了四个属性。写需求时不用刻意区分，但评审时要能从四个维度去检查。

3.12 小结

今天的内容其实就两个核心：

1. 需求层次：业务→用户→系统→软件，逐层细化，每层都有它的受众和用途
2. 需求属性：功能、性能、接口、安全，四个维度缺一不可

我个人建议，写需求时先画一个矩阵。横轴是层次，纵轴是属性。每个格子填上对应的需求条目。这样能确保没有遗漏。嗯，这个方法我在好几个项目里用过，效果不错。

下节课我们会讲需求获取的方法。到时候我会分享一些和客户“斗智斗勇”的经验，保证实用。

---

公众号:蓝海资料掘金营，微信deep3321