itemis Blog

Traceability for Polarion and source code

Written by Tobias Benning | Dec 22, 2017

Information: YAKINDU Traceability Is Now itemis ANALYZE

The Polarion adapter of YAKINDU Traceability (now itemis ANALYZE) provides traceability for Polarion work items. Work items are not restricted to source code only, they can rather also be any other development artifact type, for example test cases in an external tool. YAKINDU Traceability (now itemis ANALYZE) can also recognize links existing within Polarion between Polarion work items. As part of the latest release, we based the Polarion adapter on a new technical foundation. 

This led to a performance boost, which makes the Polarion adapter the feature of the month for December 2017. We now can query the Polarion database even faster than Polarion itself (at least in our lab).

Define the work items which are relevant for traceability

The new technical basis is simply SQL: The adapter queries the Polarion database directly. Hence, the configuration is simple: You just have to provide the connection credentials for the database and to specify which work items are relevant.

The following image illustrates which data are relevant for the data access: you just need to set the database’s host, port number, and the credentials for accessing the database. 



Once access is granted, you can specify which artifacts are relevant, based on attribute filters.



In the example above, we configure YAKINDU Traceability (now itemis ANALYZE) to extract the
id and the severity of all work items of type Software Requirement.

The extraction of, say, stakeholder requirements and links between stakeholder requirements can be configured in the same manner.

Linking between Polarion and C code

Once artifacts such as system requirements or software requirements are available from Polarion, they can be linked to any other artifact type that is supported by YAKINDU Traceability (now itemis ANALYZE), for example, architectural design artifacts in UML/SysML or Matlab or to test cases in the tool of your choice. Please find a complete list of supported artifact types on our website.

As the definition of such links is not specific to Polarion, we can re-use the linking mechanism that has been described already in our blog post on tracing requirements and source code.

Putting the pieces together

As an example, we set up a YAKINDU Traceability (now itemis ANALYZE) configuration representing the left leg of a V-model, comprising

  • system requirements,
  • software requirements residing in Polarion, and
  • software units in the form of C source code.


The animated GIF above shows how to create links between Polarion work items and source code with YAKINDU Traceability (now itemis ANALYZE): We create link-two-software-requirements to the very same C file by a simple drag and drop. The comments created by YAKINDU Traceability (now itemis ANALYZE) are the persisted links. As a result, it visualizes the complete traceability context of the C file, comprising system requirements and software requirements.