ReqSuite® Requirements Manager (RM)
Relationship Types

Unlike some other RM tools, ReqSuite® RM only allows elements to be linked if a corresponding relationship type between their categories has been explicitly modeled in the project template. Although this may sound like a limitation at first, this mechanism allows for better assurance of the semantics of relationships and, consequently, automatic verification of compliance with required links.

For defining relationship types, the following aspects are important (see Figure 1):


The correct definition of a relationship’s direction is of great importance in ReqSuite® RM, as it affects several functions such as reuse, Word exports, filters and assistance. Therefore, to build a solid data model in the project template, it is necessary that the relationship (type) directions follow a clear rule.

In ReqSuite® RM, the source of a relationship (the end without an arrow) shall always be the category whose elements are derived from, contained in, required by, influenced by, part of, etc. of elements of the category being the target of the relationship (the end with an arrow). Simply put, the source always represents the more concrete / refined level in a relationship. For instance, when having the categories “system” and “subsystem”, the relationship shall lead from the subsystem to the system and not vice versa.

If, at the end of the relationship type definition, all relationship types are passed through transitively, two things should always hold true:

  • There should be a root category to which all relationships ultimately lead. This root category has no outgoing relationships itself. In many project templates, a category called “Project”, “Product” or “System” – which is often also defined as a singleton category – is typically such a root.
  • There must be no circular reference, which means that one should never return to the same category when traversing relationships transitively. The only allowed exception are so-called self-relationships, i.e. relationship types where the source and target categories are identical.
ReqSuite®-specific Types

When defining relationship types, there is a need to decide whether the relationship shall be a “requiredBy”, “containedIn”, “influencedBy” or “specializes”. The differences are explained below.


Relationship types that are requiredBy can be managed in a project, i.e. users can create relationships of this type between elements of the corresponding source and target category. They cover 90% of cases and are the common choice when defining a relationship type.


Relationship types that are containedIn can be managed in a project too. The main difference is that they are considered stronger. For instance, when reusing elements including their related elements, elements being in a containedIn relationship to the reused elements are automatically included, while for requiredBy relationships, users can individually select which related elements to reuse. Except of this specific case, there are no differences.


Relationship types that are influencedBy cannot be managed in a project. The only purpose of these relationships is to order the sequence of tasks in the work proposals when other relationship types are not sufficient to provide the desired order.


Relationship types being specializes cannot be managed in a project either. The purpose of these relationships is to apply the principle of inheritance from object-oriented design in the project template. This means that if the target category is an abstract category, the specializes relationships express that the source category is a special type of the target category. The depth and breadth of inheritance in ReqSuite® RM are both limited to one.


The specification of the “meaning” and the “reverse meaning” in the editing window of a relationship is used to express the semantic of a relationship. E.g. “Requirement given for the product” and “Product has Requirement”. The meaning (“given for the product“) reflects the semantic when reading from the source to the target category, the reverse meaning (“has“) reflects the semantic from the target to the source category.
When creating or modifying a relationship type in the project template, ReqSuite® RM displays a preview of a complete sentence expressing the meaning. If this sentence sounds strange, it’s an indicator that the meaning is not described in a correct form.

Furthermore, German project templates give the possibility to include “…” in the meaning description as sentences in German are typically built differently to English or French sentences. For instance, when typing “für die Umsetzung des … notwendig” as the relationship meaning, the “…” are automatically replaced by the name of the target category.


The quantity specification in the definition of a relationship type expresses how many elements of the source category can be related to how many elements of the target category. The corresponding condition can then be automatically checked and enforced in a project.

For example, for a relationship from a category called “Component” to a category called “Component Requirement” and meaning “affected by the”, a quantity specification of “1 –> 1..*” would mean that each component must be related to at least one component requirement, while each component requirement must be related to exactly one component.

In case of a “1->1” relationship, for example between the categories “Requiremen” and “Test Case”, ReqSuite® RM automatically creates an element of the category “Test Case” when creating a “Requirement” element and links them together.

Figure 1: Definition of relationship types

When defining a relationship type, four additional propertys can be defined.

First of all, a model representation for the relationship can be chosen. This property, however, is only relevant, if both the source and target category have already been categorized with a model type which is only relevant if an automatic exchange with modeling tools such as Enterprise Architect are necessary.

The property “Define relationship attribute” allows specifying whether or not additional information can be attached to a relationship of this type in a project. A possible use case is a declaration which relationship of a certain item to another is of highest importance.

The properties “Mark target when source changes” and vice versa are used for enabling an automatic impact analysis. As the label indicates changes on elements on one side of the relationship will automatically lead to notifications to the responsible user of the related elements and to  corresponding highlightings in the project. The same holds true if a new link is created.

To avoid duplications in the refinement view, the property „Show relationship in refinement tree” allows to set which paths should be visualized there. If, for example, a requirement is integrated transitively both via the requirements hierarchy and via the product structure, you can specify whether it should be accessible via both paths in the refinement tree, or only via one of them.