Interconnecting your Engineering Elements
In product and system development, traceability is a key factor to tie cross-domain and cross-discipline development objects together and unify the complete lifecycle “story”. The links between these objects tell the story of how they relate to each other. In Polarion we call these objects work items.
For example, systems requirements are usually decomposed into lower level software- and hardware requirements. These downstream child requirements are then fulfilling, refining or satisfying the parent (or upstream) system level requirement. The name of these links varies but they hold the same fundamental meaning.
Let’s look at another example, a software engineer is assigned a task to write the code required to fulfil a user need in the software application. From the software requirement an implementing task is created and assigned to the developer. In Polarion this link is bi-directional. The link name (going from the task to the requirement) is named implements and the opposite name, is implemented by goes from the requirement back to the task. Conceptually it looks like this:
Polarion visualizes these relationships in the following way:
In Polarion we configure what we call link roles and link rules. Link roles are simply the name of the link (and opposite or back link).
Link rules determine which link roles are allowed to be used between which work items. Normally a test case would verify or validate a requirement, but not implement it. So, we are not allowed to use the implements link role between a test case and requirement and Polarion makes sure we only use what is allowed according to our defined process.
We can see that the implements role has three rules:
What is needed to configure these link rules is a project administration access role.
If you have questions about the Polarion functionality, please check out our Polarion Community.
Be part of the Polarion community
Join the community today and get in touch with us, register in our new community. Many of our experts are active in the new Polarion Community.
Join the Polarion Community
Comments
Leave a Reply
You must be logged in to post a comment.
Thank you for the illustrative article!
Question about the structure of the link rules in the figure above:
Rule 1 says:
– Task,Issue may implement Work Package
Rule 2 says:
– Work Package, Issue may implement System Requirement, Software Requirement
Rule 3 says:
– Task may implement Software Requirement
So both, Issue and Task, may implement a Software Requirement, therefore I could include Rule 3 into Rule 1, having only two rules needed for the same thing:
Rule 1:
– Task,Issue may implement Work Package,Software Requirement
Rule 2:
– Work Package, Issue may implement System Requirement, Software Requirement
Do you agree with this change?
If so: What are the pros and cons of the three-rule vs. the two-rule version?
Are there any other best or bad practices when defining link rules?
Would it be a good practice e.g. to only have one work item type in the “To types” column for each link rule?
Stephan