Overview

Changes in a requirement may create a need to review linked requirements (or other types of issues) that depend on it. easeRequirements allows you to create a fine-grained “suspect logic” that alerts users about requirements that need review due to changes in linked requirements. The logic takes the form of rules that specify which fields are to be monitored for changes, which link types are to be examined, and the users that are to be notified when suspects are discovered.

The suspect rules are organized as schemes that can be shared by multiple projects.

Configuring suspect schemes can be challenging, so a detailed example has been provided - see Example of configuring a suspect scheme.

1 Overview
2 Configuring Suspect Schemes
- 2.1 Linked Issues as trigger for suspects
3 Example of configuring a suspect scheme

Configuring Suspect Schemes

To configure rules for suspect logic, you need the "Suspect Configuration" user permission - see Managing User Permissions.

In the easeRequirements Navigation Bar select More features and settings > Suspect Schemes. A list of all existing suspect schemes is displayed. The following actions are available:

Purpose	Action	Comment

Purpose

Action

Comment

Create scheme

Select the option Add New Suspect Scheme and specify the following options:

Name: The name of the scheme.
Projects: The projects that share the scheme.
Query: The query used to identify specific issues that may trigger the suspect mark for this configuration. If you want all issues in the project to trigger a suspect mark, leave this option empty.
Monitor Fields: Select the fields you want to be monitored for changes. Choose <All fields> if you want all fields to be monitored.

Link Types: Select the link types that you want to be in the scope of the scheme. Choose All Types if you want all types of links to be included.
Scope: Select whether only downstream relationships (what Jira calls “outward” links), upstream relationships (“inward” links), or both are to be considered.
Notifiction: Optionally select specific users or projects roles that receive a notification when a requirement is marked as suspect.
Select Add to create the scheme, which takes immediate effect.

To avoid being overwhelmed by links incorrectly getting marked as suspect, think carefully about which fields are selected here. Only those fields that, if changed, might necessitate changes in related requirements should be included. The requirement description is an obvious candidate, since a change in a requirement’s description may necessitate coordinated changes in related requirements. But a change in, say, the assignee of a requirement probably has no impact on related requirements.

Modify scheme

Select Edit, modify the configuration as desired, and select Update.

Delete scheme

Select Delete and select Delete.

Linked Issues as trigger for suspects

There may be a need for requirements to mark newly linked issues as suspects to check its impact on requirements. When linking an existing issue or creating a new link, regardless of the scope indicated, the link between both changed and linked issue will be marked as a suspect since it is identified equally as a change for both.

The revision may also show the issue keys in the “R4J Suspect“ revision interchangeably (in the example below, ABC-123 and ABC-456) since Jira does not provide the direction which the links are created.
Example of an “R4J Suspect“ revision: R4J Suspect: Suspect set in ABC-123 due to change in ABC-456

Example of configuring a suspect scheme

The following example describes a possible situation in requirements management, explains what we want to accomplish with a suspect scheme, details how to configure the link type in Jira, and how to configure the suspect scheme in easeRequirements.

Suppose we have high-level requirements and lower-level specifications of those requirements. We represent these with two issue types, Requirement and Specification. We link related Requirements and Specifications together using the link type Specification. We describe the relationship as follows:

Requirement A is specified by Specification B.
Specification B specifies Requirement A.

This leads to the following link type configuration in Jira:

Name	Outward Description	Inward Description

Name	Outward Description	Inward Description
Specification	specifies	is specified by

When a Requirement is changed we want to review the related Specification to check if any changes are needed. But a Specification can be changed without necessarily requiring a review of the related Requirement. With this in mind, we create the following suspect scheme:

Option	Value	Explanation

Option	Value	Explanation
Name	review specifications of changed requirements	This is simply a name by which you can recognize the purpose of the scheme.
Projects		The projects that share the scheme.
Query	issuetype = “Requirement“	Only issues of type “Requirement” will trigger a suspect mark for the Fields and Link Types indicated in this configuration.
Fields	Description	Only changes in the Description field are of interest. If there are other fields where changes might require a review of the linked specification, they can be added here.
Link Types	Specification	The rule in this scheme only applies to links of this type.
Scope	Upstream Only	Given Requirement R and Specification S, such that “R is specified by S” we select the option “Upstream Only”. “Upstream” simply stands for the inward link description, while “downstream” stands for the outward link description.
Notification		This option is set to the users, if any, that are to be alerted to events that lead to a link being marked as suspect. Information about suspect links is provided in other ways than notifications, so explicit notifications are not usually necessary - see Suspect Links.