智能座舱/IVI 做 ASPICE：需求评审 Checklist TOP30
智能座舱（IVI/CDC/Infotainment）项目的 ASPICE L2 落地，最容易“翻车”的环节往往不是代码，而是需求。原因很现实：座舱需求来源多（产品、交互、导航、语音、应用生态、法规与安全要求）、变更频繁、跨团队协作复杂。一旦需求质量不稳定，后面的设计、测试与追溯都会被拖垮，评估抽样时“对不上”的概率极高。
需求评审（Review）是把风险前移的最低成本手段。本文给出一份可直接复用的“需求评审 Checklist TOP30”，覆盖 IVI 项目最常见的抽样关注点：可测试性、边界条件、HMI/交互一致性、接口与依赖、性能与启动时间、日志与可诊断性、法规与隐私合规等。只要按清单执行并沉淀问题闭环，你就能显著降低后期返工与复核风险。
在深圳华赛信息咨询的辅导实践中，我们发现：座舱项目如果把需求评审做成硬门禁（Checklist+问题闭环），通常能把系统测试阶段才暴露的缺陷比例降低 约 20%-40%，同时把“评估前集中补证据”带来的产能损失压缩到 10%-15% 以内。
为什么 IVI 需求最容易被 ASPICE 抽样“击穿”？
评估师抽样需求时，常见提问链路是：这条需求怎么验收？边界条件是什么？依赖谁？变更如何控制？测试用例如何覆盖？对应的发布版本如何复现？如果需求本身没有清晰的验收标准与约束，后续证据链就很难闭环。
需求评审的正确产物：不是“签字”，而是“问题闭环”
一份可审计的需求评审证据通常包含：评审对象与版本、参与人、时间、Checklist、问题清单、问题关闭记录与复核结论。座舱项目建议把需求评审做成两级：
- 一级评审（需求质量门禁）： 可测试性、完整性、一致性、可追溯性。
- 二级评审（座舱专项门禁）： HMI/交互、性能启动、日志诊断、隐私合规、接口依赖。
智能座舱/IVI 需求评审 Checklist TOP30
| 序号 | 检查项 | 判定标准（要看到什么） | 常见问题（IVI 高发） |
| 1 | 需求是否唯一编号且版本可追溯 | 需求 ID、版本号/基线、变更记录可定位 | 需求在文档里改了但系统里无记录 |
| 2 | 需求是否有明确验收标准（AC） | 可量化/可观察的验收条件与判定方式 | 只写“体验更好/更流畅/不卡顿” |
| 3 | 需求是否可测试（Testable） | 能写出对应测试用例与预期结果 | 需要“主观判断”的描述过多 |
| 4 | 需求边界条件是否明确 | 异常/极限/网络断开/权限不足等场景定义 | 只描述正常流程，异常全靠猜 |
| 5 | 需求输入/输出是否完整 | 输入来源、输出行为、状态变化描述清晰 | 状态机缺失，事件触发不清 |
| 6 | 术语是否统一（Glossary） | 关键名词有定义，跨团队一致 | 同一功能被不同团队叫不同名字 |
| 7 | 需求优先级与范围是否清晰 | Must/Should/Could 或 P0/P1/P2 明确 | 所有需求都“必须”，资源无法排期 |
| 8 | 依赖项是否明确（系统/供应商/接口） | 依赖对象、接口版本、交付条件明确 | 依赖没写，集成阶段集中爆雷 |
| 9 | 接口与信号是否定义（对外/对内） | 接口字段、频率、时序、错误码、超时策略 | 只写“对接 XXX”，无接口细节 |
| 10 | 需求是否与系统需求保持一致 | SYS.2 ↔ SWE.1 双向追溯可证明 | 软件需求自嗨，系统需求未覆盖 |
| 11 | HMI/交互流程是否清晰（座舱专项） | 页面/状态/跳转/返回/焦点规则定义 | 交互只靠 UI 图，逻辑无描述 |
| 12 | 多语言/本地化要求是否明确 | 语言范围、切换规则、字符串长度约束 | 后期发现截断/布局崩坏 |
| 13 | 性能指标是否量化（启动、响应、帧率） | 冷启动/热启动、页面响应时间、FPS 门槛 | “秒开/不卡”无量化标准 |
| 14 | 资源约束是否说明（CPU/内存/存储） | 资源上限、告警阈值、降级策略 | 资源不设限，集成后频繁 OOM |
| 15 | 网络条件与弱网策略是否明确 | 断网/弱网/切网行为、超时、重试与缓存策略 | 在线功能弱网体验不可控 |
| 16 | 离线能力与数据一致性是否定义 | 离线可用范围、数据同步规则、冲突处理 | 离线与在线状态切换后数据错乱 |
| 17 | 日志与可诊断性要求是否明确 | 关键事件日志、错误码、埋点、抓取方式 | 问题复现难，定位全靠运气 |
| 18 | 异常处理与用户提示是否明确 | 异常提示文案、兜底页面、恢复路径 | 异常直接白屏/卡死 |
| 19 | 权限与账号体系是否定义 | 登录态、权限模型、访客模式、退出行为 | 权限边界不清，出现越权 |
| 20 | 隐私合规（PIPL/GDPR）是否覆盖 | 采集范围、用途、同意管理、撤回机制 | 只写“合规”，无具体机制 |
| 21 | 数据安全与传输加密是否明确 | 加密算法/通道、证书策略、密钥管理边界 | 安全要求落在实现阶段才补 |
| 22 | OTA/升级相关要求是否定义 | 升级策略、回滚、断电恢复、版本兼容 | 升级失败后不可恢复，影响量产 |
| 23 | 第三方应用/生态依赖是否明确 | 应用名单、版本策略、上架/下架流程 | 生态变动导致功能不可用 |
| 24 | 语音/导航/媒体等关键能力的降级策略 | 降级触发条件、降级后体验与提示 | 某模块异常导致全局不可用 |
| 25 | 并发与多任务场景是否覆盖 | 来电/倒车/语音中断等打断场景定义 | 状态恢复异常，用户投诉高 |
| 26 | 时间/时区/夏令时等时间相关需求是否明确 | 时区切换、NTP、离线时间策略 | 日志时间错乱，定位困难 |
| 27 | 异常数据与容错策略是否定义 | 输入校验、容错、默认值与告警 | 脏数据导致崩溃 |
| 28 | 验证方式与责任人是否明确 | 验证类型（单测/集成/系统/验收）、Owner | 测试责任不清，评估现场说不一致 |
| 29 | 需求变更触发的回归范围是否定义 | 回归策略、影响分析记录、回归用例集合 | 变更后只测改动点，漏回归 |
| 30 | 追溯链接是否可用且可点出证据 | 需求 ↔ 设计 ↔ MR/PR ↔ 用例 ↔ 执行记录 ↔ 基线 | 链接存在但指向空或版本不匹配 |
怎么用这份 Checklist 跑出“可抽样证据”？
步骤一：把 Checklist 变成评审门禁
评审不是走过场。建议规定：未通过关键项（如可测试性、验收标准、边界条件、依赖与接口、追溯）不得进入开发。
步骤二：评审问题必须进入工单并闭环
把评审问题记录到缺陷/任务系统，明确 Owner 与截止时间。评审通过的证据应包含问题关闭记录与复核结论。
步骤三：抽样演练常态化
每个迭代至少抽样 1 条需求，从需求追到测试执行记录与发布基线。抽样跑得通，评估与 OEM 复核就不会变成突击战。
华赛咨询如何帮助座舱团队把需求评审“跑成习惯”？
深圳华赛信息咨询通常从三件事入手：
- 需求口径统一： 建立座舱领域的术语表与需求模板，减少歧义。
- 工具链固化： 在 Jira/ALM 中配置必填字段、追溯链接与评审门禁，让证据自动沉淀。
- 陪跑两轮迭代： 用真实需求跑评审、跑问题闭环、跑抽样演练，形成可审计的证据链。
常见问题解答 (FAQ)
Q1：TOP30 太多了，我们能不能只做核心项？
A： 可以。建议先落地 10 个核心项：编号与版本、验收标准、可测试性、边界条件、依赖与接口、性能量化、日志诊断、隐私合规、变更与回归、追溯可点。跑顺后再扩展到完整 TOP30。
Q2：需求评审做得严，会不会拖慢进度？
A： 前 2-3 周可能会变慢，但返工率会明显下降。对座舱项目来说，把缺陷从系统测试阶段前移到需求评审阶段，综合成本更低。
Q3：如何把“可测试性”落到具体写法？
A： 把主观词改为可观测指标：响应时间、启动时间、错误码、状态机、日志点、触发条件与预期结果。只要测试能根据需求写出用例并给出判定方法，可测试性就成立。
IVI 项目要想 ASPICE L2 跑得稳，需求评审是最值得投入的第一步。把 Checklist 做成门禁，把问题做成闭环，你就能把风险在最便宜的阶段消化掉。
如果您希望我们为您的座舱团队定制一份“需求评审 Checklist + 工具字段模板 + 抽样演练脚本”，欢迎联系深圳华赛信息咨询获取方案。