The model structure and Traceability diagram act as starting points for tracing the definition, design and implementation of a feature of a system or process. By applying tools such as the Relationship Matrix and Traceability window to these, you can follow threads throughout the model to determine how the feature is implemented and tested. You can also obtain information on what elements realize and are realized by the elements in a given package, using the Dependency report and Implementation report, respectively.
The Traceability window is a most useful and versatile traceability tool. Starting with a Traceability diagram or a package structure in the Project Browser, you can use the Traceability window to quickly explore the relationship chain of which any element is a component. When you click on the element, it immediately becomes the top point in the Traceability window. When you click on the background of a diagram, all elements in the diagram are listed in the Traceability window, and you can follow the threads starting at each element through the diagram.
If you require a rapid, broad-brush view of relationship flows in the project structure, starting with a general list of - say - all functional Requirements, you can use a combination of Model Search, Project Browser and Traceability window; this is a powerful tool for scanning your project, identifying how elements have been organized, and how they interact. For example, the Model Search would list all the requirements, you could rapidly click on each element and immediately see in the Project Browser where it has been grouped, and at the same time - in the Traceability window - how that element interacts with other elements in the model.
You can select any or all of the relationship types available in the Traceability window toolbox. The single type selected below is Realizes (Implements), and the selected element is the Delete User Use Case. The Traceability window then shows that Delete User implements REQ017, but this is also partially realized by the Close Account Use Case.
By moving the cursor around a diagram or the Project Browser, and/or changing the relationship type combinations in the Traceability window, you can quickly see how elements are connected and how they influence each other. For example, you can see that REQ017 is realized by two Use Cases, so you might then explore what else influences and is influenced by these two Use Cases. The Traceability window takes you well beyond what is likely to be depicted on any single diagram.
If you have used transformations to develop your model, the T icon displays the transformation dependencies that exist between an element in a PIM and elements in the PSMs.
Using the Relationship Matrix, you can both create and study the relationships between, for example, the Requirements and Use Cases for a module. You might identify the 'theme' package (in this case, Manage Users) in the Requirements model and the Use Case model as the source and target packages, and explore the likely element and connector types in the packages. This, like the Traceability diagram, identifies which Requirements are (or should be) realized by which Use Cases. You can then perform similar checks with the Manage Users packages in, say, the Use Case and Implementation models.
The Source and Target field browsers ([ ... ]) enable you to examine child packages within the 'theme' package, and obtain further detail on how the feature at this stage is defined.
You can trace how a Class or Interface element in a diagram or the Project Browser is implemented in code or, for tables, in DDL, using the Source Code viewer. For code, as you click on features in the element, the corresponding code is highlighted in the viewer.
From the perspective of model management or project management, you could also use the Audit View as a means of tracing the change history of a package or element. The Relationship Matrix also assists in this respect, indicating the impact of changes in one element on others. A Use Case exists because it defines how a Requirement is met; if the Requirement is changed, the Use Case and its dependent diagrams and elements should probably be changed, if not deleted.