Day24-02｜5.2.2 需求变更：用可追踪的决策控制变化，而不是压制变化

本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.2.2“需求变更”。软件系统在开发、部署和运行过程中必然会发生需求变化，原因包括业务策略调整、法规变化、用户反馈、技术约束、竞争压力、缺陷修正和外部系统变化。需求变更管理的目的不是拒绝变化，而是识别变化、评估影响、确定优先级、批准实施、验证结果并维护相关基线，使变化带来的价值大于成本和风险。

一、学习目标与考试定位

完成本节后，应能够解释需求变更的来源和特点，理解需求基线、变更请求、影响分析、审批、实现、验证和关闭的完整流程；能够分析变更对范围、进度、成本、架构、质量、数据、测试、部署和运维的影响；能够说明 CCB（变更控制委员会）的职责和适用边界；能够在敏捷项目中理解待办优先级与变更控制的关系；能够在案例题和论文中设计既响应变化又不失控的变更机制。

软考高级案例题常描述“客户不断插入需求”“需求变更未经评估直接修改代码”“一个小改动导致多个模块和报表出错”“项目末期仍然频繁改范围”。高分答案必须体现变更的闭环：提出、记录、分类、影响分析、决策、计划、实施、测试、发布、验证和基线更新。只写“加强沟通”或“需求冻结”都不够。

二、需求变更的基本概念

需求变更是已确认的需求、约束、验收标准或需求属性发生新增、删除、修改、澄清或优先级调整。变更可能发生在需求基线建立前，也可能发生在基线建立后。基线是一组经过评审和批准、作为后续活动依据的需求或相关产物版本。基线并不意味着永久不变，而是意味着变更必须通过正式控制并留下证据。

需求变化可以是正向的，例如增加用户价值、适应新法规、修复需求误解；也可能带来风险，例如范围蔓延、架构不一致、测试不足、数据迁移错误和进度延期。变更管理要关注变化的价值与代价，而不是把所有变更视为坏事。

可以把需求变更闭环记为：

提出请求 → 记录与分类 → 影响分析 → 批准或拒绝 → 排期实施 → 验证发布 → 更新基线 → 复盘关闭

三、需求变更的来源

业务来源包括战略调整、市场竞争、用户反馈、流程变化、组织重组和新业务机会；外部来源包括法律法规、行业标准、合作伙伴接口、供应商产品和操作系统升级；内部来源包括需求澄清、缺陷修复、架构评审、性能测试、安全测试和运维事故；项目来源包括资源变化、进度约束、预算调整和技术可行性发现。

变更请求应说明背景、目标、具体内容、提出人、紧迫性、影响范围和期望时间。仅在聊天工具中说一句“顺便加一下”不能作为可执行需求，因为它没有责任、优先级、验收标准和变更证据。紧急变更可以走快速通道，但事后仍需补齐记录和复盘。

四、变更影响分析

影响分析是需求变更管理的核心。首先分析业务和范围：变更解决什么问题，是否改变目标用户、业务流程、角色和验收标准；其次分析架构：是否影响模块边界、接口、数据所有权、通信、部署、权限和质量属性；再次分析工程：需要修改哪些需求、设计、代码、数据库、测试、文档、配置、脚本和培训；最后分析计划、成本、资源、风险和上线窗口。

影响分析不能只靠提出变更的人完成，应由业务、产品、架构、开发、测试、数据、安全、运维和项目管理共同参与。分析结果要给出备选方案、工作量、依赖、风险、收益、回滚方法和不变更的后果。对于影响不确定的技术问题，可以先安排一个时间受限的原型或调研任务，避免在信息不足时直接承诺。

五、变更控制委员会与决策机制

CCB 是负责审查和批准重要变更的角色集合，成员通常包括业务代表、项目经理、架构师、技术负责人、测试、运维、安全和配置管理人员。它的职责不是替团队决定每个字段，而是根据价值、影响、风险、资源和约束决定是否纳入范围、何时实施以及由谁负责。

小变更可以授权给产品负责人或团队在预设规则内快速决策，大变更、架构变更、合同变更、安全和合规变更需要更高层级审批。审批层级应与风险和影响匹配，所有变更都提交同一个委员会会造成瓶颈。CCB 的决策应记录批准、拒绝、延期或需要补充分析的理由。

六、基线、版本与追踪关系

需求基线、架构基线、代码版本、数据库脚本、测试用例、部署配置和用户文档之间应建立追踪关系。一个需求变更应能找到受影响的设计元素、代码模块、测试用例、发布包和责任人；反过来，一个代码修改也应能追溯到需求、缺陷或变更请求。追踪关系可以使用需求管理工具、版本控制、工单系统和持续集成记录实现。

基线更新要有明确版本和时间。不能直接覆盖原需求而使历史决策消失，也不能保留多个互相矛盾的“最终版”。变更实施后，更新需求、架构、接口、数据库、测试、部署和操作文档，并通知相关人员。版本管理的价值在于可比较、可回滚和可审计。

七、需求变更的优先级和节奏

优先级可以综合业务价值、紧迫性、风险降低、依赖关系、成本、不可逆性和客户承诺判断。法规和安全修复可能优先于普通功能；架构前置任务可能优先于短期可见的页面优化；能解除多个后续依赖的变更可能具有较高优先级。

项目需要设置变更节奏。迭代项目可以在一个迭代开始前重新排列待办，已承诺的迭代中尽量保持目标稳定；传统项目可能在阶段基线和里程碑处集中处理变更。紧急故障和法规变更可以插入，但要评估挤出什么工作、对承诺造成什么影响，不能把“紧急”作为绕过所有控制的理由。

