4. 需求工程方法与车规需求规范
在车规ECU项目中，需求不是“写给人看的说明文档”，而是贯穿设计、实现、测试、诊断与法规认证的工程基线。需求工程的核心任务，是把整车层面的功能意图、法规约束和诊断要求，转化为可分配、可实现、可验证、可追溯的ECU级需求条目，并让每一条需求在生命周期内保持唯一身份和受控状态。对Continental这类Tier 1而言，需求规范的质量直接决定后续AUTOSAR软件架构、标定、测试用例和诊断数据库能否收敛。
需求分类：四类需求决定不同的验证路径
车规ECU需求通常分为功能需求、非功能需求、法规需求和诊断需求。功能需求描述ECU“做什么”，例如“当车速大于20 km/h且驾驶员未系安全带时，在5 s内点亮安全带警告灯并输出仪表报文”。非功能需求描述“做到什么程度”，包括时序、精度、资源占用、电磁兼容、功能安全等级和耐久性，例如“警告灯点亮延迟不超过200 ms，ASIL B”。法规需求来自强制标准或认证要求，如ECE R16关于安全带提醒、ISO 26262关于功能安全、UN R155/R156关于网络安全与软件更新。诊断需求则规定故障检测、DTC存储、冻结帧、老化清除和UDS服务，例如“检测到传感器信号超出有效范围超过500 ms后，置位DTC P0xxx，状态字节bit0置1”。
四类需求的验证路径不同：功能需求靠功能测试和HIL验证，非功能需求靠时序测量、资源分析和EMC试验，法规需求靠认证试验和法规符合性检查，诊断需求靠诊断测试和DTC复现。分类不清会导致测试用例遗漏，例如把诊断时序写成功能需求，就可能只做功能验证而漏掉UDS响应时间测试。
需求属性与追溯性：每条需求都要有“身份证”
一条合格的车规需求至少应具备以下属性：唯一ID、需求文本、类型、来源、优先级、ASIL等级、验证方法、状态、版本、负责人和上下游链接。唯一ID是追溯的锚点，来源说明它来自整车需求、法规条款还是内部设计约束，验证方法明确它是通过测试、分析、评审还是演示来确认。ASIL等级决定开发 rigor，优先级决定变更和缺陷处理顺序。
追溯性分为前向追溯和后向追溯。前向追溯从整车需求到ECU需求、软件需求、代码、测试用例；后向追溯从测试结果回到需求，证明每条需求都被覆盖。双向追溯矩阵是需求评审和功能安全审核的必查项。例如整车需求“碰撞后自动解锁”可分解为ECU需求“收到碰撞信号后100 ms内驱动门锁执行器解锁”，再链接到软件组件、CAN信号和HIL测试用例。若某条需求没有下游测试用例，就是覆盖缺口；若某个测试用例找不到上游需求，就是范围蔓延。
需求编写准则：无歧义、可验证、可分配
需求编写最常见的错误是模糊、复合和不可验证。模糊词如“快速”“适当”“尽可能”必须替换为可测量阈值。复合需求把多个行为塞进一句话，导致测试无法判定通过与否，应拆分为独立条目。可验证性要求每条需求都能设计出明确的通过/失败判据。
推荐采用“条件—主体—动作—对象—约束”的结构。例如：
【条件】当点火状态为ON且车速＞20 km/h
【主体】安全带提醒功能
【动作】输出警告
【对象】仪表警告灯
【约束】延迟≤200 ms，频率1 Hz，占空比50%这样写出的需求可以直接映射到测试用例：给定点火ON和车速25 km/h，测量警告灯首次点亮时间是否≤200 ms，并检查闪烁频率。需求中还应避免设计实现细节，例如不要写“使用某型号驱动芯片”，除非该约束来自硬件接口或法规。对于诊断需求，要明确DTC触发条件、去抖时间、恢复条件和清除条件，否则测试无法复现。
DOORS/Polarion工具使用：从文档到数据库
DOORS和Polarion是车规需求管理的主流工具。DOORS以模块化对象和链接关系见长，适合大型OEM与Tier 1之间的需求交换；Polarion更强调与ALM、测试管理和变更流程的集成。实际使用中，关键操作包括：建立需求模块和属性集，导入整车需求或法规条款，创建链接关系，生成追溯矩阵，执行基线冻结和变更影响分析。
以DOORS为例，典型操作是：打开模块，选中需求对象，在属性对话框中设置Type、ASIL、Verification Method等属性；使用“Link”菜单建立到下游测试模块的链接；通过“Analysis”生成覆盖率和孤儿需求报告。Polarion中则通过Work Item类型区分System Requirement、Software Requirement和TestCase，利用Traceability视图查看上下游关系。工具本身不保证质量，属性集和链接规则必须与项目需求管理计划一致，否则会出现“有链接但无有效追溯”的假象。
需求评审流程：分层评审与准入准出
需求评审不是一次会议，而是分层准入过程。典型流程为：作者自检→同行评审→系统/软件/测试联合评审→变更控制委员会批准→基线冻结。评审输入包括需求规范、追溯矩阵、检查表和上游需求；输出包括评审记录、缺陷清单、行动项和批准状态。评审检查表应覆盖：是否唯一ID、是否无歧义、是否可验证、是否与上游一致、是否分配了ASIL和验证方法、是否有下游测试链接。
评审缺陷要分级：致命缺陷如安全需求缺失或法规冲突，必须关闭后才能基线；主要缺陷如不可验证或追溯断裂，需在限定周期内关闭；次要缺陷如措辞优化，可记录后处理。评审通过后，需求进入基线，任何变更都要走变更请求，评估对设计、代码、测试和诊断数据库的影响。只有把评审、追溯和变更控制串成闭环，需求规范才能真正成为量产开发的受控输入。