Versions Compared

Old Version 2

changes.mady.by.user Angelica Salazar

Saved on

compared with

New Version Current

changes.mady.by.user Angelica Salazar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: REQ-20129: Official release

Overview

Traceability is an important concept in Requirements Management. If, say, a project breaks down customer requirements into functional requirements, then it wants to be able to check that a given customer requirement can be traced to one or more functional requirements and that a given functional requirement can be traced to a customer requirement. This is achieved in Jira by linking issues using a link type such as Trace, with the outward description “traces to” and the inward description “traces from”. A Customer Requirement traces to a Functional Requirement and a Functional Requirement traces from a Customer Requirement.

Jira itself places no restrictions on how links are used: Any type of issue can be linked to any other type of issue via any link type in either direction. This allows users to easily make mistakes in linking requirements, resulting in requirements being linked together with the wrong link type or in the wrong direction, thus leading to problems in checking traceability.

easeRequirements Ultimate for Jira solves this problem by providing a Data Modeler, which is used to restrict which link types are available and how they are to be used with given issue types. For example, a data model may include a rule that says that the link type Trace can only be used between the issue types Customer Requirement and Functional Requirement and that the link direction can only be from the former to the latter.

Info

To configure data models, you need the "Data Model Configuration" user permission - see Managing User Permissions.

Table of Contents
minLevel1
maxLevel6
outlinefalse
stylenone
typelist
printabletrue

Administration

User Interface

A data model consists of a number of rules and is displayed as a table with each row describing one combination of a link type and two issue types (source and destination). Here is an example of a rule:

Customer Requirement

traces to

Functional Requirement

The rule states that a link of type Trace is allowed to be created from an issue of type Customer Requirement to an issue of type Functional Requirement.

The link type is designated by its outward description (“traces to”), not by its name (“Trace”). A rule is understood to apply also in the reverse direction (“traces from”). That is, with the rule shown above, a link of type Trace can be created between an issue of type Functional Requirement and an issue of type Customer Requirement using the inward link description “traces from”.

Note

The rules in a data model are completely restrictive. That is, every link in a project using a model should be sanctioned by a rule. In this example, if this is the only rule in the data model, then the only links that should be created in a project using the model are Trace links, and that link type should only be used for issues of the types Customer Requirement and Functional Requirement, where the former is the source of the link and the latter is the destination.

Activated vs. non-activated data models

A data model states what should be the case for links in projects associated with the model, but doesn’t in itself ensure conformity. Activating a data model results in the model being consulted in projects using it when links are created in Jira and easeRequirements. : Unsanctioned links cannot be created when a data model is activated .

NoteThe data model is only consulted for links created in easeRequirements, not for links created via the native linking functionality of Jira itself in the Link dialog

(unless an external plugin with its own linking functionality is being used).

Unsanctioned links can still be created in projects using non-activated models or external plugins. In this case, the Data Model Checker can be used to identify and correct unsanctioned links. The checker can also be used after a data model has been activated to identify and correct previously created unsanctioned links or unsanctioned links created via the native linking functionality of Jira.

Operations

When creating or editing a rule, multiple issue types and link types can be provided. The resulting set of singular rules, one for each combination, is automatically generated

Purpose

Action

Comment

Create a data model

  • Go to Jira navigation > Requirements > Data Model EditorConfiguration.

  • Select Add New Data Model.

  • Enter a Model Name.

  • Optionally, select one or more projects that are to use the model.

Edit a data model

  • Go to Jira navigation > Requirements > Data Model EditorConfiguration.

  • Select the Edit icon next to the desired data model.

Delete a data model

  • Go to Jira navigation > Requirements > Data Model EditorConfiguration.

  • Select the Delete icon next to the desired data model.

Associate or disassociate projects

with

from a data model

  • Go to Jira navigation > Requirements > Data Model EditorConfiguration.

  • Add or remove projects in the Projects option.

Activate a data model

  • Go to Jira navigation > Requirements > Data Model EditorConfiguration.

  • Check the option Active Status next to the desired data model.

See Activated vs. non-activated data models.

Add a rule

  • Open the desired data model.

  • Go to the end of the list of existing rules.

  • Specify the following options:

    • Issue Type (from): The source issue type(s).

    • Link Type: The outward description of the link type(s).

    • Issue Type (to): The destination issue type(s).

  • Select Add.

  • .

Edit a rule

  • Open the desired data model.

  • Modify the options of an existing rule.

  • Select Update.

Delete a rule

  • Open the desired data model.

  • Select Delete next to the desired rule.