先冻结评审对象
- 评审包至少标明模型版本、工具版本、采用的语言版本、建模约定和本轮需求基线。区分系统、分系统和设备等层级，并明确哪些对象属于本轮交付。不要把一个试点模型的检查结论扩展到整个产品。
- 准备一条从需求到功能、结构、接口和验证记录的代表性路径，由不同专业共同走查。路径中断时记录缺失对象或未确认假设，不能通过增加无明确含义的连线消除问题。
把检查拆成四类
- 完整性检查关注需求、功能、结构和约束是否覆盖约定范围；一致性检查关注端口方向、数据类型、单位及接口控制文件是否对应。相同名称不保证是同一个对象，判断时还要核对标识和归属。
- 行为检查覆盖正常路径、异常退出和恢复条件；可验证性检查要求每个关键指标有对应检查方法与证据。可执行模型应保留输入、运行条件和输出；概念模型则应注明哪些行为尚未执行验证。
覆盖率必须说明分母
- 分别统计纳入基线的需求总数、已建立有效关联的需求数、已有验证证据的需求数，以及不适用项。有关联不等于已验证，不同统计口径不能合并成一个宣传数字。
- 抽查孤立需求、失效链接和跨版本引用，记录异常的原因及负责人。阈值应由项目的风险和验收约定确定，不把某个项目的百分比要求直接当成 SysML 通用标准。
交付可复核的评审包
- 评审包包含检查清单、问题清单、模型基线、关键路径说明与证据索引。每条问题标明对象标识、复现方法、严重程度、修订版本和复核结果，关闭问题时保留前后对照。
- 效率改善可比较同类评审问题的定位时间、重复问题数量和问题关闭周期；只有在范围与检查方法一致时才做前后比较。模型审查通过不代表实物性能已通过试验。