Generation of traceability matrices

[stanislaw]

This ticket will probably not be worked before 2023-Q2, so here are only initial thoughts only:

• It has to be configured which documents should be calculated against which documents.
• The configuration can happen statically in the strictdoc.toml or dynamically in the UI.

[elfman2]

Interrest in matrices generated with export --formats rst

[stanislaw]

Adding input from one user on this traceability matrices topic. The context of the following considerations is the DO-178C aviation standard.

Input from a user

Trace has the following objectives:

• demonstrate that all requirements is covered by implementation
• demonstrate that there is not any unspecified code
• demonstrate that all requirements are tested
• demonstrate that all derived requirements are analysed by safety assessment.

A system is usually composed of several functions: 1 sdoc file per function. Functions are allocated to several software/ hardware components through a system design document, which also allocates design assurance level to these components. A software component is specified with HLR (high level requirements), then software design specifies software architecture and low level requirements.

• All HLR shall be covered by at least one LLR
• Any HLR shall refine a system requirement, else the HLR is "DERIVED" and shall be assessed by safety
• Any LLR shall refine a HLR, else the LLR is "DERIVED " and shall be assessed by safety
• All LLR shall be implemented by source code
• All HLR and LLR shall be covered by a test. HLT (high level tests) are testing HLR, LLT are testing LLR (unit tests).
• There shall not exist any unspecified code nor untested code/requirement, and therefore no dead code.

In addition to these objectives, there is some industrial/economic will to optimise change request management. Upon some system requirement change request, the applicant shall perform an impact analysis to determine the artefacts which shall be modified (requirements, code, test procedure, test results) in order to assess the new baseline against DO178 objectives.

Technical consideration: All artefacts shall remain readable/modifiable during more than 50 years (ex: https://fr.m.wikipedia.org/wiki/Sud-Aviation_SA330_Puma). That's why the artefact data format shall be text or pdf. The legacy solution is to store on pdf documents several matrices to achieve DO-178 objectives.

A trace matrix is a 2 column table:

1/ SYS-REQ,HLR 2/ HLR, SYS-REQ 3/ HLR, LLR 4/ LLR, HLR 5/ LLR, code source unit 6/ CSU, LLR 7/ HLT, HLR 8/ HLR, HLT 9/ LLT, LLR 10/ LLR, LLT

Until today, the relationship between the applicant and the certification authority is based on the sharing of the pdf artefacts, plus some on site audit of the source code and test case.

This is not convenient for engineers to use pdf on every day job, and it is also not convenient for the authority to navigate across tens of pdf. Matrices are a way to identify uncovered items in a twinkling of an eye, and to navigate in pdf. They are the entry point to conduct an audit.

But there might be other clever ways to comply to the objectives I first described.