How to incorporate the correct traceability model into your processes

traceability
traceability

Each development process (implicitly or explicitly) covers a traceability model which defines all possible or desired relations between the process artefacts. It is an essential part of the process description in order to enable impact and coverage analyses, test traceability and progress monitoring. In its most simple form a traceability model consists of available artefact types and the allowed relation types between them.

A simple traceability model: Artefact types and their allowed relations

In Polarion, artefact types are usually mapped to work item types and the allowed relations are defined by link roles. The configuration is easily done in the administration area by adapting the linking rules for each link role, e.g. the link role “verifies” will be typically allowed from a “System Test Case” to a “System Requirement:

System Test Case “verifies” System Requirement

After defining the linking rules according to your traceability model, Polarion will only suggest the allowed link types during work item linking and it won’t be possible to create links that don’t match your linking rules. Yes, this is a big step towards incorporating the correct traceability model into your processes. Nevertheless I would like to highlight some simple possibilities to ensure that your users are guided by your traceability model in their daily tasks.

Many links are created along the breakdown process, i.e. when a new work item is “derived” out of an existing one. In most cases a requirement will be broken down into multiple requirements or a change request is submitted against an approved requirement by deriving a new work item of type “change request”. Polarion offers the possibility to provide the appropriate menus for work item derivation. With the help of the “form menus” you can adapt the user interface in a way that makes application of your traceability model easier for your users. Quick and systematized access to frequently used derivation actions will automatically lead to correctly linked artefacts and better data quality.

Form menu to support correct work item linking

Defining linking rules will prevent that no undesired links will be created between your artefacts, but how can you ensure that all desired links will be created so that traceability is complete? It is good practice to apply various reports to highlight missing linking information so that your users will be able to quickly identify To-Dos regarding traceability. Coverage reports are a perfect instrument to get an overview about the traceability status in a project, e.g. if you want to connect at least one software requirement with your system requirements.

Coverage report to identify missing traceability information

Furthermore you can apply more specialized and role based reports in order to provide traceability related To-Do lists for your users. Additional sections in the standard “My Polarion” page can cover all traceability related tasks for a user, based on their roles and assignments. Like in other areas (e.g. approval process and change management) this will promote a more collaborative approach to achieving better traceability.

Personal traceability To-Do items

If traceability is defined as a process goal and the fulfillment of the traceability model is not a nice-to-have, it is a good idea to make the conditions to reach certain project milestones dependent on the existing traceability information. E.g. “Definition of Done” for product releases should cover aspects like test traceability so that the current status is transparent and a valid product release is only possible by maintaining the correct links.

Definition of Done covering traceability aspects

Another area which can be utilized to ensure correct linking of artefacts is the workflow definition. If for any status of a work item a traceability goal is defined, this should be reflected in the workflow conditions. E.g. it is common practice to allow the status change of a system requirement to “approved” only if there is at least one system test case verifying it or to allow re-opening of an approved requirement only if there is an assigned change request. Simple measures like these in the workflow definition will guarantee that your traceability model will be incorporated into your processes.

Workflow condition checking a “tracking” change request

I hope these simple ideas will help you to establish complete traceability across your processes. Here are some links which might provide further information about the discussed topics:

Configure Work Item linking
Create and link a new Work Item in a single operation
Workflow Conditions for Work Items

Leave a Reply