DNG ReqIF Import shall import SPEC-OBJECTS with the same ReqIF ID as reused artefacts (as the same Base Artefact)

Description

DOORS Next has a concept for artefact reuse. A "Base Artefact" can be reused in different contexts, meaning for example in different modules or in different places in the same module. These artefacts are still all the same artefact, meaning for example that if the value of an attribute is changed for a reused artefact in one context, the artefact will be changed in all contexts.

The ReqIF Standard allows a SPEC-OBJECT (i.e. the equivalent of an artefact) with the same ReqIF ID to exist in different places in the same SPECIFICATION (i.e. the equivalent of a module) as well as in different SPECIFICATIONS (i.e. in different modules). In this way, artefact reuse can be modelled in ReqIF.

DNG ReqIF Import currently can only import a SPEC-OBJECT with a specific ReqIF ID into one context / as one “instance” – i.e. a SPEC-OBJECT with a specific ReqIF ID can only be imported into one module, as one “instance” of a potentially reused artefact. If there is a ReqIF file with a SPEC-OBJECT with the same ReqIF ID at different places in the same SPECIFICATION or different ReqIF files with a SPEC-OBJECT with the same ReqIF ID in different SPECIFICATIONS, DNG ReqIF Import will not import these SPEC-OBJECTS as reused artefacts.

Instead, the DNG ReqIF Import will fail in these cases.

DNG ReqIF Import shall import SPEC-OBJECTS with the same ReqIF ID as reused artefacts (i.e. SPEC-OBJECTS with the same ReqIF ID are imported as artefacts that all have the same Base Artefact).

Reason

The current implementation of the DNG ReqIF Import is unable to import SPEC-OBJECTS that use the same ReqIF ID but are in different positions, which is a valid way to model reused artefacts in ReqIF. DNG is only able to import reused artefacts if the tool-specific TOOL-EXTENSIONS exported by DNG ReqIF Export are available in the ReqIF. ReqIF Export tools are not obliged to use / provide these TOOL-EXTENSIONS.

Exporting reused artefacts with the same ReqIF ID is allowed in the ReqIF Standard and is, in our opinion, the correct way to model reused artefacts in ReqIF. Exporting reused artefacts this way should allow more tools import the SPEC-OBJECTS as reused artefacts (if RM Tool can handle reused artefacts) or at least recognise the information that the SPEC-OBJECTS represent reused artefacts (if RM Tool cannot handle reused artefacts).

Note / Suggestion

To distinguish the different reused artefacts at different positions within a module / in different modules, you could use different SPEC-HIERARCHY ReqIF Identifiers for the different "instances" / binding artefacts (in the SPEC-HIERARCHY part of the ReqIF).

This idea is related to the following idea:

"DNG ReqIF Export shall export reused artefacts (same Base Artefact) as one SPEC-OBJECT with the same ReqIF ID"

https://ibm-ai-apps.ideas.ibm.com/ideas/ENGRMDN-I-520

ReqIF Ranking

Idea priority

Medium

Post comment

Guest

Reply
| Oct 18, 2024

The ReqIF Implementation Guide 2.10 has now clarified how to represent objects that are reused in Requirements Authoring Tools in ReqIF. The above idea would be a valid implementation of this.

The relevant part of the ReqIF Implementation Guide 2.10 is as follows:
"2.18 How to represent objects that are reused in Requirements Authoring Tools in ReqIF

The ReqIF standard compliant way to export re-used objects is by exporting a single SpecObject and referencing that SpecObject from multiple SpecHierarchies (which might be part of the same or different Specifications).

When importing a reused SpecObject to a requirements authoring tool that doesn’t support reuse, and then exporting the object again, the process is:

If there are two or more copies of that reused object in the requirements authoring tool, consolidate them into one SpecObject in the ReqIF export. Use the original ReqIF identifier (as it was in the ReqIF file that has been imported) so that there’s again a single reused SpecObject, as in the ReqIF file imported before. "

The last paragraph is concerning requirements authoring tools that do not support reuse, wich would not be relevant here, as DOORS Next supports requirments reuse.

0 reply Hide replies

4 MERGED