ReqSuite® Requirements Manager (RM)
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 are not to 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
The second step is the definition of the states of the workflow (see Figure 1). Besides the name of the state, the following properties can be specified.
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
This property can be used to specify that only project administrators 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 last 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.
The last step during workflow definition, is the creation of transitions between the different states. Since this is self-explanatory, it will not be discussed in detail.
For more hands-on details on workflows, please take a look at the following tutorial video: