3. 项目启动与需求工程

在AUTOSAR项目里，需求工程不是“把OEM发来的文档存进系统”这么简单。OEM通常以整车级功能需求（如“车速超过30 km/h时自动落锁”）或系统级技术规范（如某ECU的通信矩阵、诊断规范、网络管理要求）的形式下发，而Tier1需要把这些需求逐层分解为可分配给软件组件（SWC）、基础软件（BSW）和硬件接口的工程条目。项目启动阶段如果需求接收、解析和追溯没做扎实，后续架构设计、代码生成和集成测试都会反复返工。

一、接收OEM需求：先分清“输入物”的类型和边界

OEM下发的需求通常不是单一文件，而是一组交付物。常见输入包括：功能需求文档（FRD）、系统需求规范（SRS）、通信矩阵（DBC/ARXML）、诊断规范（ODX/CDD）、网络管理规范、功能安全需求（ISO 26262相关ASIL等级）、信息安全需求（ISO/SAE 21434）以及整车信号数据库。接收时第一步不是急着导入工具，而是建立“需求接收清单”，明确每份文档的版本、发布日期、适用范围（车型/平台/变型）、责任人和变更历史。

以某OEM的BCM（车身控制模块）项目为例，OEM提供了一份SRS，其中包含约420条系统需求，编号规则为SRS_BCM_xxxx，并附带一份DBC文件描述CAN信号。此时需要确认：SRS中的需求是否全部适用于本项目配置？DBC中的信号是否与SRS中的功能描述一一对应？如果OEM同时提供了ARXML格式的软件组件描述，还要确认其AUTOSAR版本（如R4.2.2或R4.4.0）是否与项目选用的Vector工具链版本兼容。

二、解析系统需求：从“一句话需求”到“可分配条目”

解析的核心动作是“拆解+分类+补充约束”。OEM的一条系统需求往往混合了功能行为、性能指标、接口定义和诊断要求。例如：“当车速>30 km/h且所有车门关闭时，BCM应在200 ms内通过CAN发送落锁指令，并支持UDS 0x2E写入配置。”这条需求至少应拆为：功能触发条件、执行动作、时间约束、通信接口、诊断服务、配置参数六类信息。

解析时建议使用“需求属性表”逐条标注：需求类型（功能/性能/接口/安全/诊断）、ASIL等级、验证方法（测试/分析/评审）、分配对象（SWC/BSW/硬件）、优先级。对于AUTOSAR项目，还要特别关注需求是否涉及SWC到SWC的端口连接、RTE事件、BSW模式管理或E2E保护。若OEM需求中存在模糊表述（如“快速响应”），必须转化为可测量的参数，例如“从信号接收到应用层处理完成≤50 ms”。

解析完成后，应形成一份“系统需求规格书（SyRS）”，它是OEM需求与后续软件架构之间的桥梁。SyRS中的每条需求都应有唯一ID，并与OEM原始需求建立链接。

三、建立需求追溯矩阵：让每条需求都有“来路”和“去向”

需求追溯矩阵（RTM）不是一张静态表格，而是贯穿项目生命周期的关系网络。在AUTOSAR项目中，追溯至少应覆盖四个层级：OEM需求 → 系统需求 → 软件架构元素（SWC/BSW模块） → 测试用例。正向追溯确保每条OEM需求都被实现，反向追溯确保每个设计元素都有需求依据，避免“镀金”功能。

实际操作中，可以在Vector工具中利用链接关系自动生成追溯视图。例如，在DOORS或Polarion中为每条需求设置“Satisfies”“Derives”“Verifies”等链接类型；在DaVinci Developer中，将SWC的端口和Runnable与系统需求ID关联。追溯矩阵的粒度建议到“需求条目级”，而不是文档级，否则无法定位变更影响。

四、使用Vector工具进行需求管理

Vector工具链在需求管理上的优势在于“需求—架构—代码—测试”的贯通。常用组合包括：DOORS或Polarion作为需求库，DaVinci Developer/Configurator作为架构与配置工具，CANoe/CANoe4SW作为测试工具。实际项目中，可以通过以下方式落地：

• 需求导入与链接：将OEM的SRS以ReqIF格式导入DOORS，保留原始ID和层级结构；在DOORS中建立“OEM需求→SyRS”的Derives链接。
• 架构关联：在DaVinci Developer中创建SWC和端口后，通过需求ID字段或外部链接将SWC的Runnable与SyRS条目关联。
• 配置追溯：在DaVinci Configurator中，对ComM、EcuM、Dcm等BSW模块的配置参数标注来源需求ID，便于变更时定位。
• 测试覆盖：在CANoe的测试用例中引用需求ID，生成覆盖报告，确认每条SyRS至少被一个测试用例验证。

需要特别注意的是，Vector工具之间的数据交换依赖ARXML和ReqIF标准。如果OEM提供的ARXML版本与工具版本不匹配，可能需要使用Vector的转换工具或手动调整命名空间。此外，需求变更时，应通过工具生成“追溯影响报告”，而不是人工翻文档。

五、一个可复用的需求追溯矩阵模板

下表给出一个适用于AUTOSAR项目的RTM字段示例，可直接在DOORS或Excel中建立。字段设计以“可追溯、可验证、可变更”为目标，不引入与项目无关的管理字段。

这张表的关键在于“每一列都有明确来源和去向”。OEM需求ID来自原始文档，SyRS ID由项目组分配，分配对象指向具体的SWC或BSW模块，测试用例ID指向CANoe工程中的测试节点。状态列用于跟踪实现进度，但不要把它变成任务管理工具，需求状态只反映“是否已实现并验证”。

项目启动阶段的需求工程，本质上是在OEM的“整车语言”和AUTOSAR的“软件语言”之间建立可验证的映射。接收时管好输入物，解析时拆到可分配粒度，追溯时保持双向链接，再用Vector工具把这条链路固化下来，后续的架构设计、代码生成和集成测试才有稳定的基线。