It doesn’t take much to remember a time you wish you had “looked before you leaped.” The time you bought furniture that would not fit through the doorway, or the small tree you planted whose roots are now cracking through the sidewalk. Don’t you wish you had given more thought to these changes and their effects BEFORE they were implemented? Well, an impact analysis can help.

An impact analysis is a systematic approach for evaluating changes to a system. It looks at the new feature, enhancement, or problem to be fixed, the underlying reason for change or root cause, and the proposed solution in terms of the existing system and its constraints and requirements. It is part of an overall modification process and provides justification for or against the change. Much meaningful investigative work for changes is simply discarded or forgotten because it is not written down. This is a more formal way of documenting the discussions and informal reviews that take place to provide traceability for audits. Any system change has the potential to affect at least some documentation. Keeping records for the change itself is one thing, but design and requirements documents may also need changes. For complicated changes the impact analysis can be a separate document; for simple changes it can be incorporated into change tracking documentation. While the focus of the impact analysis in IEC 61508 is on software changes, there is no reason not to extend an impact analysis to other types of system changes.

• How was the problem revealed?
• Why is the enhancement important?
• What product or release versions are affected?
• Is the problem safety-critical?
• What modules are affected? Are safety-critical modules affected?
• Do we inform customers?
• Does this change affect future hardware/software compatibility?
• What other functionality might these changes affect?
• Is there any Testing impact? Regression test or validation test changes?
• Where in the lifecycle process should work start? (Or, to what lifecycle stage should we return to fix a problem?)

• Describe the feature or problem, and then the effect on system/product
• Describe the root cause of the problem (not just a quick patch); keep asking “why it happened” until you get to the root
• Describe the solution, and then the effect of solution, especially any interfaces or connected functions/issues
• Determine the earliest lifecycle phase where changes apply

3/7.1.2.9- If at any phase of the software safety lifecycle, a modification is required pertaining to an earlier lifecycle phase, then an impact analysis shall determine (1) which software modules are impacted, and (2) which earlier safety lifecycle activities shall be repeated.

3/7.5.2.6- During the integration testing of the safety-related programmable electronics (hardware and software), any change to the integrated system shall be subject to an impact analysis. The impact analysis shall determine all software modules impacted, and the necessary re-verification activities.