4. 评审输入工件：系统架构文档、软件架构文档、接口规范、需求追溯矩阵的检查要点
好，咱们进入第四讲。这一讲很实在，就是讲评审时手里拿到的那些文档，到底该怎么看。
我做了这么多年评审，发现一个现象：很多人评审时走马观花，翻一遍文档就说「没问题」。结果呢？后期集成时炸成一锅粥。说白了，评审不是走过场，是要带着「找茬」的心态去读每一份文档。
今天咱们就聊聊四类核心工件的检查要点。嗯，都是我用真金白银的教训换来的。
4.1 系统架构文档：别被漂亮的图骗了
系统架构文档，说白了就是整个系统的「骨架图」。我见过不少团队，画图一流，逻辑三流。
检查要点一：层级关系是否清晰？
我个人习惯，拿到文档先看目录结构。系统架构应该从顶层往下分解，每一层都要有明确的职责边界。你想想看，如果ECU的供电模块既管电源又管通信，那后面肯定要出问题。
检查要点二：接口定义是否完整？
这里我踩过坑。有一次评审一个ADAS系统架构，画面上每个模块都标了箭头，但箭头上的信号名、数据类型、周期全都没写。我当时就问：「这个箭头到底传什么？」对方答不上来。结果后来联调时，发现两个模块对同一个信号的理解完全不一样。
- 每个模块的输入/输出是否明确？
- 接口的数据类型、范围、单位是否定义？
- 通信协议（CAN/LIN/Ethernet）是否标注？
- 时序要求（周期、延迟、抖动）是否写明？
检查要点三：非功能需求是否体现？
系统架构不能只画功能模块。安全性、可靠性、实时性这些非功能需求，必须在架构层面有体现。比如，安全相关的功能有没有独立的监控路径？冗余设计有没有做？
4.2 软件架构文档：代码的「施工图」
软件架构文档，是给程序员看的施工图。我经常说，没有好的软件架构，代码写得再漂亮也是空中楼阁。
检查要点一：模块划分是否合理？
好的软件架构，模块之间应该是高内聚、低耦合的。我见过一个项目，把传感器数据处理、诊断、通信全部塞进一个模块里。结果每次改一个功能，都要动整个模块，测试回归量巨大。
这里有个小技巧：看模块的接口数量。如果一个模块有超过10个对外接口，大概率是设计有问题。我曾经在一个项目中，把一个模块从15个接口砍到5个，代码量反而减少了30%。
检查要点二：运行时视图是否清晰？
静态结构图只是第一步。你还要看运行时视图——任务怎么调度？中断怎么处理？资源怎么竞争？
我记得有一次评审，软件架构文档画了20多个任务，但没画任务间的同步关系。我问：「这些任务谁先跑？谁后跑？共享资源怎么保护？」设计者一脸懵。后来果然出了死锁问题。
评审时，要求设计者画出任务时序图。至少要把关键路径上的任务调度关系讲清楚。
检查要点三：错误处理机制是否覆盖？
很多软件架构只画正常流程，对异常情况一笔带过。但汽车电子里，异常才是常态。传感器失效怎么办？通信超时怎么办？内存不足怎么办？
我曾经评审过一个制动系统的软件架构，发现错误处理只写了「返回错误码」。我问：「返回错误码之后呢？系统怎么降级？」设计者说：「这个后面再细化。」——嗯，这种回答我一般直接打回重写。
4.3 接口规范：细节决定成败
接口规范，是团队协作的「契约」。我见过太多因为接口没对齐导致的返工了。
检查要点一：命名是否规范？
接口命名要见名知意。我见过一个项目，信号名叫「Sig_123」，没人知道它代表什么。后来查文档才知道是「车速信号」。你说这种命名，后期维护的人得多痛苦？
检查要点二：数据类型和范围是否明确？
这个看起来简单，但最容易出错。比如，一个温度信号，范围是-40°C到125°C，分辨率0.1°C。如果接口规范里只写了「温度信号」，没写范围和分辨率，那不同模块之间肯定要打架。
检查要点三：时序约束是否完整？
接口规范不能只写静态信息。信号的发送周期、最大延迟、超时时间，这些都要写清楚。我遇到过一个问题：一个传感器信号周期是10ms，但接收方按100ms的超时去判断，结果传感器真的失效了，系统过了100ms才检测到，差点出事故。
接口规范中的时序参数，必须和系统架构文档保持一致。我建议评审时，拿着接口规范逐条对照系统架构文档，确保没有遗漏或矛盾。
4.4 需求追溯矩阵：别让它变成摆设
需求追溯矩阵，很多人觉得就是做个表格应付审核。但我觉得，它是保证「需求不丢失」的生命线。
检查要点一：双向追溯是否完整？
需求追溯矩阵要支持双向追溯：从需求到实现，从实现到需求。我评审时，会随机抽几个需求，看它们是否都追溯到了对应的架构元素和测试用例。反过来，也会抽几个架构元素，看它们是否都有对应的需求。
有一次，我抽到一个「故障诊断功能」，发现它没有对应的需求。一问才知道，这是开发人员自己加的「彩蛋」。嗯，这种没有需求支撑的功能，后期维护时第一个被砍掉。
检查要点二：追溯关系是否合理？
不是所有需求都要追溯到一个架构元素。有些需求是全局性的，比如「系统响应时间小于100ms」，它可能影响多个模块。这种情况下，追溯矩阵要体现这种多对多的关系。
我见过一个项目，把「系统响应时间」这个需求只追溯到了一个模块。结果其他模块根本没考虑这个约束，最后集成时响应时间超标了3倍。
检查要点三：变更管理是否同步？
需求是会变的。每次需求变更，追溯矩阵必须同步更新。我评审时，会看矩阵的版本号和变更记录。如果发现矩阵的版本落后于需求文档的版本，那基本可以断定，这个矩阵已经失效了。
需求有出处，实现有依据。
变更要同步，追溯要双向。
接口要规范，时序要明确。
架构要清晰，错误要处理。
4.5 总结：评审不是找茬，是防患于未然
好了，这一讲的内容就这些。总结一下：
- 系统架构文档：看层级、看接口、看非功能需求
- 软件架构文档：看模块划分、看运行时视图、看错误处理
- 接口规范：看命名、看数据类型、看时序约束
- 需求追溯矩阵：看双向追溯、看合理性、看变更同步
说实话，这些检查要点看起来多，但真正做起来，就是养成习惯。我刚开始做评审时，也经常漏掉东西。后来我给自己做了一个检查清单，每次评审前先过一遍清单，慢慢就熟练了。
下一讲，咱们聊聊评审中的沟通技巧。毕竟，评审不是一个人闷头看文档，是要和团队一起讨论的。到时候见。