traceabilitymodel 1024x467 1

traceability

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

traceabilitymodel
A simple traceability model: Artefact types and their allowed relations

In Polarion, artifact 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:

linkroles
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 the application of your traceability model easier for your users. Quick and systematized access to frequently used derivation actions will automatically lead to correctly linked artifacts and better data quality.

formmenu
Form menu to support correct work item linking

Defining linking rules will prevent that no undesired links will be created between your artifacts, 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 of the traceability status in a project, e.g. if you want to connect at least one software requirement with your system requirements.

coverage
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.

mypolarion
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.

dod
Definition of Done covering traceability aspects

Another area that can be utilized to ensure the correct linking of artifacts 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 be “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.

condition
Workflow condition checking a “tracking” change request

Leave a Comment

Your email address will not be published. Required fields are marked *