Add framework for trainings and an example training#742
Conversation
|
The created documentation from the pull request is available at: docu-html |
|
@MaximilianSoerenPollak , any news from infrastructure team discussion, how to continue with the training framework? |
Sorry I completely lost this out of sight. |
|
@masc2023 we have talked about it. We think it can stay here in this repo, we will look through the python code and support on it to make it more robust in some ways. |
PandaeDo
left a comment
There was a problem hiding this comment.
Just some first thoughts on it. I tried the test out yesterday. To be honest it was very hard to read and the questions I had were not really helpful in the meaning to ensure knowledge. I was asked two times for things that are implemented in the metamodel and which are not really necessary to ensure the process.
Is there a reason why we change the style in the pages? Also it's a little bit hard to read with orange, green on violet. Could be my setup but why not using the same style as in the process description?
At the end I would prefer to spend some time in the training to bring it to the point what we want to archive. Maybe also with different aspects regarding different roles.
| <ol> | ||
| <li><strong>No agreed specification</strong> — contributors implement different interpretations | ||
| of the same need.</li> | ||
| <li><strong>No audit trail</strong> — safety and security auditors cannot verify that every |
There was a problem hiding this comment.
Would prefer arguments in the direction that we want to ensure safety. For others and even as a contributor for our self’s. As a user of a vehicle which runs safety critical software and as a pedestrian.
The motivation to archive that is in my opinion much more higher then to create documents for some auditors.
| standard requirement is addressed.</li> | ||
| </ol> | ||
| <div class="callout important"> | ||
| <div class="callout-label">Why RE is Mandated by Standards</div> |
There was a problem hiding this comment.
| <div class="callout-label">Why RE is Mandated by Standards</div> | |
| <div class="callout-label">Why Requirements Engineering is Mandated by Standards</div> |
Don't like abbreviations like that especially when it's AI generated so that there is no additional effort for the author. But it's harder to read for humans.
| <div class="callout-label">Why RE is Mandated by Standards</div> | ||
| <p>ISO 26262 (Part 8, SWE.1), ASPICE PAM 4.0, ISO/SAE 21434, and ISO PAS 8926 all | ||
| iltiyexplicitly require a documented, traceable requirements hierarchy as a precondition | ||
| for safety and security releases. Without it, certification is impossible.</p> |
There was a problem hiding this comment.
For my opinion again, certification is a weak argument. Would replace it like above to motivate everyone who is contribution to a safety critical software by intrinsic goals.
| to both problems: a hierarchy of requirement levels with defined attributes, | ||
| mandatory reviews, and automatic traceability links to code and tests.</p> | ||
| <h2>1.2 Stakeholders and Their Information Needs</h2> | ||
| <p>The requirements hierarchy must satisfy the needs of every stakeholder who will |
There was a problem hiding this comment.
Sure that the "requirements hierarchy" must satisfy the following needs?
| <td><strong>Project Lead</strong></td> | ||
| <td><code>rl__project_lead</code></td> | ||
| <td>Defines platform specification and content, creates project timeline, tracks project progress</td> | ||
| <td>Clear stakeholder requirements as a project description</td> |
There was a problem hiding this comment.
Would guess that's not the only aspect that they need.
| <tr> | ||
| <td><strong>SW Architect</strong></td> | ||
| <td><code>rl__committer</code></td> | ||
| <td>Breaks down platform specification into features, derives feature/component architecture, allocates requirements to architecture elements, defines AoUs from architecture</td> |
There was a problem hiding this comment.
What about component architecture?
| <tr> | ||
| <td><strong>Tester</strong></td> | ||
| <td><code>rl__committer</code></td> | ||
| <td>Verifies that the specification is satisfied by the elements under test, considers AoUs for test case specification</td> |
There was a problem hiding this comment.
In general it's seems to me that the descriptions don't really fit to "what they need form requirements"
| </tbody> | ||
| </table> | ||
| <div class="callout tip"> | ||
| <div class="callout-label">Open Source Working Mode</div> |
There was a problem hiding this comment.
This could also be an argument why we need requirements engineering. After the table it's a little bit lost and not the place where I would expect it.
A training framework is added, to allow generation of S-CORE specific trainings materials.
An example training is added for requirements engineering