Remarks: This document is part of the QP Certification Pack, which has been specifically designed to aid companies in safety certification of their software based on the QP real-time embedded frameworks.

Documents Comprising the Certification Package:

Traceability

Traceability enables product teams to associate a specific work artifact (e.g., a specific requirement) with all the related project artifacts, both upstream and downstream, so that anyone can see how the work artifact relates to the requirement—and vice versa—at any point during development. This functionality, also called live traceability, fosters team collaboration and enables early detection of possible production risks.

Unique Identifiers (UIDs)

The cornerstone of traceability is the consistent use of Unique Identifiers (UIDs), which are short text labels associated with all work artifact, such as requirements, architecture elements, design elements, tests, etc.

The most important feature of UIDs is their uniqueness within the whole system under consideration. To avoid name conflicts, it is advantageous to establish general rules for constructing the UIDs. In this QP Certification Pack, the UIDs have the following general structure:

+---------------- 1. work artifact class ('R' for Requirement, 'A' for Architecture, etc.)
| ++------------- 2. Project Unique Identifier (here 'QP' or 'QA')
| || +----------- 3. one-digit feature number
| || | ++-------- 4. two-digit work artifact number (e.g., Requirement number)
| || | ||  +----- 5. optional sub-section letter (A, B, C...)
| || | ||  |
R QP x yy [A]

Examples: RQA001, RQP002B

The UID fields are as follows:

the UID starts with a letter corresponding to the class of the work artifact:
- R Requirement
- A Architecture artifact
- D Design artifact
- P Deviation Permit (e.g. for MISRA violation)
- T Test
the Project Unique Identifier (PUI), which is 'QP' for the QP Framework and 'QA' for QP Application. The PUI avoids name conflicts with other software components in a larger system
the PUI is followed by a 2-digit feature number
this is followed by a 2-digit requirement number
optionally, the requirement might end with a letter ('A', 'B', 'C',...), which identifies a sub-requirement of a given requirement.

Note: As long as the UIDs remain system-wide unique, the general UID structure outlined above can be slightly modified and adapted to the specific classes of UIDs. For example, the class of "Deviation Permits" for coding rule violations could use the already unique rule numbers instead of the 2-digit "work artifact number".

Attention: For technical reasons of generating cross-reference in this documentation system, the UIDs can consist of only letters, digits, or underscore and special characters are NOT allowed.

Upstream Traceability

Upstream traceability begins at a specific work artifact and links it to the original artifact. For example, architecture element can be linked with an original requirement. Upstream traceability gives visibility into why specific artifacts were created and how different pieces of a system fit together. Tracing in this way also allows testers to find gaps or missing work artifacts.

Upstream traceability is the most efficient way of specifying hierarchical relationships, such as superclass-subclass in OOP. Class inheritance is universally represented in the subclasses, which store their superclass (upstream traceability). In contrast, superclasses don't show their subclasses (downstream traceability). The QP Certification Pack generalizes this approach to all work artifacts, starting with the requirements at the top, through architecture, design, source code, tests, etc.

As illustrated in the diagram below, upstream traceability is provided explicitly in the Certification Pack and QP source code. Specifically, the downstream work artifacts provide trace information to the related upstream artifact by means of Unique Identifier (UIDs).

Schematic View of Upstream Traceability in QP

Note: The QP Certification Pack traceability system is its full integration with the source code. This is achieved by placing special traceability links, such as @tr{RQP103} or @tr{AQP202}, inside the doxygen comments in the code.

Downstream Traceability

Downstream traceability begins at the original artifact and links it with all the resulting downstream work items. For example, a requirement can be linked with source code elements that implement that requirement. This type of trace ensures that each original artifact (e.g., requirement) is not only satisfied but verified and validated.

Note: Downstream traceability allows the teams to perform impact analysis to identify the potential consequences of a change of a given artifact.

In the QP Certification Pack, the downstream traceability can be achieved quite simply by automatically searching the project for the UID of the specific work artifact. For example, the following grep command shows the downstream traceability for the requirement RQP103.

C:\qp\qpcpp>grep -r -n tr{RQP103} ../cert-pack . --exclude=3rd_party
../cert-pack/sas.dox:86:@tr{RQP003} @tr{RQP103}
../cert-pack/sas.dox:95:@tr{RQP101} @tr{RQP102} @tr{RQP103} @tr{RQP120}
./include/qep.hpp:244:* @tr{RQP103}
./include/qep.hpp:521:* @tr{RQP103} @tr{RQP120E}
./include/qep.hpp:532:* @tr{RQP103} @tr{RQP120H}
./include/qep.hpp:543:* @tr{RQP103}
./include/qep.hpp:552:* @tr{RQP103} @tr{RQP120B} @tr{RQP120C}
./src/qf/qep_hsm.cpp:32:* @tr{RQP103} @tr{RQP104} @tr{RQP120} @tr{RQP130}
./src/qf/qep_hsm.cpp:137:* @tr{RQP103}
./src/qf/qep_hsm.cpp:164:* @tr{RQP103} @tr{RQP120I} @tr{RQP120D}
./src/qf/qep_hsm.cpp:259:* @tr{RQP103} @tr{RQP120T}
./src/qf/qep_hsm.cpp:282:* @tr{RQP103}
./src/qf/qep_hsm.cpp:460:* @tr{RQP103}
./src/qf/qep_hsm.cpp:624:* @tr{RQP103}
./src/qf/qep_hsm.cpp:673:* @tr{RQP103}

Bidirectional Traceability

Bidirectional traceability is the ability to perform both downstream and upstream traceability. Bidirectional traceability is the optimal type of traceability because it gives teams full visibility from requirements through architecture, design, source code, tests, and back again. The system implemented in the QP Certification Pack provides such bidirectional traceability.

Remarks: The whole system of traceability offered in QP is extensible and it is highly recommended that the QP Applications adopt it as well.

Requirements (SRS)