In IBM DOORS Next Generation can use links to associate requirements with other requirements (artifacts) in IBM DOORS Next Generation and with resources outside of DOORS NG. Generally, there are three types of links in DOORS Next: 

• Standard links (OSLC links) - associating artifacts in the same database with one another, these links can be added into the views and if they are opened, user is navigated to the location of linked artifact or it will directly open the linked artifact (depends on the context of the link). 

• Hyperlinks - associating artifacts (mainly content of them) with any entity or resource inside or outside the IBM DOORS Next Generation database. If the entity or resource is located outside the database we can also call them external links.

There is a case when together with hyperlink also an OSLC link is created. This happens when the user defines this manually or automatically, when the functionality called LookUpTerm is used. More about this functionality you can find here. 

This article aims to describe OSLC system defined link types that are used in IBM DOORS Next.

This article serves as an introduction to DOORS NG links. While not being a direct DNG linking tutorial, it will help you learn the basics of DNG linking terminology, what types of links there are, and the basics of link management in DNG while highlighting the offering of extensions that Softacus provides for DNG linking

OSLC - Open Services for Lifecycle Collaboration is an open community that defines a set of specifications that enable integration of software development in areas such as Application Lifecycle Management (ALM), Product Lifecycle Management (PLM), IT Operations and more… The intention is to make life easier for tools users and tools vendors, by making it easier for tools to work together.

IBM DOORS Next provides several options on how you can manage your artifacts in your Projects and some of them include the artifacts reusing. Every artifact that is located in Module (specification, document) - module artifact - is also stored as a base artifact in Module’s folder or in the “Base Artifacts” folder (this setting can be specified in Component/Project properties). When you are reusing artifacts, the traceability might not be lost. For this purpose, there are two contexts of the links in IBM DOORS Next:

• Base artifact links - base artifact links do have special icons in grid view, to be easily recognized and are created when the target or source of the link is base artifact. If the link is created as a base artifact link, it is displayed in all modules, where this artifact is reused.
  
  
• Module artifact links - module artifact links are created, when both source and target artifacts are located in a module and they are displayed in a grid view only, if the user is located in module from where or where to was link created.

Requirements projects include several predefined link types for traceability:

• Constrain (Constrains / Constrained By) - Captures the relationship between requirement artifacts when one artifact limits or holds back the other artifact. For example, an artifact can be constrained by a requirement that it must conform to.
• Embeds (Embeds / Embedded In) - These types of relationships can be used when performing operations such as 'Insert Artifact' and 'Insert Image' for a Text artifact and is not forced by the system
• Extraction (Extracted / Extracted From) - Can be used when the content of a Requirements Management artifact has been created from content of another Requirements Management artifact, this type of link is created when performing extraction-based operations, for example, the 'Save As New' operation for a Text artifact.
• Illustration (Illustrates / Illustrated By) - Illustrates the relationships between graphical and text artifacts.
• Link (Link To / Link From) - Can be used between any RM artifacts. General relationship between RM artifacts
• Mitigation (Mitigates / Mitigated By) - Captures the relationship between requirements and risks. A requirement mitigates one or more risks, and a risk is mitigated by one or more requirements.
• Decomposition (Child Of / Parent Of) - Captures part-whole relationships between Requirements Management artifacts. These types of links are typically used to represent artifact hierarchies
• Satisfaction (Satisfies / Satisfied By) - Captures how the different levels of requirements are elaborated. For example: an approved vision statement in a vision document can be satisfied by one or more stakeholder requirements.
• Synonym (Synonym / Synonym) - Can be used for relating two Requirements Management Glossary Terms that have the same meaning.
• References Term (References Term / Term Referenced From) - Enforced link type when using “Add Term” function - all artifacts are always linked on the base artifact level

• Affected By (Affects / Affected By) - Captures the relationship between a requirement artifact and a change management work item that affects the implementation of the requirement artifact. For example, a defect in the Change and Configuration Management (CCM) application can affect the implementation of a requirement artifact. This link type is not available for modules and collections.
• Implemented By (Implements / Implemented By) - Captures the relationship between a requirement artifact and a change management work item that describes the implementation of the requirement artifact. For example, a story in the CCM application can describe the implementation of a requirement artifact. In the CCM application, links of this type are shown as Implements links. This link type is not available for modules and collections.
• Tracked By (Tracks / Tracked By) - Captures the relationship between a requirement artifact and a change management item that tracks the implementation of the requirement artifact. For example, a plan item in the CCM application can track the implementation of a requirement artifact. In the CCM application, links of this type are shown as Tracks links. This link type is not available for modules and collections.

