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.

NOTE: This is just a preview. The complete QP Certification Pack can be requested from Quantum Leaps.

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 item 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.

Upstream Traceability

Upstream traceability begins at a specific work item 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 items were created and how different pieces of a system fit together. Tracing in this way also allows testers to find gaps or missing work items.

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 items 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 (e.g., @tr{RQP103} or @tr{AQP202}) inside the doxygen comments in the code. All these "trace records" are then listed separately in the Traceability Report.

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.

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

Traceability Report

NOTE: This is just a preview of the QP Certification Pack. The links to actual requirements are provided in the complete document, which can be requested from Quantum Leaps.

File qep_hsm.cpp

traces to: RQP103

traces to: RQP104

traces to: RQP120

traces to: RQP130

Member QHsm::dispatch (QEvt const *const e, std::uint_fast8_t const qs_id)

traces to: RQP103

traces to: RQP120A

traces to: RQP120B

traces to: RQP120C

traces to: RQP120D

traces to: RQP120E

traces to: RQP120A

traces to: RQP120E

traces to: RQP120C

traces to: RQP120B

traces to: RQP120I

Member QHsm::hsm_tran (QStateHandler(&path)[MAX_NEST_DEPTH_], std::uint_fast8_t const qs_id)

traces to: RQP103

traces to: RQP120E

traces to: RQP120F

Member QHsm::init (void const *const e, std::uint_fast8_t const qs_id)

traces to: RQP103

traces to: RQP120I

traces to: RQP120D

Member QHsm::isIn (QStateHandler const s) noexcept

traces to: RQP103

traces to: RQP120S

Member QHsm::QHsm (QStateHandler const initial) noexcept

traces to: RQP103

Member QHsm::top (void *const me, QEvt const *const e) noexcept

traces to: RQP103

traces to: RQP120T

Member QMsm::childStateObj (QMState const *const parent) const noexcept

traces to: RQP103

traces to: RQP120H