Configuring Suspect Logic

Overview

Changes in a requirement may create a need to review linked requirements (or other types of issues) that depend on it. easeRequirements will allow you, in the future, to create a fine-grained “suspect logic” that alerts users to issues that need review due to changes in linked requirements. While this monitoring is not yet available as a built-in feature, it is recommended to use Jira Automation in order to approximate the functionality. The logic takes the form of project-specific automation rules that specify which fields are to be monitored for changes, the scope of a change (i.e. whether it affects upstream or downstream requirements and which link types are to be examined) and the users that are to be notified when suspects are discovered. Global automation rules could be used to monitor changes for all/many projects.

Jira Configuration

The Jira System Administrator should create a multi-line text field named e.g. “easeRequirements Suspect”. This field is used to provide Information about suspect links and support the review of such links.

Creating a Suspect Logic Rule

To configure rules for suspect logic, you need to be a Global or Project administrator.

  • For a global rule, go to Jira Settings > System > Global Automation.

  • For a project-specific rule, go to Project Settings > Automation.

Follow the steps below to set up an automation rule.

Step

Action

Explanation

Step

Action

Explanation

Create a new rule

Select the Create rule button.

 

Create a trigger for the rule

Select the trigger Field value changed in section Issue Triggers.

The rule is triggered when one or more fields of an issue are changed.

Define fields for the trigger

Select the fields to be monitored for changes when an issue is edited:

In this example, whenever the field Description is edited the rule is triggered.

Add project restriction (optional for a global rule)

Create new condition: Issue fields condition:

 

If a rule is project-specific the restriction to that project is assumed and this condition is not needed. If a rule is global, it can still be limited to certain projects by adding this condition.

Further restriction, e.g. to issue types or via JQL could be applied.

Store issue key in variable

Select new action Create variable in section Advanced:

 

The variable changedIssue is used to store the issue key for use later in the rule. Specify{{issue.key}}as the “smart value”.

Process linked issues

Select new branch Branch rule / related issues:

 

This branch runs through all issues that are linked with a given set of link types. You need to specify the name of the link types to be considered by this rule from the point of view of the issue that is changed, not from the point of view of the related issue. The following example clarifies this:

  • You have a link type that relates requirements to test cases. The name of the link type indicates the direction, which depends on the point of view. From the point of view of the requirement, you say it “is tested by” a test case. From the point of view of the test case, you say it “tests” the requirement.

  • When a requirement changes, the related test case is suspect and needs to be reviewed, and you want the rule to monitor this situation.

  • The rule must be stated from the point of view of the requirement (not the test case), so you should select “is tested by” as the name of the link type.

Modify linked issue

Select new action on branch: Edit issue:

 

Here you specify the following two changes to the linked issue to mark it as suspect:

  • In the option Choose fields to set, select the label to identify the issue as suspect.

You are free to use any label, but take care to avoid using a label that conflicts with other labels.

  • Under More options, specify the following string in Additional fields:

{
"fields": {
"easeRequirements Suspect": "{{issue.easeRequirements Suspect}}Linked issue {{changedIssue}} has changed, please check effect\n"
}
}

This results in a line being added to the custom field “easeRequirements Suspect”.

Add notification (optional)

Select new action on branch: Send email in section Notifications.

 

Specify the the user roles, single users or groups to be notified, as well as the subject and content of the email. Here are suggested values:

  • To: Reporter, Assignee

  • Subject: Issue {{issue.key}} is going suspect!

  • Content: Hello Jira user, please check issue {{issue.key}} for completeness as the linked issue {{changedIssue}} was modified. Best Regards, your Jira System

Enable the rule

Provide a name for the rule and then enable it by selecting Turn it on.

 

 

Clear easeRequirements Suspect field when Suspect Label removed

To remove the growing entries in the easeRequirements Suspect field, someone could setup this rule to clear the field.

Step

Action

Explanation

Step

Action

Explanation

Create a new rule

Select the Create rule button.

 

Create a trigger for the rule

Select the trigger When: Value changes for in section Issue Triggers.

The rule is triggered when a fields of an issue changes.

Define fields for the trigger

Select the Labels fields for any changes by any operation:

 

Select the Labels field for any change type for edit issue, create issue, assign issue and workflow transition (if they apply to your uses case)

Check the change log

Select the {{smart values}} condition:

 

Check if the change log contains the value “Suspect”

{{#changelog.labels}}{{fromString}}{{/}}

Check the label field

Select the Issue fields condition:

Check if the “Suspect” value is removed from the labels field.

Clear the Suspect field

Execute the Edit issue action:

 

Select the Suspect field to be cleared.
(Image shows “R4J suspect” custom field, could be any field defined above)

Enable the rule

Provide a name for the rule and then enable it by selecting Turn it on.