八、敏捷环境中的需求变更

敏捷并不取消变更管理，而是缩短反馈和决策周期。产品负责人维护产品待办并调整优先级，团队在迭代计划中选择可完成工作，已开始的工作尽量不被随意打断。变更进入待办后仍需澄清验收标准、估算、风险和依赖，涉及架构和质量属性的事项应由架构师参与。

敏捷团队可以采用轻量变更记录、故事拆分、影响标记、架构决策记录和自动化回归测试。对于高风险变更，需要更正式的评审、原型和发布控制。关键不是每次都开长会，而是让团队知道谁能决定、变化影响什么、如何验证和何时交付。

九、架构变更和范围蔓延

需求变更可能引起架构变更。新增一个简单报表可能只影响查询和页面；新增多租户、跨地域部署、实时风控或长期数据留存则可能改变数据模型、权限、部署、缓存和一致性策略。架构师要识别“表面小、结构大”的变化，避免被局部工作量误导。

范围蔓延是未经正式决策而持续增加需求，常表现为每个请求都很小，但累计后改变项目目标和复杂度。防止范围蔓延不是拒绝用户，而是让新增内容进入统一优先级和容量管理，明确本次迭代做什么、下次做什么、哪些不做以及为什么不做。

十、案例分析：支付平台临近上线的变更

某支付平台距离上线还有三周，业务部门提出增加分期、优惠叠加和新的第三方支付渠道。产品负责人认为这些功能能提升收入，开发团队表示“先改代码，测试以后补”，项目经理担心影响上线日期。

首先分别记录三项变更，明确业务目标、收益、截止原因、用户范围和验收标准。随后分析分期对订单、账单、还款和对账的影响，优惠叠加对规则引擎和价格计算的影响，新渠道对接口、签名、回调、密钥、对账和故障处理的影响。三项变更都可能触及支付状态机、数据模型、权限、审计和合规，不能按普通页面需求估算。

CCB 应比较方案：一是全部纳入本次上线，可能带来延期和高风险；二是只纳入监管或合同必须项，其他进入下一迭代；三是使用特性开关和灰度，让已验证能力先上线，复杂能力延后开放。若选择部分实施，应明确挤出项、测试范围、回滚方案和业务承诺。涉及支付核心状态和第三方接口的内容，应先做联调和异常演练，不能以“代码能编译”作为完成标准。

十一、常见误区

第一，需求冻结后任何变化都不能接受。冻结的意义是建立控制，不是阻止法律和业务变化。第二，需求变更只影响开发工作量。它还可能影响架构、数据、测试、部署、培训、合同和运维。第三，敏捷就是随时插入需求。迭代目标、容量、完成定义和质量底线仍需保护。第四，只记录新版本不保留旧版本。这样会丢失决策依据和审计证据。第五，所有变更都由最高领导审批。过度集中会降低效率，应按影响和风险分级授权。

十二、课后练习

练习一：单项选择

需求变更控制中最关键的活动是（ ）。

A. 立即修改代码；B. 影响分析和基于信息的决策；C. 删除原需求；D. 只统计新增页面数量。

答案：B。影响分析能揭示变更对范围、架构、质量、进度、成本和运维的影响，是批准和排期的依据。

练习二：简答题

请列出需求变更从提出到关闭的主要步骤。

参考答案：提出并记录变更请求；确认需求内容、背景、提出人和紧迫性；进行业务、架构、进度、成本、质量、测试、运维和合规影响分析；确定优先级和备选方案；由相应层级批准、拒绝或延期；更新计划和基线；实施变更并进行评审、测试和发布；验证结果，更新相关文档和追踪关系；关闭请求并复盘。

练习三：案例分析

某系统临近验收时，客户提出十项新需求，项目经理为保持客户关系全部承诺，但导致核心功能测试被压缩。请分析问题并提出改进方案。

参考答案：项目经理没有进行价值、影响、资源和风险分析，承诺改变了范围和关键路径，压缩测试会增加缺陷和验收失败风险。应逐项登记并澄清需求，识别合同或法规必需项，分析对架构、代码、数据、测试、进度和成本的影响；由业务、项目、架构、测试和客户共同评审，按优先级分批交付；保护核心功能测试和质量底线；必要时采用特性开关、灰度或延期交付，重新确认合同、里程碑和资源；所有决定记录理由、责任人和验收条件，不能用口头承诺替代变更控制。

十三、论文素材

论文可写：项目实施过程中，我建立了分级的需求变更机制。所有变更先进入统一台账，记录背景、目标、优先级和验收标准，再由业务、架构、测试、运维和项目管理人员共同分析其对范围、架构、数据、质量、进度、成本和合规的影响。小变更在授权规则内快速处理，涉及核心架构、安全和合同的变更提交 CCB 决策；批准后通过需求、设计、代码、测试和配置追踪实施，完成回归验证、灰度发布和基线更新。对紧急变更设置快速通道，但要求事后补齐证据和复盘，避免范围蔓延与无序修改。

十四、今日复盘

需求变更管理的目标是让变化可见、可分析、可决策、可实施和可验证。基线不是冻结一切，而是让后续变化有控制；影响分析要覆盖业务、架构、数据、质量、计划、成本、测试、运维和合规；CCB 应按风险分级授权；敏捷通过待办和迭代节奏管理变化，但不取消架构和质量控制。下一篇进入 5.2.3 需求追踪。