瀑布模型下做数据迁移，需求文档要写哪些内容
如果要把现有系统的数据迁移到新平台，需求文档应该覆盖哪些业务边界、数据来源和目标范围，才能避免迁移过程中反复变更？
明确迁移范围与业务边界
需求文档应清楚写明迁移涉及的业务系统、数据源系统、目标系统、数据类型和迁移边界，包括哪些数据要迁、哪些数据不迁、是否包含历史数据、是否涉及多系统联动，以及迁移目标是替换旧系统、并行运行还是分批切换。范围越清晰，后续的开发、测试和验收越容易统一标准。
在迁移项目中，除了列出要迁移的数据表，还需要把字段映射、清洗规则、重复数据处理和校验规则写到什么程度，才算可执行？
把数据规则写成可落地的执行说明
需求文档要详细描述源字段与目标字段的映射关系、数据格式转换规则、空值处理方式、重复数据去重规则、异常数据处理方式和校验口径。若涉及主数据、编码规则、日期格式、单位换算或权限字段，也要明确转换标准。写法应尽量具体到可直接用于开发和测试，避免只停留在原则层面。
项目已经有明确计划，为什么还要在需求文档中定义验收条件、对账口径和成功标准，这些内容会影响哪些环节？
验收标准决定项目是否能顺利交付
在瀑布模型中，需求文档不仅用于定义要做什么，也用于定义做到什么程度算完成。验收标准应包括数据完整率、准确率、迁移成功率、对账方式、容错范围、性能要求和业务验收口径。若没有清晰标准，测试阶段和上线验收时很容易出现争议，导致返工和延期。
除了数据本身，需求文档要不要描述停机窗口、切换方式、回退方案和上线后的观察期，这些内容在项目中有什么作用？
迁移需求也要覆盖切换与回退安排
需要写。数据迁移不是单纯搬数据，还涉及业务何时切换、是否允许双轨运行、出现问题时如何回退，以及上线后如何观察数据稳定性。文档中应明确切换窗口、回退条件、应急处理流程、责任人和沟通机制，这样实施团队和业务团队才能在同一套预案下协作。