Tracker Relations
Codebeamer organizes tracker items by placing each item in exactly one tracker, which then acts as the container of that items.
But items don't need to exist in complete isolation though, they can have relations to other items in other trackers, even other projects.
Relations are critical for managing, auditing and tracing back changes.
For example, you can trace back which tasks were triggered by which requirements. Then when you also associate your code changes with these tasks, you can take traceability to the next level: you will be able to easily tell which requirements resulted in which source code changes! (see Tracing Source Code Changes to Requirements, Task and Bugs).
 |
Watch a video on tracker relations here.  |
There are two types of relations between tracker items:
• References and
• Associations.
References
References are relations bound to Reference Fields of tracker items (see Creating and Customizing Trackers).
• can be required/mandatory
• can refer to multiple items
• can refer to items from multiple target trackers
◦ even from trackers in other projects
• can refer to a specific subset of target tracker items (via a filter or view)
The Name of a reference field is synonym for the relation between referring item and reference field values, or in other words, the function or role, that the referring item plays for the reference field values (or vice versa). E.g.
• A Test Case Verifies a Requirement
• The Subject to be approved by an approval Task.
The Cardinality of references can be configured to be
of references can be configured to be• 0..1 if the field is not mandatory and only allows a single value
• 1 if the field is mandatory and only allows a single value
• 0..* or * if the field is not mandatory and allows multiple values
• 1..* if the field mandatory and allows multiple values
• x..y where x and y are the Minimum and Maximum number of values of the reference field.
You can also define Constraints between reference fields (of the same tracker), e.g.
between reference fields (of the same tracker), e.g.• If field A refers to an item of tracker X
• Then field B must refer to an item of tracker Y
• Where the item in B must refer to the item in A via the reference field C (of tracker Y)
See Dynamic pick-list fields for more information about: Dynamic/Relation based dependencies between reference fields.
The
• and Reference
Relations between trackers can also be visualized as a diagram by clicking on Configuration Diagram on the Trackers page:
In the diagram:
• Trackers are shown as nodes
• Inheritance is shown as blue Generalization arrows from the derived tracker to the template tracker
• References are shown as light blue arrows from the declaring reference field to the target trackers
We can change the visibility of trackers on the left tree by clicking on trackers.
The selected tracker list is saved, so when the configuration diagram is opened again then the last saved selected tracker list is displayed.
References can be used to
• find/filter items referring to/referenced by other items in
Depending on the current point of view (Tracker), References can be
• Upstream or
• Downstream.
Upstream References
Upstream references are defined by reference fields in the current tracker.
Downstream References
Downstream references are defined by reference fields of other trackers referring to the current tracker.