Draft QNX restriction documentation

[aschemmel-tech]

No description provided.

[github-actions]

⚠️ Docs-as-Code version mismatch detected
Please check the CI build logs for details and align the documentation version with the Bazel dependency.

[github-actions]

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

[ANegm-ETAS]

This is a helpful addition but it raises a question:

The process describes linking Assumptions of Use (AoUs) to architecture elements to show compliance. This works well for positive requirements, but a significant number of restrictions in the QNX safety manual are negative—they prohibit the use of certain functions.

How, then, should a feature team 'link' the absence of a forbidden function to an architecture element to demonstrate compliance?

[aschemmel-tech]

This is a helpful addition but it raises a question:

The process describes linking Assumptions of Use (AoUs) to architecture elements to show compliance. This works well for positive requirements, but a significant number of restrictions in the QNX safety manual are negative—they prohibit the use of certain functions.

How, then, should a feature team 'link' the absence of a forbidden function to an architecture element to demonstrate compliance?

Let's for example have an AoU like "the component shall not use exceptions". By linking this to the component you confirm that you did some check to prove this, for example run a test/chek-script or do a manual code analysis.

[ANegm-ETAS]

Let's for example have an AoU like "the component shall not use exceptions". By linking this to the component you confirm that you did some check to prove this, for example run a test/chek-script or do a manual code analysis.

so in this example, Are we expecting all architecture elements in all components to link to this AOU and create a test case for them as well ?

[aschemmel-tech]

Let's for example have an AoU like "the component shall not use exceptions". By linking this to the component you confirm that you did some check to prove this, for example run a test/chek-script or do a manual code analysis.

so in this example, Are we expecting all architecture elements in all components to link to this AOU and create a test case for them as well ?

To be precise: all architecture static views of all the components. But there is an alternative to this: we can also link to an existing requirement or we cover the AoU by e,g, a coding guideline entry (without linking, but by adding a comment in the description). The most efficient way of course would be to write a static code analysis check to cover this for all components at once.

[ANegm-ETAS]

so in this example, Are we expecting all architecture elements in all components to link to this AOU and create a test case for them as well ?

To be precise: all architecture static views of all the components. But there is an alternative to this: we can also link to an existing requirement or we cover the AoU by e,g, a coding guideline entry (without linking, but by adding a comment in the description). The most efficient way of course would be to write a static code analysis check to cover this for all components at once.

we actually looked into creating a static analysis check for QNX restrictions and although it's technically possible according to legal we can only do so without allowing any direct inference of the restrictions (no one should be able to use the tool to reverse engineer the qnx safety manual) and Only violations may be reported , so no explanation of the rule violation either .

we could cover the AoUs by a coding guideline but wouldn't the coding guideline here consist of the restriction list similar to the AoUs themselves . Would linking the AoUs to the Implementation checklist be acceptable coverage