3. 项目启动与需求澄清

EyeQ项目启动阶段最容易被低估的工作，不是写代码，而是把OEM或Tier1给出的“整车语言”翻译成EyeQ能执行的“系统语言”。OEM的需求文档通常以整车功能为视角，例如“车辆应在高速公路上实现自动变道”“前向碰撞预警需在自车时速60km/h以上激活”；而EyeQ作为视觉感知SoC，需要的是可量化、可验证、可映射到具体算法模块与接口的系统需求，例如输入图像分辨率、帧率、检测距离、置信度阈值、输出信号周期与坐标系定义。需求澄清的本质，就是完成这两层语言之间的可追溯转化。

一、需求转化的四层映射

建议把转化过程拆成四层：整车功能需求 → 系统功能需求 → EyeQ子系统需求 → 软硬件接口需求。每一层都要保留来源标识，形成双向追溯链。以“自动紧急制动（AEB）对行人目标的有效识别”为例：

• 整车功能需求：车辆在自车时速10～80km/h范围内，对前方横穿行人实现AEB触发。
• 系统功能需求：感知系统需在白天/夜间、干燥/湿滑路面条件下，输出行人目标的位置、速度与置信度。
• EyeQ子系统需求：EyeQ4M需在100ms内完成单帧行人检测，输出目标框、距离估计与TTC，检测距离≥60m，最小行人高度像素≥24px。
• 接口需求：通过CAN FD以20ms周期发送目标列表，坐标系采用ISO 8855车辆坐标系，距离单位为米，置信度范围0～1。

这里的关键是：每一条EyeQ需求都必须能回答“它来自哪条OEM需求”以及“它将被哪条测试用例验证”。如果一条需求无法追溯来源，它很可能是工程师自行添加的“镀金需求”；如果一条OEM需求没有对应的EyeQ需求，则说明转化存在遗漏。

二、需求澄清中的典型歧义与处理

OEM文档中常见的模糊表述包括“及时”“准确”“在大多数场景下”“良好光照条件”。这些词不能直接进入EyeQ需求规格。澄清时可采用“参数化提问法”：把形容词替换为可测量参数，并请OEM确认边界值。例如：

澄清结果必须写入需求规格并经过OEM/Tier1确认，不能停留在会议纪要或口头共识中。对于暂时无法确认的参数，应标记为“待定项（TBD）”，并指定责任人与关闭时间，避免在开发后期才暴露需求缺口。

三、关键干系人识别

EyeQ项目涉及的角色远不止OEM和Tier1。需求澄清阶段应尽早识别以下干系人，并明确其关注点与决策权限：

• OEM功能负责人：定义整车功能边界与验收标准，是需求优先级的最终决策者。
• Tier1系统工程师：负责将OEM需求分解为域控制器或传感器需求，是EyeQ需求的主要输入方。
• EyeQ算法负责人：评估检测距离、帧率、算力占用等需求在EyeQ平台上的可实现性。
• 底层软件与BSP工程师：确认摄像头输入、CAN/Ethernet输出、时间同步等接口约束。
• 功能安全工程师：识别ASIL等级要求，确认安全机制与失效响应需求。
• 测试与验证负责人：确保每条需求都有可执行的验证方法，参与需求评审。

建议在项目启动会上产出一份干系人登记表，至少包含姓名、角色、所属组织、关注需求领域、决策权限、联系方式。对于跨时区、跨公司的项目，还应明确需求变更的提出与审批路径。

四、需求评审机制

需求评审不是一次性会议，而应嵌入需求生命周期的多个节点。推荐设置三级评审：

1. 内部技术评审：由EyeQ系统工程师与算法、软件、测试人员共同检查需求的可实现性、可测试性与一致性。
2. 联合需求评审：与OEM/Tier1逐条确认需求理解一致，重点澄清TBD项与接口定义。
3. 基线评审：需求冻结前进行，确认所有需求已分配唯一ID、来源、验证方法，并纳入配置管理。

评审检查项可包括：需求是否单一、无歧义、可验证；是否与上层需求追溯一致；是否存在相互冲突；性能指标是否包含测试条件与边界；接口信号是否定义完整。评审记录应保留问题清单、责任人、关闭状态，未关闭的问题不得进入基线。

五、从需求到规格的交付物

本节结束时，项目组应至少形成以下可交付成果：EyeQ系统需求规格书（含需求ID、描述、来源、优先级、验证方法）、需求追溯矩阵（OEM需求与EyeQ需求的双向映射）、干系人登记表、需求评审问题清单。这些成果是后续架构设计、软件实现与测试用例编写的共同输入。

需求澄清与评审的质量，直接决定后续架构设计和测试验证是否返工。在EyeQ项目中，建议把“需求可追溯、可验证、无歧义”作为启动阶段的退出准则，而不是等到集成测试阶段才发现需求本身存在冲突或缺失。