Data Modeler: Managing Data Models
- David Sedlock
- Angelica Salazar
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.
To configure data models, you need the "Data Model Configuration" user permission - see Managing User Permissions.
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”.
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 (unless an external plugin with its own linking functionality is being used).
Unsanctioned links can 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.
Operations
Purpose | Action | Comment |
|---|---|---|
Create a data model |
|
|
Edit a data model |
|
|
Delete a data model |
|
|
Associate or disassociate projects from a data model |
|
|
Activate a data model |
| |
Add a rule |
|
|
Edit a rule |
| |
Delete a rule |
|
|