Workflows in ReqSuite® RM define states in which the elements of a certain category can be, the conditions that apply in these states, and valid transitions from one state to another. In the context of ReqSuite® RM, workflows must not be confused with processes that define a sequence of content-related work steps. However, the latter can be realized via relationship types and the assistance function of work suggestions.

For defining workflows, the following steps are important (see Figure 1):

Workflow Creation & Assignment

The first step is the creation of the workflow itself. The only property to be defined is the name of the workflow. All other details are then managed via states and transitions. For making the elements of a certain category follow this workflow, the workflow has to be assigned in the category’s editing window. In this regard, it is important to note that

• not every category needs to have a workflow
• every category can (theoretically) have another workflow

State Definition

The second step is the definition of the states of the workflow (see Figure 1). Besides the name and the color of the state, the following properties can be specified.

Description

The description property allows providing information about the purpose of the state and is displayed to end users as a tooltip.

State is start state

This property identifies a state as the start state of the workflow. For the purpose of uniqueness, each workflow can have only one start state.

State is end state

This property identifies a state as an end state of the workflow. Unlike start states, each workflow can have multiple end states, e.g., rejected and implemented.

Items in this state are read-only

This property specifies that elements that are in this state are locked for editing, i.e., they are read-only.

Items in this state will not be exported

This property can be used to specify that elements that are in this state are not exported via the interfaces of ReqSuite® RM. This applies to document exports such as Word, Excel, etc. as well as to the exchange with other tools such as JIRA, TFS, etc.

Items in this state will not be baselined

By using this property, it can be defined that elements that are in this state will not be included in a created baseline.

Items in this state allow being explicitly reviewed

This property is necessary for defining review and approval workflows. In particular, when an item is set to a state with this property, all users who have the role of a reviewer in the corresponding project are automatically invited to submit a rating. Also, a rating scale is automatically added to the comment field in the editing window.

State can only be set by project administrators and assigned groups

This property can be used to specify that only project administrators and members of the assigned group can set the corresponding state. Similar to the previous property, this property plays a role in approval workflows. For example, if there is an “approved” and a “rejected” state, it would make sense to set this property for both, otherwise each (normal) user could accept or reject a request by himself/herself.

Set state automatically when all derived elements are in this state

This property allows to set the associated state automatically if elements derived from the respective element are already in this state. Derived elements are those that are related to the element as a source. Two aspects are important to consider with this property:

• The automatic setting works only if all derived elements are actually in this state. The only exception are elements whose category has no workflow.
• The condition is checked by name matching. This means that the derived elements do not have to follow the same workflow, but the name of the state that triggers the automatic setting must have the same name.

Changes in this state do not lead to an impact analysis

This last property allows to disable the impact analysis for this state. So, if an element is changed in this state, related elements will not be marked as affected, even if the corresponding relationship types have been configured for impact analysis. This is useful in early stages of development, for example.

Transition Creation

The last step during workflow definition, is the creation of transitions between the different states. Since this is self-explanatory, it will not be explained in detail.