The Polarion adapter of YAKINDU Traceability 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 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 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, 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 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: We create link-two-software-requirements to the very same C file by a simple drag and drop. The comments created by YAKINDU Traceability are the persisted links. As a result, it visualizes the complete traceability context of the C file, comprising system requirements and software requirements.