需求基线与变更控制是什么
需求基线是评审通过并被正式确认的那一版需求，包含条目、验收标准与追踪关系；它一旦建立，后续任何范围变化都要走影响分析、评估与审批，并更新基线与追踪矩阵。基线的目的不是冻结需求，而是让变化可见、可评估、可追溯：谁在什么时候加了什么需求、代价是多少、哪些测试与文档需要同步调整，都能查到。
基本信息
| 基线内容 | 已评审确认的需求版本 + 追踪关系 + 验收标准 |
|---|---|
| 变更流程 | 提出 → 影响分析 → 评估工作量与风险 → 审批 → 更新基线与追踪矩阵 |
| 常见角色 | 变更控制委员会（CCB）或产品决策组；执行由产品与研发共同承担 |
| 判定口径 | 影响验收标准、接口或数据模型的变更必须走流程 |
| 记录载体 | 变更单附影响分析结论与审批记录，与需求条目双向关联 |
典型使用场景
- 范围蔓延治理：临近发布新增需求时，先评估代价再决定是否纳入本次交付
- 合同类项目：需求变更是结算与工期调整的依据，需要书面记录与审批
- 多团队协作：一个需求改动牵动多个团队时，基线明确谁是受影响方
- 回归范围确定：按变更影响分析圈定受影响的用例，避免全量回归
- 验收争议处理：以基线与验收标准为准，而不是各方记忆与口头承诺
- 审计留痕：监管或客户要求提供需求变更历史的完整链条
变更影响分析清单
| 维度 | 核对内容 | 遗漏的后果 |
|---|---|---|
| 范围 | 涉及的需求条目与验收标准 | 漏项在验收时才发现，返工集中在后期 |
| 设计 | 接口契约、数据模型与部署拓扑是否受影响 | 上游不改，下游按新口径开发，联调时冲突 |
| 测试 | 回归范围与用例更新 | 旧用例失效或覆盖出现盲区 |
| 排期 | 工作量估算与依赖调整 | 排期不变而范围变大，质量被压缩 |
| 文档 | 追踪矩阵、术语表与用户文档同步更新 | 文档与实现长期不一致 |
变更记录要素
变更记录要素
# 变更单编号与提出人、提出时间
# 变更描述：改什么，涉及哪些需求条目
# 原因：业务变化、缺陷修复还是合规要求
# 影响分析：范围/设计/测试/排期/文档五维结论
# 评估结论：工作量、风险等级、建议接受或建议延后
# 审批记录：审批人、审批时间、是否附带条件
# 落地情况：基线版本号、追踪矩阵更新结果轻量项目可以用「需求库 + 变更记录」替代正式 CCB，但影响分析这一步不能省：省掉它，范围变化就变成不可解释的工期波动。
基线要有版本号并与追踪矩阵绑定，例如需求条目关联用例、接口与提交记录；变更后只更新文字而不更新关联关系，测试覆盖很快出现盲区。