Trace Relationships in Content Versions
A trace relationship is a special directional dependency that relates two documents or content items. For example, a trace relationship between a requirement and the test case that validates it. Fundamentally, there are two types of trace relationships: downstream and upstream.
A Downstream Traces is a trace relationship that originates from a generic element and goes to a more specific element. For example, a Downstream Traces from a component level requirement to one of the test cases that verifies the requirement. In Windchill RV&S, a Downstream Traces is denoted by a forward relationship.
An Upstream Traces is the reverse of the Downstream Traces. An Upstream Traces originates from a more specific element and goes to a more generic element. For example, an Upstream Traces from a component level requirement to the system level specification document that it was derived from. In Windchill RV&S an Upstream Traces is denoted by a backward relationship.
|
Trace relationships are configured by your administrator.
|
To create a trace relationship, you only need to specify the start and end points of the relationship. Provided the trace relationship has been configured by your administrator, the specific relationship is then created automatically. For more information on trace relationships, see
Managing Trace Relationships.
A live document is the originating document that is used to create a version (using a check-in operation). A live document and its contents can be changed throughout its lifecycle.
A
document version represents the structure of the document and its contents at a specific point in its history. A content version is an artifact that represents a record of the content item at a specific point in its history. While a live document can continue to evolve, once a version is created, the significant content of that version cannot be changed. For more information on versioning, see
Creating a Document Version.
When checking in content, trace relationships are not handled in the same way as standard relationships. The handling of a trace relationship is determined by the direction of the trace, and whether or not the item it points to is a version. The order of traces is maintained on both the versioned item and the target. New traces are added at the end of the operation.
As part of the check-in operation, Windchill RV&S moves or copies any suspect flags along with the associated trace relationship.
The next sections describe the typical scenarios for creating a content version and illustrate how Windchill RV&S handles trace relationships in each of those scenarios. The diagrams in the scenarios use the following legend:
Trace Scenario 1
In this scenario, all downstream traces from the live item are copied to the new versioned item, whether those traces point to a live or versioned item. In both cases, the upstream traces are copied from the Test Document to both the live Requirements Document and the versioned Requirements Document.
Trace Scenario 2
In this scenario, upstream traces that point to live content are not copied to the new version of the item. The result is that no new traces are created on the versioned item.
Trace Scenario 3
In this scenario, upstream traces that point to versioned content are moved from the item you are checking in, to the newly-created version of that item. In this scenario, the result is that the upstream trace from the live Test Document is moved to the versioned Test Document.
Trace Scenario 4
For two items that are checked in as part of a single operation, Windchill RV&S recreates (copies) the trace between the two newly-created, versioned items. No traces are created from the new versions to the original live items.
| In the same scenario, if the two items are versioned in separate operations, the result depends on the selected order of the check-in operations. When items are versioned individually, the resulting traces may not match the result of versioning in a single operation. |