从需求原文建立唯一入口
- 将来源章节、原始描述、责任人和状态保留在需求记录中。对含有多个判断条件的句子拆分后，保留拆分关系，避免后续评审无法回到原文。指标必须带单位、适用工况与判定条件；未确认的数值标记待澄清，不自行补成确定要求。
关系应该如何分层
- 区分需求分解、设计满足与验证关联。比如续航要求可以分配到能源系统，但关联一个电池模块并不等于满足续航；还要有功耗分析、任务工况和验证结果。不要把所有关系都命名为关联，否则影响分析无法区分设计责任与引用资料。
变更后检查哪些内容
- 需求调整时，从受影响的功能、接口与参数继续追到试验或仿真用例。冻结变更前后的模型版本，记录哪些结果需要重跑、哪些证据可以保留。删除需求也需要处理下游关系，不能留下看似完整的失效验证链接。
交付与抽查方法
- 建议移交需求字典、关系矩阵、孤立项清单及一条完整证据链示例。验收时随机选择正常、变更和关闭状态各一项，从原文追到模型和报告。无法追到原始证据的条目应进入问题清单，而不是只在矩阵中填上已覆盖。