Links are established that explicitly model interrelationships among information in the different work product. The traceability objectives are:

• determine the impacts of proposed changes [Ramesh1997];
• link variabilities among different SPL assets, make easy future decisions in the products instantiation; and
• demonstrate that each requirement has been satisfied  [Ramesh1997].

The traceability metamodel is presented in Figure below. In this metamodel, the entity Trace represent the traceability link between two objects (Object A and Object B). An Object can has many trace links. An Object in RE can be a Use Case, a Requirement, a Feature, or a Use Case or Requirement Variable Part. The Use Case or Requirement Variable Part corresponds to a variation point or a variant within specification (e.g. text fragment, actors, pre conditions, and so). Thus, relationship between work products is a many-to-many association.

All RE work products must be traceable. However, it must maintain only the direct trace. Indirect traceability is found by inference from objects trace links. Some examples can be observed:

• A use case UC1 has direct trace link with its variable part VP1. Whether VP1 is directly traced with a feature F1, then UC1 is indirectly traced with F1. It represent a transitive relationship, T = {(UC1,VP1)  and  (VP1,F1) → (UC1,F1)}.
• Whether requirement R1 is directly traced with feature F2, and use case UC3 is directly traced R1, the F2 is indirectly traced with UC3.  T = {(UC3, R1) and (R1, F2) → (UC3, F2)}.

All Traces are characterized by the attribute relationship type. The following relationship types are defined:

• External Association. This relationship express external association between different work products, i.e. relationship between feature and requirement, feature and requirement variation point, feature and requirement variant, feature and UC, feature and UC variation point,  feature and UC variant, requirement and UC, UC and requirement variation point, or UC and requirement variant. For example, requirement User Maintain is associated with feature Authentication. It implicates that when feature Authentication feature is bound the requirement User Maintain also is automatically bound.
• Composition. This relationship is used to express the whole-part relationship between requirement and its variation point, use case and its variation point, or variation point (of the requirement or UC) and its variant (whether VP has more than one variant). In the relation (A, B), the object A is the parent-role and object B is the child-role.
• Implication. This the relation means that it must make a choice about the variable object A only if a object B is chosen. This relationship type is defined only between objects of a same work product, i.e. feature and feature, requirement and requirement, requirement and requirement variable part (variant or VP), requirement variable part and requirement variable part, UC and UC, UC and UC variable part, and UC variable part and UC variable part. In the relation (A, B), the object A is the requester and the object B is the required object. For example, Login/Logout (A) requires User Maintain (B).
• Exclusion. This relation means that it must make a choice about a variable object A only if object B is not chosen. This relationship type is defined only between objects of a same work product, in the same manner that Implication. In the relation (A, B), the object A is the excluder and the object B is the excluded object. 
• Internal Association. It is defined for any another direct relationship between particular objects of a same work product that are not related by implication or exclusion.  This relationship type can be defined between feature and feature, UC and UC, or requirement and requirement.