4、HUD系统需求规范（SysReq Spec）：编写高质量的系统需求（清晰、无歧义、可测试）、需求追溯矩阵（RTM）建立、需求评审流程与Checklist
好，我们进入第四讲。这一讲，我打算聊聊HUD系统需求规范怎么写。
说实话，很多团队在HUD开发上栽跟头，不是技术不行，而是需求写得一塌糊涂。我见过一个项目，需求里写着“HUD显示清晰”，结果测试和开发吵了三个月——什么叫清晰？亮度多少？对比度多少？没人说得清。
所以，高质量的系统需求，是ASPICE落地的第一道关卡。今天我就把我在几个量产HUD项目里踩过的坑、总结的经验，一次性讲透。
4.1 高质量系统需求的三个核心特征
我个人习惯，判断一条需求好不好，就看三点：清晰、无歧义、可测试。缺一不可。
4.1.1 清晰（Clear）
清晰的意思是，任何一个人读这条需求，理解都是一致的。不要用“适当的”、“合理的”、“良好的”这类模糊词。
❌ 反面案例：
“HUD在强光下应保持良好的可读性。”
✅ 正面案例：
“在环境光照度≥100,000 lux（模拟正午太阳直射）条件下，HUD虚像亮度≥12,000 cd/m²，字符对比度≥8:1。”
你看，后者把条件、指标、单位全写清楚了。测试工程师拿到这条需求，直接就能写测试用例。
4.1.2 无歧义（Unambiguous）
歧义是需求里最隐蔽的杀手。我记得有一次评审，需求写着“HUD图像应与前挡风玻璃对齐”。结果结构工程师理解为“图像中心对齐玻璃中心”，光学工程师理解为“图像边缘对齐玻璃边缘”。
嗯，后来我们加了一句话：“HUD虚像投影区域应完全位于前挡风玻璃的楔形膜区域内，且虚像下边缘距玻璃下边缘距离为30mm±2mm。” 歧义瞬间消失。
4.1.3 可测试（Testable）
可测试性，说白了就是这条需求能不能用仪器测出来。我曾经在评审时问需求作者：“这条需求你打算怎么测？” 他愣住了。
我的经验法则：
写需求时，脑子里同步想测试方法。如果想不到怎么测，这条需求大概率不合格。
举个例子，关于HUD的虚像距离（VID）：
- 不可测试：“HUD虚像应看起来在远处。”
- 可测试：“在驾驶员眼点位置（按SAE J941定义），使用平行光管测量，HUD虚像距离应为7.5m±0.5m。”
4.2 需求追溯矩阵（RTM）建立
RTM，很多人觉得就是做个Excel表，把需求编号列一列。其实没那么简单。
我参与过一个项目，客户需求有200多条，系统需求衍生出800多条。如果没有RTM，你根本不知道哪条客户需求被覆盖了，哪条被遗漏了。
4.2.1 RTM的结构
我个人习惯用四列结构：
| 列名 | 内容 | 示例 |
|---|---|---|
| 客户需求ID | 来自SOR或客户规范 | CR-001 |
| 系统需求ID | 本层级的SysReq编号 | SR-HUD-012 |
| 追溯关系 | 正向/反向/双向 | 双向追溯 |
| 覆盖状态 | 已覆盖/部分覆盖/未覆盖 | 已覆盖 |
⚠️ 注意：RTM不是一次性建完就完事了。需求变更时，RTM必须同步更新。我曾经吃过这个亏——客户改了SOR，我们忘了更新RTM，结果测试阶段才发现有一条关键需求没实现，返工成本超过20万。
4.2.2 双向追溯的重要性
ASPICE明确要求双向追溯。什么意思？
- 正向追溯：从客户需求出发，能找到对应的系统需求。
- 反向追溯：从系统需求出发，能找到它来源于哪条客户需求。
你想想看，如果只有正向没有反向，系统需求里多了一条“HUD应支持OTA升级”，但客户根本没提这个要求——这就是典型的镀金（Gold Plating），ASPICE审核时会被开不符合项。
4.3 需求评审流程与Checklist
评审，不是走过场。我见过太多评审会，大家坐在一起念PPT，念完就散会，什么问题都没发现。
4.3.1 评审流程（我推荐的三步法）
- 预审（30分钟）：评审人提前阅读需求文档，标注疑问点。我个人要求评审人至少提前24小时拿到文档。
- 正式评审（1-2小时）：聚焦争议点和关键需求，不逐条朗读。主持人控制节奏，避免跑题。
- 跟踪闭环（持续）：评审发现的问题，必须落实到责任人，设定关闭日期。我习惯用Jira或类似工具跟踪。
4.3.2 评审Checklist（我压箱底的清单）
这份清单是我在多个项目里迭代出来的，分享给你：
| 检查项 | 检查内容 | 通过标准 |
|---|---|---|
| 完整性 | 是否覆盖所有客户需求？ | RTM显示100%覆盖 |
| 一致性 | 需求之间是否有冲突？ | 无逻辑矛盾 |
| 可测试性 | 每条需求是否有明确的测试方法？ | 测试工程师确认可测 |
| 无歧义性 | 是否使用模糊词汇？ | 无“适当、合理、良好”等词 |
| 可验证性 | 指标是否有量化阈值？ | 所有指标有数值+单位+公差 |
| 可追溯性 | 是否建立双向追溯？ | RTM完整且最新 |
一个小技巧：评审时，我要求每条需求必须有一个“测试方法”字段。如果写不出来，这条需求打回重写。这个习惯帮我挡住了至少30%的垃圾需求。
4.4 避坑指南：我踩过的三个坑
最后，分享三个我亲身经历过的坑，希望你别再踩。
坑一：需求写得太细，变成设计。
我曾经在系统需求里写了“HUD使用TI的DLP芯片”。结果后来TI芯片缺货，想换安森美的方案，但需求已经冻结，走变更流程走了两个月。记住：系统需求关注“做什么”，不关注“怎么做”。
坑二：忽略非功能需求。
很多团队只关注功能需求，比如显示什么内容、亮度多少。但HUD是安全件，EMC、热管理、机械振动这些非功能需求同样重要。我见过一个项目，HUD功能全对，但EMC测试不过，延迟了3个月上市。
坑三：RTM只做一次。
需求是活的。客户会变，供应商会变，法规会变。RTM必须跟着变。我建议每个迭代结束时，花半天时间刷新RTM，确保它始终反映最新状态。
好，这一讲就到这里。下一讲，我们会进入HUD的架构设计阶段，聊聊怎么把系统需求分解成软硬件架构。到时候见。