Requirements Interchange Format Avatar
  1. OMG Specification

Requirements Interchange Format — All Issues

  • Acronym: ReqIF
  • Issues Count: 4
  • Description: All Issues
Closed All
All Issues

Issues Descriptions

AttributeDefinition should allow mutliplicities for attribute values

  • Key: REQIF12-2
  • Legacy Issue Number: 17553
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Section 10.3 says: "What is actually shared among the requirements is the requirement attribute definitions (the number of attributes, the names of the attributes, the default values for the attributes, and the datatypes of the attributes.)"

    However, there is no possibility to allow more than one value for an attribute of a SpecType. This is a very fundamental conecept and should be provided by ReqIF 1.1.

    A potential solution might be the following:

    • Add a metaattribute upperValueBoundary to AttributeDefinition with default set to 1 (meaning, the attribute is allowed to have exactly one entry).
    • Add two more metaattributes to AttributeDefinition: isOrdered:Boolean = true and isUnique:Boolean = true to enable the user specifying the nature of a list of attribute values
    • Add a constraint to AttributeValue that ensures that the upperValueBoundary of the corresponding AttributeDefinition must be respected by an implementation
  • Reported: ReqIF 1.0.1 — Mon, 20 Aug 2012 04:00 GMT
  • Disposition: Closed; Out Of Scope — ReqIF 1.2
  • Disposition Summary:

    Take the issue out of scope, as it is a breaking change

    Implementing this issue would introduce a change to the ReqIF XML schema.
    This change to the XML schema would make ReqIF files that are valid against
    the new XML schema incompatible with previous ReqIF files, thus breaking
    interoperability with almost all tools that are on the market now (including
    tools by IBM, PTC, NoMagic and many others).

    As this is considered a major change, it should be taken out of scope for a RTF.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

Implementation Guide

  • Key: REQIF12-1
  • Legacy Issue Number: 18784
  • Status: closed  
  • Source: PTC ( Mr. Hedley Apperly)
  • Summary:

    As discussed at the co-located Req-IF/OMG meeting in Berlin (June 2013) it would be more in the spirit of OMG standard openness to include the non-normative recommendations for implementing the standard, in the standard document itself, rather than as a link to a non-OMG web site where there is a charge of 90 Euros to download the 'implementation guide'. This issue should be considered for resolution and could either result in; 1/ removal of section 12 Annex A from the specification, so that it stands alone, 2/ creating the 'implementation guide' as a freely available OMG document (still linked from the specification) or 3/ including the non-normative implementation guidelines as a section directly in the specification.

  • Reported: ReqIF 1.1 — Thu, 20 Jun 2013 04:00 GMT
  • Disposition: Resolved — ReqIF 1.2
  • Disposition Summary:

    Remove the reference - ProSTEP does not release implementation guide

    ProSTEP has a clear position on this:

    Implementation guides are not made public free of charge, as ProSTEP
    is the owner and the artifact has been created through a ProSTEP funded
    activity. (Implementation guides are common artifacts created by
    ProSTEP implementor forums.)

    So the proposal is: remove the reference from the standard.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

Unfinished sentence

  • Key: REQIF12-4
  • Legacy Issue Number: 19654
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    In the table of UC-1: Export Requirement Specifications > Main Success Scenario > Step 2, there is an unfinished sentence that reads:

    "The structure of the specifications."

    Request is to remove this sentence or incorporate its meaning in the text before.

  • Reported: ReqIF 1.1 — Tue, 4 Nov 2014 05:00 GMT
  • Disposition: Resolved — ReqIF 1.2
  • Disposition Summary:

    Remove the superfluous sentence

    As the mentioned sentence is not necessary or helpful to understand the rest of the text around it, and probably the results of a copy/paste error: just remove the sentence altogether.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

Allowed source and target elements on SpecRelationType level

  • Key: REQIF12-3
  • Legacy Issue Number: 17554
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Currently, any SpecObject can be associated with any other SpecObject by using a SpecRealtion. Even though this is very generic and flexible, it is prone to erros, since the user is not restricted by the type of a SpecObject that can be used as source or target element for SpecRelation. So, subsequent tasks have always to ensure that only allowed SpecObject can be linked with each other. Unfortunately, it is not possible to deposit the knowledge about what SpecObjects are allowed in the model itself.

    This situation can easily mitigated by adding a sourceType and targetType association to SpecRelationType. Further more, a constraint on SpecRelation must be defined that ensures that the only SpecObjects are linked as source and/opr target that adhere to the SpecRelationType source and target.

  • Reported: ReqIF 1.0.1 — Tue, 28 Aug 2012 04:00 GMT
  • Disposition: Closed; Out Of Scope — ReqIF 1.2
  • Disposition Summary:

    Take the issue out of scope, as it is a breaking change

    Implementing this issue would introduce a change to the ReqIF XML schema.
    This change to the XML schema would make ReqIF files that are valid against
    the new XML schema incompatible with previous ReqIF files, thus breaking
    interoperability with almost all tools that are on the market now (including
    tools by IBM, PTC, NoMagic and many others).

    As this is considered a major change, it should be taken out of scope of a RTF.

  • Updated: Tue, 29 Mar 2016 15:09 GMT