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 Quality Management (QM) application, requirement artifacts are located in the Requirements Management (RM) application, and development artifacts are located in the Change and Configuration Management (CCM) application. The traceability relationships between Quality 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:
  • Discovering and repairing missing back links is not supported for configuration management enabled projects.
  • If you have not enabled configuration management, when you create a link to external artifacts in a ELM application, a link is automatically created back to the source artifact in the target application, which is called a back link. However, the synchronization between bidirectional links and the traceability between source and target artifacts are not guaranteed.
When a source artifact and target artifact link to each other, this is known as bidirectional linking. 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.

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 QM 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 submitted against the test case during 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
–> 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)
–> 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)

video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net
Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki