Reviews, Coverage & Traceability

Reviews

What is a Review?

A review is a structured process for formally evaluating a set of requirements. When you create a review, the app creates a parent Jira issue to represent the review itself, and creates one child sub-issue for each named reviewer. Each reviewer's progress is tracked independently through Jira's own workflows and statuses.

Requirements are formally linked to the review issue so there is a clear, traceable record of which requirements were under review.

ℹ️ Note: The Reviews module requires Review Settings to be configured before it can be used. See Page 2 for setup instructions.

Navigating Reviews

Click Reviews in the left sidebar. The module has the following tabs:

Creating a Review

1. Click the Create tab in the Reviews module.

2. Fill in the form:

3. Click Create to submit.

The app will automatically:

• Create the parent review Jira issue

• Create one reviewer sub-issue per reviewer you added

• Link all selected requirements to the review

• Open the new review in a new tab

Reviewer Sub-Issues

Each reviewer in a review has their own dedicated Jira sub-issue. This makes it possible to track each person's review progress separately using Jira's built-in statuses and workflows.

In the review detail view you can:

• See each reviewer's name, status, and the number of comments they have left

• Click a reviewer to open their sub-issue for more detail

• Add additional reviewers after the review has been created

Viewing a Review

Click on any review in the Reviewer Tasks or Review Tasks lists to open it in a tab.

The review detail view shows:

• Review fields — editable fields for the review issue (summary, description, and any custom fields from your settings)

• Reviewers — all reviewer sub-issues with their current statuses

• Linked Requirements — the requirements linked to this review

• Linked Issues — any other linked Jira issues

• Comments — comments on the review issue

Filtering Reviews

In the Reviewer Tasks and Review Tasks tabs, use the filter controls to narrow the list:

Attribute Rules (Review Automation)

Attribute rules are automatic actions that run when a review reaches a specific status. They are configured in Settings → Reviews → Attribute Rules.

Example: When a review is set to "Closed", automatically update the "Approval Status" field on all linked requirements to "Approved".

Rules run automatically when the configured review status is reached — no manual action is needed. This ensures that requirement fields stay in sync with your review outcomes without extra effort.

Coverage

What is a Coverage Matrix?

A coverage matrix is a grid that shows the relationship between two sets of Jira issues. The most common use case is showing which requirements are covered by which test cases — but you can configure it for any pair of issue types connected by a Jira link type.

• Rows represent one set of issues (e.g. requirements)

• Columns represent another set (e.g. test cases)

• A cell in the grid is marked when a link of the chosen type exists between the row issue and the column issue

This gives you a clear visual answer to the question: "Which of my requirements have been tested?"

Creating a Coverage Matrix

1. Click Coverage in the left sidebar.

2. From the Coverage List tab, click Create.

3. Fill in the form:

4. Optionally click Preview to see a live preview of the matrix before saving.

5. Click Create to save. The new matrix opens in a tab automatically.

Viewing a Coverage Matrix

Click a coverage matrix name from the Coverage List to open it.

The matrix is displayed as a table. A checkmark or indicator in a cell means a link of the configured type exists between that row issue and that column issue.

You can click on a cell to create or remove a link directly from the matrix — no need to open the individual Jira issues.

Public vs. Private Coverages

• Private matrices are only visible to the person who created them.

• Public matrices are visible to all users of the project.

The Coverage List displays private and public matrices in separate sections.

Traceability

What is a Traceability Report?

A traceability report shows how issues are connected across multiple levels of your requirements hierarchy. Rather than showing a flat relationship between two sets of issues, traceability follows a chain — for example:

• Level 1: Business Requirements

• Level 2: System Requirements (linked to Level 1 via "derives from")

• Level 3: Test Cases (linked to Level 2 via "validates")

The report lets you answer questions like: "Can I trace this business requirement all the way to a test case?" or "Which business requirements have no test coverage?"

Creating a Traceability Report

1. Click Traceability in the left sidebar.

2. From the Traceability List tab, click Create.

3. Fill in the form:

For each level:

Click Add Level to add more levels to the chain. The first level is always the starting point — the top of your traceability chain.

4. Optionally click Preview to see a live preview before saving.

5. Click Create to save. The new report opens in a tab automatically.

Viewing a Traceability Report

Click a report name from the Traceability List to open it.

The report is displayed as a hierarchical table:

• Issues from the first (top) level appear as the main rows.

• Issues from the second level that are linked to a first-level issue appear indented beneath it.

• The chain continues downward for all configured levels.

This layout makes it straightforward to spot gaps — for example, a top-level requirement with no linked issues at the next level down.

Public vs. Private Reports

• Private reports are only visible to the person who created them.

• Public reports are visible to all users of the project.

The Traceability List displays private and public reports in separate sections.