Documents Comprising the Certification Package:
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.
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]
The UID fields are as follows:
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).
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.
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 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.