4. 安全气囊系统需求分析流程：需求获取、分析、规格化、验证与确认

好，咱们进入正题。安全气囊系统的需求分析，说白了就是搞清楚「到底要造个什么东西」。

我见过不少项目，开发到一半才发现需求没对齐，结果返工成本高得吓人。所以这个流程，咱们得走扎实了。

4.1 需求获取：别坐在办公室里猜

需求获取不是闭门造车。你得走出去，跟各方角色聊。

我个人习惯，先列一个「利益相关者清单」：

• 终端用户：驾驶员、乘客。他们关心的是「别误爆」「别漏爆」。
• 主机厂（OEM）：关心成本、平台复用、法规合规。
• 法规机构：比如国标、ECE、FMVSS。这些是硬杠杠。
• 生产部门：关心可制造性、测试便利性。
• 售后/质量：关心故障诊断、可维修性。

获取手段上，我常用这几种：

1. 文档分析：啃法规、啃竞品拆解报告。
2. 用户访谈：找几个老司机聊聊，听听他们对气囊的「吐槽」。
3. 场景头脑风暴：拉上系统、硬件、软件、测试的人，一起推演各种碰撞场景。
4. 原型演示：用快速原型工具做个简单的HMI界面，让用户点一点，反馈更直观。

嗯，这里要注意：获取到的需求，别急着写进文档。先记下来，后面还要过滤。

4.2 需求分析：把「想要」变成「需要」

需求分析阶段，核心是「去伪存真」。

我曾经遇到一个需求：「气囊展开声音要小」。听起来合理吧？但仔细一分析，火药爆炸的声音怎么可能小？

所以，分析的第一步是判断可行性。

我一般把需求分成三类：

类型	定义	举例
功能需求	系统「做什么」	正面碰撞时，主驾气囊必须展开
性能需求	系统「做到什么程度」	展开时间 ≤ 30ms（从碰撞到完全充气）
约束条件	系统「不能做什么」或「必须符合什么」	工作温度范围：-40℃ ~ 85℃

分析时，我常用因果图和决策表。举个例子：

// 伪代码：气囊点火决策逻辑
if (碰撞强度 > 阈值) {
    if (乘员位置传感器检测到有人) {
        if (安全带未系) {
            点火（强充气）；
        } else {
            点火（弱充气）；
        }
    } else {
        不点火；
    }
} else {
    不点火；
}

你看，一个简单的决策表，就能把「什么情况下点火」理得清清楚楚。我在项目中，经常用这种表格跟软件工程师对齐，避免歧义。

4.3 需求规格化：写清楚，别让人猜

需求规格化，就是把分析后的结果，写成可验证的文档。

我见过最糟糕的需求是：「系统应可靠工作」。什么叫可靠？没法验证。

好的需求规格，应该遵循SMART原则：

• Specific（具体的）
• Measurable（可测量的）
• Achievable（可实现的）
• Relevant（相关的）
• Testable（可测试的）

举个例子：

❌ 差的需求：「气囊在碰撞时展开。」

✅ 好的需求：「当车辆以≥25km/h的速度发生正面刚性壁障碰撞时，主驾气囊应在碰撞触发信号发出后30ms±5ms内完成完全充气，且展开后气囊中心点与H点（人体躯干与大腿的旋转中心）的水平距离应≤150mm。」

你想想看，哪个能测？哪个不能测？一目了然。

4.4 需求验证与确认：别等到测试才发现问题

验证和确认，很多人混着用。我简单区分一下：

• 验证（Verification）：我们做对了吗？（检查文档、设计、代码是否符合需求）
• 确认（Validation）：我们做的是对的吗？（检查最终产品是否满足用户真实需求）

验证的手段，我常用：

1. 同行评审：拉上3-5个工程师，逐条过需求。我习惯用「走读」的方式，每人拿一支红笔，现场改。
2. 原型仿真：用Simulink或Modelica搭个模型，跑几个典型场景，看看需求是否自洽。
3. 测试用例推导：每条需求，至少对应一个测试用例。如果写不出测试用例，说明需求不够具体。

确认的手段，更偏「用户视角」：

• 实车碰撞试验：这是最终确认。但成本高，所以前期仿真要做足。
• 用户验收测试（UAT）：请主机厂的测试工程师，按他们的驾驶习惯来操作。

最后，说个我自己的习惯。我会在需求文档的末尾，加一个「需求追溯矩阵」。每一行是一条需求，每一列是设计、代码、测试用例。这样，任何时候有人问「这个功能对应哪个需求」，我都能秒回。

好了，这一章就到这里。下一章，咱们聊聊如何用SysML建模语言，把需求画出来。那玩意儿，比文字直观多了。