Tracker Relations
Codebeamer organizes tracker items by placing each item in exactly one tracker, which then acts as the container of that item.
However, items don't need to exist in complete isolation, they can have relations to other items or projects in other trackers.
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 can easily identify which requirements resulted in which source code changes (see Tracing Source Code Changes to Requirements, Task and Bugs).
There are two types of relations between tracker items:
• References
• Associations
References
References are relations that are bound to reference fields of tracker items (see Creating and Customizing Trackers).
Reference fields are similar toForeign Keys
in Relational Databases, and have the following properties:
in Relational Databases, and have the following properties:• Can be required or mandatory
• Can refer to multiple items
• Can refer to items from multiple target trackers, including trackers in other projects
• Can refer to a specific subset of target tracker items (using a filter or view)
The name of a reference field is a synonym for the relation between the 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). For example,
• A test case verifies a requirement
• The subject to be approved by an approval task.
You can configure the Cardinality of references as follows:
of references as follows:• 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).
between reference fields (of the same tracker).For example:
• 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 using the reference field C (of tracker Y)
See Dynamic pick-list fields for more information about dynamic or relation-based dependencies between reference fields.
• To visualize the Tracker Inheritance and reference relations between trackers as a diagram, click Configuration Diagramon 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.
You can click the trackers in the left pane to change their visibility.
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 for the following:
• Find or filter items referring to or referenced by other items in Tracker Views
Depending on the current point of view (tracker), references can be one of the following:
• 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.