This post is about how a simple toggle button might resolve a philosophical conflict. The conflict arises from the following question: "How many directions does a trace link have?". Pop quiz!
Several standards mandate the “bidirectional traceability of requirements”*. If you take the term “bidirectional” literally, you might get to the conclusion that a trace link has two directions.
On the other hand, however, a trace link has semantics and thus must be directed. For example, imagine a link with semantics “refines” between two requirements – apparently, this link requires direction in order to distinguish the refined and the refining requirement. This discussion easily gets philosophical. If you are lost in such a philosophical discussion, a look into the “traceability bible”** might enlighten you:
- Commandment one: A trace link is a specified association between a pair of artifacts, one comprising the source and one comprising the target artifact. … [It] is effectively bidirectional. Where no concept of directionality is given or implemented is is referred to solely as an association.
- Commandment two: When a trace link is traversed from source to target, is is used in the primary direction. Where link semantics are provided, they provide a way to “read” the traversal.
- Commandment three: When a trace link is traversed from target to source, it is used in reverse direction. Where link semantics may no longer be valid.
- Commandment four: Bidirectional trace link is a term used to refer to the fact that a trace link can be used both in a primary and in reverse link direction.
Now that we are enlightened, our wisdom comprises the knowledge that answer B is correct.
A trace link has always two directions: the primary direction, which refers to the semantics of the link, and the reverse direction. And we have learned that it is the implementation, i.e. the traceability tool, that turns an association into a trace link.
YAKINDU Traceability implements this knowledge in a simple toggle button in the YT Overview. It allows you to analyze traceability either bidirectionally or unidirectionally.
Let’s consider the following traceability model, consisting of high-level requirements (HL), medium-level requirements (ML), and low-level requirement (LL):
The YT Overview shows that high level requirement HL 1 is linked to medium level requirements ML 1 and ML 2 which are both linked to low level requirements LL 1 and LL 2. One characteristic of the YT Overview is the layout of linked artifacts in the graph. It depends on the links’ primary direction: Target artifacts are always placed below source artifacts.
The bold border around ML 1 signals visually that this is the requirement of which its context is shown in the diagram. The depth is set to three, which means that all requirements which are at most three trace links away from ML 1 will be drawn. For instance, HL 2 is three links away via the chained traces “ML 1 – LL 1 – ML 2 – HL2”. Please note that this link chain is built based on link evaluations in both directions. Bidirectional evaluation is adequate for this example, but in larger projects, it may lead to confusing graphs making it hard to recognize relevant information.
Did you notice the highlighted toggle button in the toolbar above the graph? Using this button you can switch between bidirectional and unidirectional (“directed”) link evaluation. The following example shows the same graph as above, however, now the “show only directed links” option is set.
Please note that this option does not restrict links being displayed based on their primary direction only. We implemented an even smarter approach: The overview joins two different tree views into a single graph:
- The primary direction tree consists of all artifacts derived from a given artifact. Here it is the tree rooted at ML 1 containing all artifacts that are reachable via links in primary direction.
- The reverse direction tree comprise all artifacts on higher level with regards to a given artifact, here it is the tree rooted at ML 1 containing all artifacts which are reachable via links in reverse direction.
As this simple toggle can provide you with a better overview of even complex trace models, we decided to label it "Feature of the Month" for June 2017.
* CMMISM for Systems Engineering/Software Engineering, Version 1.02 (CMMISW/SW, V 1.02); CMMI Staged Representation, CMU/SEI-2000-TR-018, ESC-TR-2000-018; Continuous Representation, CMU/SEI-2000-TR-019, ESC-TR-2000-019; Product Development Team; Software Engineering Institute; November 2000
** tel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (2012). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea, eds. Software and Systems Traceability. Springer London. pp. 5-6. ISBN 9781447122388. To be honest, Gotel et al. name their definitions "definitions", not "commandments". And, by the way, they don't name their work "bible".
Comments