软件设计模式与架构解析
1. 变更控制
在遵循严格文档原则的系统中，通常不允许频繁更改需求。过去，这常常导致“范围蔓延”现象，即项目从一个简单的设计开始，最终却变得极其复杂，严重超出预算和时间。例如，原本只是设计一个简单的电灯开关，最后却变成了一个运行的核电站项目。
为避免这种情况，在需求和设计文档完成并批准后，任何需求或设计实现的变更都必须遵循正式的变更控制流程。这并非阻止系统变更，而是对其进行适当分析和记录，同时也有助于限制“范围蔓延”。若变更未经过妥善审查和记录，可能导致项目延迟或实施不当。通过该流程，有些变更可立即实施，有些则可指定为产品未来版本的需求。
不同组织处理变更控制的政策和文档记录方式各不相同，有的使用邮件记录，有的采用“迷你业务需求文档（BRD）/功能规格文档（FSD）”结构，还有的会根据变更的严重程度将两者结合使用。理想情况下，所有变更都应遵循同一系统。
以考勤卡项目为例，假设业务需求文档（BRD）和功能规格文档（FSD）已完成并批准，且实际编码工作已经开始。业务分析师在审查文档和遗留系统的当前实践后，向开发团队提出有一个场景被遗漏，可能会稍微改变流程。新需求是“团队负责人可能需要代表团队成员完成并批准考勤卡”，这就需要创建一个变更请求（CR），将这个新需求作为变更控制流程的一部分进行正式记录。
为便于清晰记录和跟踪，每个变更请求应记录在一个单独的文档中。与需求一样，CR有唯一标识符和简要描述。由于变更请求是在设计完成和编码开始后提出的，在将新需求纳入实施之前，需要考虑更多问题和因素。以下是一个示例CR文档：
| ID | CR - 100 |
| — | — |
| Issue | 新需
