Improvement: Add illustration to impact analysis process req

[aschemmel-tech]

No description provided.

[github-actions]

The created documentation from the pull request is available at: docu-html

[aschemmel-tech]

Please also add your ideas/comments of how the output result of the tool should look like (e.g. just a list of work products or an attribute filled for each work product). Likewise how we use it, e.g. only in a PR and/or standalone with UIDs as input values.

[masc2023]

Please also add your ideas/comments of how the output result of the tool should look like (e.g. just a list of work products or an attribute filled for each work product). Likewise how we use it, e.g. only in a PR and/or standalone with UIDs as input values.

Propose to modify the image in the following way, just binary color-code, work products to be covered for impact analysis or not

Further to add an example, how it could work iteratively

Assuming applied the tool during an PR.
Compare also https://github.com/eclipse-score/process_description/blob/4a53e42cfc72927631606bbc7c744d5473b8d5ef/.github/ISSUE_TEMPLATE/3-change.yml
will introduce a light-weight impact analysis, so the impact analysis tool could be used only during PR

[aschemmel-tech]

• I think the picture on iterative following the links is helpful and I will add.
• But I am not happy with the removal of direction. I do not think for example that when a Safety Analysis is updated (for example if during a review an additional failure mode is found) this has any impact on the Architecture. But the other way round it may have. Just to focus on the real impact.

[pahmann]

After reading through the simplified view from Markus, and reading the comment on it from Alexander, I start understanding the original picture properly. It took me roughly 3 attempts to get an understanding. As this is a requirement put to the later tooling, I wonder, if the requirement may be to complex to treat. Maybe bring the original picture as proposed by Alexander combined with the example and visualizing the example can create clarity.

Phrasing an explicit statement in the requirements text that the tests do not need to be treated, will be a value add. I remember that in an audit it was mentioned that the illustrations are a support of the textual description, but with the explanations in the figure information is created, which is not in the text.

[pahmann]

See my separate general comment.
Actions:

• The requirement should mention the role of testing/verification items. The "not needed, ..." - in the illustration also has to be stated as explicit text.
• The drawing needs an example for clarity as proposed by Markus

[pahmann]

@aschemmel-tech your latest changes combining text and illustrations help me a lot for a better understanding. Thank you so much. My findings are addressed.