When planning your digital product traceability solution it is important to consider your overall product development process and how design information evolves and flows downstream.

For example, does your organization typically start development of a product with capture of requirements which are then translated into a specification for the physical design? Or do you create functional or logical system models after requirements definition? Or you may start with existing physical design information within Windchill PDMLink which is then updated in conjunction with requirements capture and system design.

Understanding your development process should guide your traceability approach to ensure that OSLC links are created in downstream systems so that changes to upstream data are visible using suspecting. In the example below, requirements definition is conducted first, followed by system design. In this situation, Integrity Modeler should be the OSLC client, meaning OSLC links are stored in the Integrity Modeler database and point to the upstream requirements. When changes are made to the upstream requirements, this is flagged to users in the downstream system using suspecting. Ensuring that changes to upstream data are visible to users of downstream data (which is typically dependent on the upstream data) is critical in managing change across design disciplines.