The options available in Requirement Coverage are:


A Jira re-index is recommended if there are changes to the Requirement Coverage options.

Requirement Coverage Strategy

The requirement coverage strategy defines how the Requirement Status must be calculated. The following strategies are available:

Use versioned Test Executions for Requirement Coverage

When this option is enabled, the Status of a Requirement for a specific Fix Version V is calculated based on the latest Test Run with Fix Version V of each associated Test. With this strategy, a Requirement can have different Statuses one for each Fix Version in the project.

Use versioned Test Sets for Requirement Coverage

When this option is enabled, Requirement Tests must be associated with Test Sets of a specific Fix Version to be considered for the Requirement Coverage of that particular version. A given Test T is considered for requirement coverage of Requirement R in the version V if:

Once Test T is considered for coverage in version V, its Status is calculated based on the latest Test Run with the specified Fix Version V.


Please see more info in the page dedicated to Requirements Coverage Analysis in the User's Guide.


Ignore Requirements with Status

Choose the workflow statuses for which the Requirement issues will not be included in Requirement Coverage Charts.

Ignore Requirements with Label

Choose the labels for which the Requirement issues will not be included in Requirement Coverage Charts.

Ignore Tests with Status

Choose the workflow statuses for which the Test issues will not be considered when calculating the Requirement Status, even if they are associated with Requirement issues.

Requirement Historical Chart Days

Specifies the default number of days that the requirement coverage historical chart must display when opened.

Separation of Concerns

When this option is checked, the result of a Test will affect all Requirements that are associated with it. Uncheck this option if a single Test result affects multiple Requirements in different ways and these might have different statuses depending on specific steps. This will allow you to manually set the affected Requirement statuses for each Test Run on the execution screen. The calculation of the Requirement Status will then consider these Requirement statuses explicitly. 

Test T1 is associated with Requirements R1 and R2: 

  • Checked: If the latest execution result of T1 has FAILED then both Requirements are NOK.
  • Unchecked: If the latest execution result of T1 has FAILED and this could only affect R2, then R1 can be OK and R2 is NOK.

Include Previous Version Requirements

When this option is checked, the option to include all Requirement issues of previous versions in Requirement Coverage charts will be checked by default.