Products

Links between work items and their intended meaning

One of the great things in Polarion is the possibility to link all kind of artefacts and work items together. As a result you are able to trace the impact of a change request down to the changes you made in the source code. However links can be used in different ways and for various reasons. In this blog I want to give an overview about the links provided by Polarion and how they are intended to be used.

Has parent / is parent of


The link should always point from child to parent. You should always use that type of link when you have a refinement situation. Typical scenario is the refinement of customer requirements. At the beginning you have general requirements which are refined over time. Derived requirements are linked as child requirements to the parent requirement


Has parent link in treeview


Has parent link in workitem editor

Depends on / is dependent on


Use this type of link if you want to express that one item can only start when the other item has been finished. Typically you will have that type of relationship between tasks. The link should always point from a task to the task it depends on.

Duplicates / is duplicated by


Sometimes work items are entered in the system twice as people sometimes tend to forget to perform a search first to check weather the bug or requirement already exists in the system. In this cases you can close the duplicated item at once indicating by a link that it duplicates the item that was already in the system. Link should point from item the item you close because of duplication to the item that is still open.


In some situation you have some features that are not completely finished but lets say 80% done. However the current functionality can be released and works. In these cases it would not be correct just to close the item representing the feature as not 100% of it was implemented. A good way out of that dilemma is creating a follow up item that indicates the missing 20% of the feature. By doing this you can make sure that you won’t forget the missing functionality in future releases. The link should point from the closed item to the follow-up item


Is follow-up link

Relates to / is related to


Use that link when you want to express a generic relationship between two items. In requirements management you have very often situation in which requirements have dependencies (no refinements as mentioned above in parent link) to other requirements.

Rule of thumb: Use the link when none of the other relationships can be applied

Implements / is implemented by


At some point of time somebody has to do the work. Usually you will end up with a bunch of work packages represented by tasks in the system. To give the assignee of the task as much information as easy available as possible you should link the task to the corresponding input element. Tasks are normally linked to following input elements:requirements, change requests, bugs or features. The link should pint from the task to the input element.


Is implemented by link

Stay tuned for upcoming blogs on linking and planning

Stroebele Timothy

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/polarion/links-between-work-items-and-their-intended-meaning/