Fix Safety Analysis Audit findings

[aschemmel-tech]

Not started:

• - 6-7.4.10 --> Safety Analysis will be rolled out

• - 6-7.4.11 --> Safety Analysis will be rolled out

• - 6-7.4.12 --> Safety Analysis will be rolled out

• Action_72: The Confirmation Review checklists need to refer to ISO-26262. @aschemmel-tech remark: please do this for the safety_analysis_checklist similar to what was done for safety plan and safety package FDRs in Link FDR templates to Iso 26262 #587
  Solved with Fix Safety Analysis Audit findings #591

• Action_73: The failure mode EX_01_01 defines the internal execution failure (wrong calculation) but refers to message loss / corruption. It shall be explained that this failure mode (wrong calculation) is related to the analysis if e.g. internal safety mechanisms are required (level 2 function, plausibility check of the output, …) because of the size / complexity of the feature. If only testability is defined as mitigation measure, complexity requirements shall be allocated to the feature.
  Solved with Fix Safety Analysis Audit findings #591

• Action_64: For Persistency: The first assumption (handle the unavailability of persistency) and the third assumption (the application may not block persistency (make it available) are inconsistent. - @aschemmel-tech comment: while this was discovered during the audit of requirements process, the root cause lies within the safety analysis. Need to consider changing the safety analysis of persistency to be able to modify also the AoU requirements https://eclipse-score.github.io/score/main/features/persistency/requirements/index.html#aou_req__persistency__error_handling and/or https://eclipse-score.github.io/score/main/features/persistency/requirements/index.html#aou_req__persistency__appl_exec