ReqSuite® Requirements Manager (RM)
Data Exchange

In order to synchronize data from a ReqSuite® RM project with other tools such as JIRA, TFS, AzureDevOps, GitLab, ClickUp or external ReqSuite® RM installations, the data exchange via the corresponding interface must be set up. Of course, this mapping does not have to be done whenever a user wants to exchange data with the other tool. Rather, this setup is done once by the administrator, e.g. when a new project starts.

A prerequisite for setting up data exchange in a certain project is that an interface to the corresponding tool has been configured before (see interface administration).

The different steps for setting up the data exchange are as follows:

Interface Assignment

The first step is the assignment of one or more tool interfaces to a project in ReqSuite® RM that shall exchange data with other tools. This can be done by clicking the plug icon in the row of the corresponding project in the project administration area and then moving the desired interface(s) from the left pane to the right pane in the next screen (see Figure 1).

Figure 1. Example for interface assignment
Project Assignment

The second step is the assignment of the ReqSuite® RM project to a corresponding project / backlog in the other tool. This can be done by clicking on the edit icon in the tools row (see right side in Figure 1), and then selecting a project in the drop down menu on the appearing screen. Further settings that can be made in this screen (see left side in Figure 2) are:

  • the selection of the point in time when the data exchange shall take place
  • the direction in which data shall be exchanged (only from ReqSuite® RM to the other tool or even back)
  • the resolving system in case a conflict occurs during data synchronization (only relevant for bidirectional data exchange)

With the checkbox “Read Git Repository” you can define if you want to download the Git commits of the mapped project for visualizing them in the editing window of the item that is addressed in a corresponding commit message. Currently, this feature is only available for GitLab and AzureDevOps as both have an integrated Git repository.

Figure 2. Example of a project assignment and category selection
Category Selection

The third step is the selection of the content categories in the given ReqSuite® RM project whose items shall be exchanged with the other tool. Even though it is technically possible to synchronize all categories, it is strongly recommended to exchange only one or two categories. The reason is that is does not make sense to duplicate the entire content of a project in two tools. Rather, a clear separation of concerns shall be established, including the definition of a clear category via which the integration should be done. The selection can be done by just marking the corresponding checkbox of the category (see right side in Figure 2).

When syncing to Jira or AzureDevOps, it is also possible to export the relationships:
If a mapping is created for at least two categories and a relationship exists between these categories in ReqSuite® RM, links between the corresponding items will also be exported to Jira or AzureDevOps. However, relationships which created from the other tools are not synchronized back to ReqSuite® RM.

Category Mapping

After selecting the content category to be exchanged, it is necessary to translate it into a content type that is supported by the other tool. This is done by clicking the edit icon in the row of the selected category and then selecting a desired type in the upper part of the then appearing screen (see Figure 3).

Attribute Mapping

Typically the last step in setting up the data exchange is the attribute mapping, which can be done on the same screen as the previous step (see Figure 3). Even though ReqSuite® RM typically creates a default mapping, additional attributes can be mapped or the default mapping can be changed to an explicit mapping. The difference between default mapping and explicit mapping is that in the former case ReqSuite® RM decides how to map best an attribute from the other tool to the data structure of ReqSuite® RM, whereas in the latter case, the administrator can explicitly select an ReqSuite® RM attribute.

Figure 3. Example of a category mapping and attribute mapping
State Mapping (optional)

The mapping of states is an optional step and only possible if a tool attribute called “State” with default mapping has been selected beforehand. When applying a state mapping, the administrator can decide which state in a ReqSuite® RM workflow shall correspond to which state in the workflow of the other tool. In this regard, not all states have to be mapped, i.e. the state on one side is not updated if it is changed to a non-mapped state on the other side.

Important Note: For tools that are not yet supported by a built-in adapter, the REST API of ReqSuite® RM can be used or you can request the development of such an adapter in one of the next releases.