变更影响分析是变更控制的重要一环。要做好变更控制，首先要做好变更影响分析。而常见的做法是，分析变更影响到的工作制品，变更是否会影响到项目进度。这里的工作制品指的是代码、文档。
比如说，在测试阶发生了需求变更，分析受影响的工作制品就包括需求规格说明、设计说明、代码、测试文档等。只要在这些工作制品和变更的需求相关，就要对其实施变更。
对工作制品的影响分析，这样做就够了吗？当然不够。
如果说变更的需求是独立的，那么这样的变更需求分析是不会有什么遗漏了，可是，现实当中这种情况几乎是不存在的。首先，需求很难是独立的，一些需求之间总会有割舍不断的耦合性。其次，在将用户需求分配给产品需求时，要考虑结构化设计，要考虑重用构件，所以需求分配不会一对一的，软件模块的设计和产品需求之间也不会是一对一的，后期的测试用例和代码模块之间也不是一对一的。就像下图所示。
假设上图中的C点发生变更，那么首先要做的就是修改需求规格说明中此一需求，其次就是溯源而上，分析这一需求的改变是否影响其源头的用户需求。如果源头的用户需求受到影响，就要分析由它分配的另外的软件需求是否受到影响，继而再继续分析受影响的软件需求的变更是否会影响后续的设计、测试用例等。
所以说，变更影响分析，不仅要分析工作制品，更重要的是要分析到制品中的模块层次——需求模块、设计模块、代码模块、测试用例等。而模块层次的影响分析是否彻底，取决于需求跟踪矩阵是否清晰。
说句题外话，需求跟踪这一实践，在很多组织都被忽视了。有的组织虽然引进了先进的需求管理工具DOORS，但却只是把它当成了一种精美的装饰物，变更分析的时候就把它抛之脑后；有的组织就用文档模版中的需求追溯章节作为需求跟踪的实现，全然不顾其中的章节条目和需求的关系并没有那么清楚，变更分析的时候也不会有人看这些追溯关系。
要做好变更影响分析，建立起一个清晰明了的需求跟踪矩阵是基础。变更影响分析，分析的就是从需求到设计、实现、测试的相互关系。
微信号：IdeaofSE
联系客服
