Medical Device Traceability Matrix

Posts: 3
Joined: Wed Aug 03, 2016 9:50 am

Medical Device Traceability Matrix

Postby s_g_robertson » Tue Mar 28, 2017 2:25 pm

I'm wanting to produce a traceability table (Medical Devices development) that shows the relationships I've tried to express below. There is no problem creating the links and navigating through them inside Polarion but what I want to produce is an output (pdf/excel/word/...) showing a matrix.

User Requirement > Validation Test Case & Validation Test Result > Product Requirement > Verification > Test Case & Test Result

Each user requirement must map to
-at least one validation test case and result
-at least one Product Requirement

Each Product requirement
-may, but does not have to map to a User Requirement
-must map to at least one verification test case and result

So the largest set of results will be the product requirements. I can fairly easily get the information split across three outputs using the ExtensibleTraceabilityTable extension.

1.User Requirement > Validation Test Case & Validation Test Result
2.User Requirement > Product Requirement
3.Product Requirement > Verification > Test Case & Test

but my problem is because not all product requirements are mapped to from a user requirement. It feels like I really need to start in the middle and work out in both directions, but I have no idea where to start.

Any suggestions?

Posts: 2
Joined: Wed Apr 12, 2017 8:46 am

Re: Medical Device Traceability Matrix

Postby Phoebe » Wed Apr 12, 2017 9:10 am

Hi Stephen,

we are using a custom Wiki page to generate traceability matrices. The algorithm is the following:
1. Query all Product Requirements
2. For each Product Requirement, query linked User Requirement and Verification
3. For each linked User Requirement, query linked Validation
4. For each Verification, query linked Test Result
5. Plot Table row containing the current Product Requirement along with its User Requirement(s), Verification etc.
6. Repeat 2.-5. for every Product Requirement
=> This table is used for documentation.

Additionally, we use a list of "Unlinked User Requirements" to check whether there are any User Requirements that have not been mapped to a product requirement yet.


Posts: 3
Joined: Wed Aug 03, 2016 9:50 am

Re: Medical Device Traceability Matrix

Postby s_g_robertson » Fri Oct 06, 2017 2:35 pm

Hi Phoebe,

I completely missed your reply.
That is exactly what I would like to be able to do. Is your wiki page based on something that is publicly available or did you start from scratch?


Posts: 1
Joined: Fri Jan 19, 2018 9:54 am

Re: Medical Device Traceability Matrix

Postby mse » Fri Jan 19, 2018 9:55 am

Hi Everyone

I have a pretty simular issue,
could anyone point me in some sort of example script I could use?

thank you!

Posts: 9
Joined: Tue Sep 12, 2017 1:02 pm

Re: Medical Device Traceability Matrix

Postby Jürgen » Mon Jan 29, 2018 12:42 pm

Hi, all

To create a trace table with more than two columns you will need a data structure that is capable to store "maps". In your case you have a map of maps of maps of maps, each map containing one level (column) of the trace table.

This is really difficult in the velocity version of Polarion, because it does not offer maps (it is too old).

What we did was to create a Java plugin (more exact: we payed Polarion to create that plugin). In Java you can create all the maps you need, then write them out in the way you like.

Basically the plugin starts at the top of the Hierarchy and then navigates through all the links, plus some specialties. For example we can do the table top-down or bottom-up. Another possibility is to filter work items on each level, e.g. only use items from one document.

But even this plugin does not cover the whole aspect. We could not create exactly one trace table containing all your items, because such a trace table needs a start point from where you can reach all the other items, and this is not possible* when you have Product Requirements in the middle of the hierarchy without a parent. (*at least not in an easy way).

In your case we would create a "dummy" (or call it a "generic") User requirement and link it to all PR who do not have a real UR. Then they all would appear in a trace table starting at the top. Or we would simply create two trace tables, one starting at top level (UR) the other starting at PR level. For the second table one could maybe filter to only have PR without links to UR, to avoid duplicates. On the other hand it does not hurt to have duplicates.

Return to “Polarion Application Lifecycle Management (ALM)”

Who is online

Users browsing this forum: No registered users and 2 guests