变更无处不在，其含义有业务维度和系统维度的阐述。
- 变更管理的业务方面更强调与新信息系统相关的变更行为和组织影响.
- 变更管理是管理软件产品和过程以及管理软件系统演化过程中的团队活动的过程，以系统合理性为目的。
质量控制需要找出需要进行修正的故障。为了得到修正，必须将这些故障提交变为变更请求，然后分配开发人员。
有些变更请求不是故障，而是改进。故障和改进都需要经历状态变化，都可能要进行排序，都有所有者，都需要追踪到它们在测试文档和用例文档中的起源。
要管理变更，就需要相应的变更请求管理工具。
可追踪性是测试与变更管理的基础，其目的是捕获、链接、追踪每一个重要的开发制品，包括需求。
可追踪性的最终目的是保证整个文件集中各种文档和模型的正确性和一致性，如从需求文档到技术文档，再到用户文档。
追踪的条目可以是文本描述或图形模型。可追踪性在这些条目之间建立了外部连接，这些连接可能是直接的或间接的。如果修改了追踪路径上的任何条目，那就可以对连接进行影响分析。
可追踪性、测试和变更管理经常与用例需求中列出的系统服务相关，而系统约束的实施也需要进行测试和管理。
可追踪性、测试和变更管理本身不是目的，不必过于强调，开发者的注意力应该集中在开发上。关注这些问题会显著增加项目成本，但不管理这些问题又会显著地增加项目的长期成本。
由于可追踪性是质量与变更管理的基础，所以应该采用成本-效益分析来确定项目追踪的范围和深度。
至少应该保证用例需求和故障之间的可追踪性，更复杂的模型还会有更复杂的可追踪性关系。
业务用例文档中列出了系统特征。测试计划文档确定了测试用例。特征与测试用例和用例文档中的用例需求连接。测试用例文档中的测试需求可以追踪到测试用例和用例需求。测试需求与故障连接，改进与用例需求连接。故障与改进之间不需要追踪。
追踪包括：
- 从系统特征到用例和用例需求
- 从测试计划到测试用例和测试需求
- 从UML图到文档和需求
- 从用例需求到测试需求
- 从测试需求到故障
- 从用例需求到改进