ReqSuite® Requirements Manager (RM)

The following functions are available under the “Relationships” tab in the main display area of the Designer:

  • New relationships: Categories are in most cases related to each other in some way, i.e. certain aspects of their characteristics are mutually relational, which you can specify in more detail using this function. This may be because a content type such as the “interface” of a system to be built specializes in a more general content type such as “system part”, or because the “system” as a singleton category consists of several of these “system parts”. To define such primarily unidirectional relations between two categories, from source category (arrow origin) to target category (arrow tip), click on the button “New Relationship”. An input window opens (see Figure 1 on the left), in which you must enter different data depending on the type of relationship selected under “Stereotype *”:
    • containedIn: With this relationship type, the source category is a logical component of the target category, that is, you use it to express membership relationships. For example, a “business activity” is always part of a “business process” and therefore follows

                                         “Business Activity” — containedIn –> “Business Process”

The name of the relationship is typically “part of” and the reverse direction “consists of”. The
“cardinality” to choose determines the multiplicity, i.e. the quantitative dependence between
the two categories. In this case it could be obvious that a business process consists of at least
one business activity and that a business activity is contained in at least one business
process. Accordingly, the cardinality should be “1..*—>1..*” (see Figure 1, top left).

    • requiredBy: The source category is not a logical part of the target category for this relationship type, but is required to describe the target category either completely or to make it “functional”. For example, an “agent” is not part of a “business activity”, but is necessary to perform this business activity, so it follows

                                           “Agent” — requiredBy –> “Business Activity”

The name of the relationship here could be “responsible for the performance of …” and the
direction “performed by”. Under the assumption that one agent is responsible for several
business activities, and one business activity is performed by exactly one agent, “1—>*”
should be chosen as the cardinality (see Figure 1, center above).

    • influencedBy: The source category is neither a logical part of the target category for this relationship type, nor is it necessary to describe the latter completely or to make it “functional”. However, the design of the source category is influenced by the design of the target category. For example, a “target” is usually influenced by a “problem”, so the following applies

                                              “Target” — influencedBy –> “Problem”

In this case, the relationship name is uniquely determined bidirectionally by the
relationship type, so that you only have to select the source and target categories. The same
applies to cardinality, which is irrelevant for this relationship type (see Figure 1, bottom

    • specializes: The source category for this relationship type is a subtype of the target category. For example, a “core process” is a special type of “business process,” so that

                                                “Core Process” — specializes –> “Business Process”

The relationship name and cardinality are unique and have the following characteristics
not relevant (see Figure 1, centre bottom).

Figure 1: Dialog boxes for adding (top and bottom left), editing (top and bottom right) and deleting (bottom center) different types of relationships.

To edit an existing relationship between content categories, click the “pencil icon” in the last column of the corresponding table row. An edit window will open that is similar in content and functionality to the previously discussed input window for a new relationship. The only exception is the fact that you cannot change the source or target category of an existing relationship (see Figure 1, center).

You can irrevocably delete a relationship between categories from the system by selecting it in the corresponding list, clicking on the “trash can symbol” in the list header and clicking the “Ok” button in the query dialog that appears (see Figure 1 on the right). Each of the previously mentioned operations can be aborted by clicking on “Cancel” in the respective dialog box (see Figure 1).

Hints and rules:

When naming relationships between categories, make sure that the sentence is linguistically correct and logically appropriate according to the following sentence patterns:

  • Configuration language “German”: “Determine the <source category> that is the <relation with “…” as placeholder for instance of the target category><instance of the target category>”.
  • Configuration language “English”: “Ask for the <source category> that is/are <relationship><instance of target category>.

For the name of the relationship redirection, one can form a complete sentence according to the following sentence pattern:

  • “<destination category><relationship (redirection)>< instance of source category>”

When defining a “specializes” relationship between content types, the target category must first be defined as an “abstract” in order to be able to select it in the dialog box for creating or editing a relationship. The abstract category is then no longer available as the source category for another specializes relationship, since the system only allows single inheritance.

Note that the maximum depth of inheritance when using specialize relationships is 1 (Example: If “core process” specializes the category “business process”, then neither “business process” may specialize another category, nor “core process” may be specialized by another category).

Except for a “specializes” edge between a specialized and the specialized abstract content type, there may only be one edge of another relationship type between two content types (example: “specializes”): If “core process” specializes in the category “business process”, then “business process” may, for example, have a “containedIn” relationship with “core process”, but no further relationship of any type between these two categories is permitted).

Make sure that there are no cycles when defining relationships between content types (example: “agent” is responsible for “business activity” and “business activity” is part of “business process”). In this case, “business process” must not have a relationship to “agent” such as “involved”.)

To resolve possible cycles in the model graph, which can be formed from the relationships as edges and categories as nodes, the checkbox “Ignore in Process Guide” should be activated for affected relationships between content types. This leaves these out of the way when generating the order of work instructions for the plug-in, so that cyclic processing paths can be avoided (see Figure 1).

For more hands-on details on content type relationships in ReqSuite, please take a look at the following tutorial video: