Linking examples

The following examples can help you understand how to use links to establish relationships between items for traceability and impact analysis purposes.

  • The requirements for an upcoming release are grouped in separate documents based on functional area. You can link all the documents in a peer relationship to indicate they are all part of the same release and make it easier for users to access the related documents.
  • A customer submits a feature request, which is added as an issue in Helix ALM. The product manager decides to address the feature request in the next release. She creates a document that includes requirements to fulfill feature request and links the issue to the document in a peer relationship to track the document and its source together.
  • A stakeholder approves a document that includes business and functional requirements for an upcoming release. The development team lead is notified when the document is approved. As the development team creates technical specification documents based on the business and functional requirement document, the team lead links the documents in a parent/child relationship to make it clearer where the technical specifications came from. This also makes it easier for the development team to make sure specifications exist for all functional requirements.
  • The QA team lead generates six test cases from a requirement to validate the requirement is implemented and tested. She links the test cases to the requirement in a parent/child relationship, then assigns the test cases to a tester to write the steps. The tester can view the requirement to make sure the correct steps are included in the test case.
  • A customer submits a feature request, which is added as an issue in Helix ALM. The product manager decides to address the feature request in the next release and creates a requirement based on it. She links the issue to the requirement in a peer relationship to track the requirement and its source together.
  • A stakeholder approves functional requirements for a portion of an upcoming development project. The development team lead is notified when the requirements are approved and creates technical requirements, which are added to a separate document. He then links the functional requirements to the technical requirements in a peer relationship and assigns the technical requirements to a software architect who writes them. The architect can view the functional requirements to make sure the related technical requirements are complete and accurate.
  • Six test cases are created to test a new software feature. The QA team lead links all the test cases in a peer relationship so testers can view the related test cases and all of them can be tracked together.
  • A problem is found that affects a product’s native client and web client. The QA team lead creates a test case that includes overview information about the change and required testing. She assigns the test case to a team member so he can add the details for testing each client. He creates two new test cases and then links all three test cases in a parent/child relationship. He selects the initial test case created by the team lead as the parent and the test cases that contain the specific testing steps as the child test cases.
  • The development team makes a functional design change, which they add as an issue in the Helix ALM project. The QA team lead is notified about the design change and creates a test case to make sure the change is tested. The team lead links the issue and test case in a peer relationship and assigns the test case to a team member to write the test case steps. The team member can view information about the change in the linked issue so the steps for testing the change are complete and accurate.
  • A test case requires testing on multiple operating systems and manual test runs are generated for each operating system. A tester links all the manual test runs together in a peer relationship so other testers can view the manual test runs and they all can be tracked together.
  • Several manual test runs are generated for a test case. A tester links the manual test runs to the test case in a parent/child relationship. She selects the test case as the parent and the manual test runs as children to show the relationship.
  • The development team makes a functional design change, which is added as an issue in the Helix ALM project. The QA team lead is notified about the change and creates a test case to make sure the change is tested. The team lead then generates manual test runs and links the manual test runs, test case, and issue in a peer relationship. When the manual test runs are assigned, the tester can view the related test case and issue.
  • QA is testing a new software component and reports five issues. When the team lead reviews the issues, she realizes they are all symptoms of the same coding problem. She links the issues to make sure the same fix is applied to all issues.
  • A company is getting ready to release a major software upgrade. In conjunction with the release, the marketing department needs to update the web site, write a press release, create a direct mail campaign, and create an email marketing blast. The marketing director creates a parent issue named Upcoming Release and creates four separate issues for each task that needs to be accomplished. He then links the issues together in a parent/child relationship.
  • A problem is found that includes a code change, a documentation change, and an update to an existing knowledgebase article. Instead of creating one issue, a developer creates three different issues, links them together, and specifies the order to fix and close the issues. Requiring the code change issue to be closed first, then the documentation change issue, and finally the knowledgebase issue ensures the documentation and the knowledgebase article both reflect the code changes.