Robot Change Impact Assessment: Pre-Change Analysis Guide

A complete change impact assessment covers three dimensions of the proposed change's potential effects. The functional impact dimension asks which functional capabilities of the deployed robot might behave differently after the change. A change to the navigation firmware may affect navigation accuracy, obstacle avoidance, and path planning; a change to the application logic may affect task selection, workflow handling, and error recovery.

The acceptance criterion impact dimension maps the identified functional impacts to the specific acceptance criteria that verify those functional capabilities, identifying the criteria that should be retested. The operational risk impact dimension assesses the potential consequences if the change produces an unexpected behavioral regression in the identified functions: the safety implications, the operational disruption, the warranty implications, and the customer communication requirements.

The assessment should be specific and should reference the acceptance test set and acceptance criteria for the deployment being assessed, not generic checklists that may not match the specific deployment's requirements.

A change impact assessment requires three types of input information to produce a useful output. The change description must specify exactly what is changing: the specific component, the specific version change, and the description of what was modified in the change. Vague descriptions like 'firmware update' without version numbers or change notes are insufficient inputs for a meaningful assessment.

The acceptance test record must be available for the assessor to review, because the impact assessment maps the change description to the specific acceptance criteria - without knowing what criteria were tested and what they test, the mapping cannot be made. The technical specification of the changed component must be available for comparison with the previous version's specification, so that behavioral differences enabled by the change can be identified from the specification rather than only from the change notes.

Where change notes are incomplete or unavailable, the technical specification comparison is the primary source for assessing potential behavioral impact.

The documented output of a change impact assessment should cover the change being assessed, the functional impacts identified, the acceptance criteria mapped to those impacts, the recommended retesting scope with rationale for each included and excluded criterion, and any operational risk considerations that the change introduces. For each acceptance criterion in the recommended retest scope, the documentation should note the reason the criterion was included: which specific aspect of the change description or technical specification difference suggests a potential behavioral impact on that criterion.

This criterion-level rationale documentation is what allows a reviewer to assess whether the retest scope is appropriate - whether criteria were included for substantive reasons or excluded without adequate justification. The assessment should be dated, should identify the assessor, and should be reviewed by the deployment lead before the change is applied, so that the assessment quality is reviewed before the deployment is committed to the retest scope it specifies.

The retest scope recommendation from the impact assessment is the input for the retest plan, but it is not necessarily the final scope. The deployment lead reviewing the assessment may identify additional criteria that the assessor did not consider, or may determine that some criteria in the assessment are included at a level of precaution that exceeds what is operationally necessary for the specific change. The final retest scope determination should be documented as a decision that references the assessment recommendation and any deviations from it, with the rationale for the deviations.

Where the deployment lead reduces the assessment's recommended scope, the rationale should be specific: not 'scope reduced to save time' but 'criterion X excluded because the change does not affect the subsystem it tests, and the assessment recommendation appears to have been over-inclusive for this criterion because of Y.' This documented scope decision is part of the change management record and may be referenced if a post-change behavioral issue arises in a criterion that was excluded from the retest scope.

Deployment teams that make change impact assessment a routine part of every change event, regardless of the apparent significance of the change, develop a discipline that benefits the entire deployment lifecycle. Routine assessments build the team's familiarity with the deployment's acceptance criteria and their dependencies on the system's components, which improves the quality of each assessment over time. The documented history of assessments provides a reference for future assessments of similar changes: if a previous assessment of a navigation firmware update identified specific criteria that were and were not affected, a future assessment of a similar update can reference the previous one as a starting point.

Over time, the assessment record also reveals patterns in which changes have the most acceptance impact, which can inform prioritization of maintenance and update activities and can identify components whose changes consistently require significant retesting as candidates for more robust change control processes.

• Obtain the complete change description including specific component, version change, and change notes before beginning the assessment
• Review the acceptance test record for the deployment as the mapping reference for the assessment
• Identify functional impacts from the change description and map them to specific acceptance criteria
• Document the rationale for each criterion included in or excluded from the recommended retest scope
• Include operational risk considerations in the assessment, noting safety, warranty, and customer communication implications
• Have the impact assessment reviewed by the deployment lead before the change is applied
• Preserve the impact assessment document linked to the change record and the subsequent retest evidence