4. 软件平台需求工程
车身域控制器（BDC）的软件平台需求工程，本质上是把整车层面的功能意图，逐级翻译成可被软件架构、模块设计和测试用例直接消费的、可验证的软件需求，并在整个生命周期内保持这条翻译链的可追溯、可变更、可冻结。它要解决的核心问题不是"写需求文档"，而是回答三个工程问题：整车功能需求如何落到 BDC 的软件接口与行为上？需求之间靠什么关系链保证不丢、不错、不重复？需求一旦变更，影响面如何被快速、完整地识别并受控？
一、需求分解：从整车功能到软件需求的层级
整车功能需求通常以用户可感知的功能描述出现，例如"车辆落锁后 3 秒内，若检测到车内仍有合法钥匙，则禁止落锁并发出提示"。这类需求属于整车级功能需求（Vehicle Function Requirement），它不关心由哪个 ECU 实现。分解到 BDC 软件平台，需要经过若干层级：
- 整车功能需求：描述用户可感知行为与整车级约束，如落锁逻辑、灯光响应、防夹策略。
- 系统需求（BDC 系统级）：把整车功能分配到 BDC 及其边界，明确 BDC 负责的输入信号、输出执行、与其他 ECU 的交互接口，例如通过 CAN 接收 PEPS 的钥匙状态、通过 LIN 驱动门锁电机。
- 软件平台需求：描述 BDC 软件平台应提供的能力，如信号采集与超时监控、状态机调度、诊断服务、电源模式管理、通信栈行为。
- 软件组件需求：落到具体模块，如门锁控制模块、钥匙检测模块、提示音模块的行为与接口。
分解的关键原则是"每一层只描述本层可验证的内容"。整车需求写"3 秒内禁止落锁"，系统需求写"BDC 在收到 PEPS 的钥匙在车内信号后，应在 100 ms 内抑制门锁驱动输出"，软件需求写"门锁控制模块在收到抑制请求后，将输出状态置为 INHIBITED，并置位诊断事件"。层级越往下，参数越具体、可测性越强。
二、追溯：需求关系链的建立与维护
追溯不是事后补的表格，而是需求分解时同步建立的关系。每一条软件需求都应能向上追溯到至少一条系统需求，每一条系统需求向上追溯到整车功能需求；同时向下关联到设计元素、代码模块和测试用例。追溯关系通常包括：派生（derive）、满足（satisfy）、验证（verify）、分配（allocate）。
在工程实践中，追溯关系应记录在需求管理工具中，并作为变更影响分析的基础。若某条整车需求变更，工具可沿追溯链自动列出受影响的系统需求、软件需求、测试用例和代码模块，避免人工翻查遗漏。
三、变更管理：影响分析与受控修改
需求变更在车身域控制器项目中极为常见，来源包括整车功能调整、法规更新、供应商接口变化、测试缺陷反馈等。变更管理的核心不是"禁止变更"，而是"每次变更都经过影响分析、评审、批准、实施和验证的闭环"。
一个可操作的变更流程如下：变更请求（CR）提交后，需求工程师首先在需求管理工具中执行追溯查询，列出所有直接和间接关联的需求、设计、代码和测试项；然后组织系统、软件、测试三方评审，评估工作量、风险和验证方案；批准后，变更被实施到需求库，版本号递增，追溯关系同步更新；最后通过回归测试确认变更未引入非预期影响。
以"落锁抑制时间从 3 秒改为 2 秒"为例，影响分析应至少覆盖：系统需求中的响应时间参数、软件需求中的状态机超时阈值、门锁控制模块的定时器配置、以及对应的测试用例 TC-042 的预期结果。若遗漏任何一项，就会出现需求与实现不一致的隐患。
四、需求基线：冻结与版本控制
需求基线是在特定时间点对一组需求及其追溯关系的正式冻结。基线的作用是：为开发、测试、供应商交付提供统一的参照版本；在变更发生时，能够明确"从哪个版本开始改、改了什么、为什么改"。
车身域控制器项目通常设置多条基线：整车功能需求基线、BDC 系统需求基线、软件平台需求基线、软件组件需求基线。每条基线包含需求条目、属性（状态、优先级、验证方法）、追溯关系和版本号。基线一旦建立，任何修改都必须通过变更流程，不能直接编辑。
五、需求属性与验证方法
每条软件需求应携带足够的属性，才能被下游消费。关键属性包括：唯一标识（如 SWR-BDC-0421）、需求描述、来源（上游需求 ID）、优先级、状态（草稿/已基线/已实现/已验证）、验证方法（测试/分析/评审/演示）、分配到的软件组件、关联测试用例 ID。
验证方法的选择直接影响测试策略。例如"门锁控制模块在收到抑制请求后 100 ms 内将输出置为 INHIBITED"适合用测试验证；"软件平台应支持至少 8 路 CAN 信号超时监控"适合用分析或评审验证；"诊断服务应支持 UDS 0x22 读取门锁状态"适合用测试验证。属性填写不完整的需求，往往在测试阶段才暴露问题，返工成本极高。
六、工程落地要点
要让需求工程真正落地，需要做到以下几点：第一，需求分解与追溯同步进行，不做事后补录；第二，变更影响分析必须基于工具中的追溯链，而非人工记忆；第三，基线建立后严格执行变更流程，禁止绕过；第四，需求属性填写完整，尤其是验证方法和分配组件；第五，定期进行需求评审和追溯完整性检查，确保没有"孤儿需求"（无上游来源）和"悬空需求"（无下游实现或验证）。
在车身域控制器软件平台中，需求工程的质量直接决定了后续架构设计、代码实现和测试验证的效率。一条清晰、可追溯、受控的需求链，是软件平台工程化的起点，也是项目可控交付的基础。