• Derives Architecture Element (Derives From Architecture Element / Derives Architecture Element) - Captures the relationship between a requirement artifact and a model element. For example, a UML use case in an architecture management application can represent a requirement artifact. The requirement artifact derives from the UML use case.
• Refines Architecture Element (Refines Architecture Element / Refined By Architecture Element) - Captures the relationship between a requirement artifact and a design element. Design resources can be linked to requirements management artifacts by using the Refined By Architecture Element link type. These link types are visible in RM as the Refines Architecture Element link type.
• Satisfy Architecture Element (Satisfies Architecture Element / Satisfied By Architecture Element) - Captures the relationship between a requirement artifact and an architecture management item that represents a model of the requirement artifact.
• Trace Architecture Element (Trace Architecture Element / Traced By Architecture Element) -  Traces the relationship between a requirement artifact and an architecture management item that traces the model element to the requirement artifact.

• References (References / Referenced By) - Tracks a relationship between requirement artifacts. These types of relationships occur when requirement artifacts reference requirement artifacts in another RM instance or another project area.

• Validated By (Validates / Validated By) - Captures the relationship between a requirement artifact and a test artifact that validates the implementation of the requirement artifact. For example, a test plan in the Quality Management (QM) application can validate the implementation of a requirement artifact. In the QM application, links of this type are displayed as Validates links. Validated By links point from the RM application to IBM Engineering Test Management (ETM).

IBM DOORS Next Generation provides a possibility to create a custom OSLC link definition. When creating a new link type it is recommended to always define URI (this is useful for creating links between other configurations, because then the links must have the same URI address, also it is useful when performing ReqIF exports/imports).

Link Constraints, simply said, are the rules for linking the artifacts. Administrator, or the user with rights to define the Link Constraints, can prevent other users from creating (or help them to not create) specific link type between specific Artifact Type. 

Note: If no Link Constraints are defined, all links are allowed.

Link Validity is a status of link between artifacts which can indicate whether the attributes and contents of these links meet the intended meaning of their link. It can be used for tracking the changes in artifacts. Link Validity has three states: valid, invalid and suspect and these states are affected by any change in attribute or content in the target or source artifact of the link. If there is any change made in one of these two artifacts, the state of the link is changed to suspect.

There are several Softacus extensions available for you to help you create and manage links in your Projects: 

Link Type Change - This extension is able to change link direction of a link or convert it to other link. For example, you can change "Link To" to "Link From" or "Link To" to Satisfied By".

Module Link Statistics - It's a quite simple to create a link between the Artifacts in Engineering Requirements Management DOORS Next and also between Artifacts in different applications (ERM - ETM, ERM - EWM....). User can create his own link types or use the default ERM links, define the directions of links (and their different names) and then use them for linking Artifacts between each other. But what about statistics? How many Artifacts in the Module (document) were linked? How many of these links are valid? For this kind of statistics you can build up the report in Report Builder application. But it's complicated for the new users. They must to learn about Report Builder, find an appropriate way how to build this report and it's time consuming. We, in Softacus, have developed a widget which will help you to simplify this process. 

Link Switcher - This extension convert links of text artifacts from module context link to base links. It can convert many links in a short time. It can process more than 200 artifacts at a time in one source module.

Links Builder - This extension allows you to create a Link between two artifacts in DNG according to certain rules. You can specify rules that take into account the following parameters: Types of linked artifacts, Link type, Artifact placement.

Link by Foreign Attribute - This extension will create links between artifacts in the selected module(s). The information about the generated links is taken from certain custom attributes. It can build many links in a short time.

Show Attributes of Linked Artifacts - This extension shows the attributes and links of the artifact that is currently selected.

Every Softacus DNG Extension can be modified based on your needs or requirements. We are looking forward to developing a solution for you.

All of our widget extensions are free of charge for customers who purchased the IBM Jazz solution or services from us. In case that you are interested only in the extension without services, you have found a bug or you have an enhancement request, please contact us at: info@softacus.com.

Softacus can provide different types of services including services for IBM products, migrations to IBM Jazz Platform, support in topics related to IBM Jazz Platform, related services topics and complex solutions based on our long term experience in working with IBM Jazz Platform.