3. 功能需求捕获与利益相关者分析

在车规ECU项目中，需求不是凭空写出来的，而是从多个来源“捕获”并经过结构化整理后形成的。整车厂给出的是整车级功能与性能目标，系统工程师负责将其分解为ECU可实现的接口与行为，法规与标准提供强制约束，终端用户则通过使用场景和抱怨反馈影响需求优先级。本节围绕“从哪里来、由谁决定、如何记录”三个问题展开，重点讲清需求来源识别、利益相关者矩阵、需求捕获模板以及一次可复现的实战演练。

一、需求来源识别：四类输入缺一不可

车规ECU的功能需求通常来自以下四类输入，每类输入的载体、粒度和变更节奏都不同：

• 整车厂（OEM）：以整车功能规范、网络通信矩阵、诊断规范、电源管理策略、功能安全目标（如ASIL等级）等形式下发。例如某车身域控制器要求“在KL30电压9V~16V范围内，车门锁执行器响应时间≤150ms”。
• 系统工程师：将整车功能分解为ECU内部软件组件、接口信号、状态机与资源约束。例如把“遥控解锁”分解为RF接收、LIN通信、电机驱动、电流采样与防夹判断等子需求。
• 法规与标准：如ISO 26262功能安全、ISO 21434网络安全、UN R155/R156、GB/T 34590、排放与诊断法规（OBD）。这类需求通常不可协商，必须逐条追溯。
• 终端用户：通过售后抱怨、J.D. Power调研、驾驶场景观察获得，例如“冬季低温下门锁偶发不动作”“解锁后后视镜展开延迟明显”。用户需求往往以场景和感受描述，需要转化为可测量的工程指标。

识别来源时，建议对每条原始输入标注来源类型、原始编号、接收日期、责任人，避免后续追溯断链。来源识别不清，是后期需求变更扯皮的主要原因。

二、利益相关者矩阵：谁影响需求、谁被需求影响

利益相关者分析的目的不是列名单，而是判断谁有权提出需求、谁有权批准需求、谁需要被通知。在车规ECU开发中，常用“权力—利益”矩阵进行分级：

• 高权力、高利益：OEM系统工程师、功能安全经理、项目总师。必须深度参与需求评审，需求变更需其签字。
• 高权力、低利益：法规认证机构、网络安全审计方。平时不参与日常讨论，但关键节点必须提交证据。
• 低权力、高利益：终端用户、售后维修技师、生产线装配人员。其反馈影响需求优先级和可维护性设计。
• 低权力、低利益：一般观察方，保持信息同步即可。

矩阵不是静态的。当项目进入量产阶段，生产线和售后的话语权会上升；当出现安全事件时，法规与安全经理的权力会临时提高。因此建议在需求基线评审前更新一次矩阵。

三、需求捕获模板：把“一句话”变成可验证条目

捕获到的原始需求往往是一句话，必须结构化为可验证条目。推荐字段如下：

模板的价值在于：每条需求都能回答“从哪来、怎么验、谁负责”。缺少验证方法的需求，在测试阶段往往无法判定通过与否。

四、实战演练：从用户抱怨到基线需求

假设某车型售后反馈“冬季早晨遥控解锁，左前门偶尔无反应”。我们按以下过程捕获并转化：

1. 场景还原：温度-20℃，KL30电压10.5V，遥控钥匙电量正常，连续操作3次，第2次无动作。
2. 来源标注：终端用户抱怨，售后工单号SC-2024-1187。
3. 初步分解：可能涉及RF接收灵敏度、LIN通信超时、电机驱动低温扭矩、电源跌落复位。
4. 转化为需求：REQ-BCM-0117——“在-40℃~+85℃、KL30 9~16V条件下，连续10次有效遥控解锁指令，左前门锁执行器成功响应次数≥10次，单次响应时间≤150ms。”
5. 验证方法：高低温箱内台架测试，记录每次响应时间与电流波形。
6. 利益相关者确认：OEM系统工程师确认指标，售后提供故障件，功能安全经理确认无ASIL提升。

该需求进入基线后，测试工程师即可按-40℃、9V、10次循环执行，判定标准明确。若实测第7次响应时间为180ms，则需求不通过，需回到系统工程师处分析是电机驱动还是通信超时导致。

五、常见问题与判断依据

在实际项目中，需求捕获最容易出现三类问题：一是来源未标注，导致变更时找不到原始依据；二是利益相关者遗漏，例如忘记产线装配对安装空间的需求，导致量产时干涉；三是需求描述不可验证，例如“解锁要快”无法判定通过与否。判断一条需求是否合格，可以问三个问题：能否追溯到来源？能否设计出测试用例？能否明确通过/不通过？三者缺一，需求就不应进入基线。

此外，法规类需求必须单独建立追溯矩阵，将法规条款与ECU需求一一对应。例如UN R155要求车辆制造商建立网络安全管理体系，对应到ECU层面可能分解为安全启动、安全通信、诊断访问控制等需求。这类需求变更频率低，但一旦遗漏，可能导致整车无法认证。