Linking to requirements and development artifacts

You can use the Engineering Lifecycle Management product integration to create traceability links to new and existing artifacts in other products that are based on Jazz. Link from test plans and test cases to requirements and work items. After creating links, you can view a summary of the linked artifact or navigate to the artifact. You can also add a widget to your dashboard to monitor the status of linked artifacts.

The Engineering Lifecycle Management product integration must be configured before you can complete this task. For more information, see Running the setup wizard. To add a widget to your quality dashboard, see Adding and organizing content on a dashboard.

As you link test artifacts to requirements and development work items, the link types define the traceability relationships between the artifact types. Test artifacts are located in the Engineering Test Management application, requirement artifacts are located in the Engineering Requirements Management DOORS® application, and development artifacts are located in the Engineering Workflow Management application. The traceability relationships between Engineering Test Management and the other applications are described in the following graphic and table:

Quality management links to requirements management and change and configuration management

Limitations: If you do not enable configuration management, when you create a link to external artifacts in the Engineering Lifecycle Management application, a link is automatically created back to the source artifact, which is called a back link. However, the synchronization between bidirectional links and the traceability between source and target artifacts might be unavailable depending on certain transactional operations in the source or target application.

When you can navigate from the target of a link back to the source of the link, this is known as bidirectional linking.

If the configuration management is enabled in the Quality Management project, the links are stored in the source artifact repository and back-links are discovered by the target artifact server making queries on the source artifact servers or LDX.

If configuration management is not enabled, the source and target applications store their links in separate databases, and the source application does not have access to the database in the target application. Certain transactional operations, such as when artifacts are copied or deleted, can occur on the source application server. In these cases, corresponding back links in artifacts in the target application are not automatically added or removed. Also, instances occur where back links are intentionally removed from the target application without removing the corresponding link from the source application. As a result, if bidirectional links are not in a state of synchronization, traceability between the source and target artifacts can appear different based on your starting viewpoint.

To add or remove target artifact links to or from the source artifact, you do not need permission to save the target artifacts.

The accuracy of traceability reports might be affected if bidirectional links are not in a synchronized state. Links to the following artifacts are included in this limitation:

Requirement collections
Development plans
Requirements
Change requests, such as defects, tasks, plan items, and stories

Note: The symmetry of bi-directional links is not guaranteed. The reason for this limitation is that the source and target applications store their links in separate databases, and the source application does not have access to the database in the target application. Certain transactional operations, such as when artifacts are copied or deleted, occur in the source application server. As a result, corresponding backlinks in artifacts in the target application are not automatically added or removed. There can also be instances where backlinks are intentionally removed in the target application without removing the corresponding link in the source application.

Table 1. Common Engineering Test Management link types
Link types in a test plan	Description
Validates Requirement Sets	Collections of requirements that are validated by the test plan
Related Change Requests	Work items submitted against the test plan, such as quality tasks
Tests Development Plans	Development plans that are related to the test plan
Link types in a test case	Description
Related Test Scripts	Automated or manual test scripts that are associated with the test case
Validates Requirements	Requirements that are validated by the test case
Related Change Requests	Work items that are submitted either as change requests against any section of the test case or as defects during or after test execution
Tests Development Items	Change management items that associated with the test case

For more information on link types in RM, see Link types in requirements projects. For more information on link types in CCM, see Linking between artifacts in the web client.

Table 2. Cross-application linking for test artifacts
RM	Link type	QM	Link type	CCM
The test manager links requirement collections and development plans to the test plan. The collection defines what requirements must be tested. The test plan is driven by the requirements collection. The development plan is tested by the test plan. The test manager must link both the requirements collection and the development plan to the test plan. When testers file defects during execution, these defects are related to the overall test plan.
Requirement collection, module, and module view	–> validated by <– validates	Test plan	–> tests <– tested by	Development plan
Requirement collection, module, and module view	–> validated by <– validates	Test plan	–> related <– related	Work item (defect)
The test lead or tester creates a test case to address one or more requirements. The corresponding development work item (the story that implements the requirement) is then tested by the test case. The requirements available for a test case are driven by the requirement collection that is related to the parent test plan to promote adequate test coverage. When testers file defects during execution, these defects are related to the test case.
Requirement	–> validated by <– validates	Test case	–> tests <– tested by	Development work item (story)
Requirement	–> validated by <– validates	Test case	–> related <– related	Work item (defect)
The tester executes the test suite or test case. Defects that result from the execution affect the test result.
		Test result (suite or case)	–> affected by <– affects	Work item (defect)
The tester executes the test case. All executions create test case execution records, which represent the test case, test environment, and execution instance. Defects block test case execution records. After a developer fixes the defect, the tester can execute the test again to confirm the fix.
		Test case execution record	–> blocked by <– blocks	Work item (defect)