User Help > Working With Documents > What Is a Document? > Relationships in the Document Model
Relationships in the Document Model
Document and content item relationships are specific to a document model environment often used in requirements management and test management domains. These relationships dictate the behavior between documents and nodes, nodes and nodes, and also between nodes and their shared items.
Document and/or content items that fulfil the relationships explained below can be viewed in the Item Details view for a content or document item.
The structural and couplet relationships are built in relationships in Windchill RV&S.
The include form of nesting documents allows you to manage content as a single document. Dividing content into multiple documents may simply be for convenience reasons; for example, to partition work within the team, or to facilitate higher performance within the system.
The structural relationship is used to construct the tree hierarchy or document structure. Each parent in the hierarchy can have one or more children. Each child can have only one parent.
The main structural relationship between the segments and nodes is called Contains/Contained By.
The couplet relationship is used to link the node to the shared item or the node to the segment. The nature of the couplet relationship is mediated by the Reference Mode pick list on the node. Each shared item or segment can be referenced by multiple nodes, while each node can reference only one shared item or segment.
The couplet relationship is called References/Referenced By.
You can create trace relationships between two items in the document model repository; for example, between a requirement and a test case, or between a higher-level requirement and a lower-level requirement. Trace relationships are defined via field pairs and are presented to the user in domain-specific language, for example, test and requirements.
Although the amount of types of trace relationships is not constrained, generally there is one relationship between each type of object in the system, for example: high level requirements, marketing requirements, test cases, components.