Requirements Interchange Format Avatar
  1. OMG Specification

Requirements Interchange Format — All Issues

  • Acronym: ReqIF
  • Issues Count: 13
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Allowed source and target elements on SpecRelationType level

  • Key: REQIF12-3
  • Legacy Issue Number: 17554
  • Status: closed  
  • Source: Fraunhofer FOKUS ( 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

AttributeDefinition should allow mutliplicities for attribute values

  • Key: REQIF12-2
  • Legacy Issue Number: 17553
  • Status: closed  
  • Source: Fraunhofer FOKUS ( 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

AttributeValue should not be subclass of Identifiable

  • Key: REQIF11-10
  • Legacy Issue Number: 18148
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    The class description of AttributeValue states that AttributeValue is a subclass of Identifiable. This is not correct according to the ReqIF model and the ReqIF XML schema, which state that AttributeValue has no super class.

    Making AttributeValue a subclass of Identifiable in the specification was simply a copy and paste error during initial specification creation, as AttributeValue instances can uniquely be identified by their related SpecElementWithAttributes and AttributeDefinition (both have identifiers).

    So the proposal is: remove the Generalization relationship between AttributeValue and Identifiable in the text of chapter 10.8.12 of the specification.

  • Reported: ReqIF 1.0.1 — Tue, 9 Oct 2012 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    Remove the Generalization relation to Identifiable in the class description of AttributeValue.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Missing class description for SpecElementsWithAttributes

  • Key: REQIF11-9
  • Legacy Issue Number: 18147
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    The description of the very fundamental metaclass SpecElementWithAttributes is missing in the ReqIF class descriptions sections. This is a pure editorial issue, but important to be resolved since SpecElementWithAttributes is one of the central metaclasses of the abstract syntax.

  • Reported: ReqIF 1.0.1 — Tue, 9 Oct 2012 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    Add a class description for SpecElementWithAttributes

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Specification inconsistencies and misspelllings

  • Key: REQIF11-8
  • Legacy Issue Number: 16399
  • Status: closed  
  • Source: SODIUS ( Philippe Soulard)
  • Summary:

    §10.2 p29 Fig10.2: Identifiable-AlternativeID composition, ident back linkage is named (with multiplicity) but shown as not navigable, the §10.8.2 p39 is unclear
    §10.6.2 p36 Fig10.11: EnumValue-EmbeddedValue composition, properties role name, but multiplicity is 1 -> either * multiplicity or property role name
    §10.6.3 p37 Fig10.12: AttributeValueXHTML dual compositions, if treated as compositions, duplicate back linkage attributeValue role names -> better treated as attributes (similar strong composition)
    §10.8.3 p40 : AttributeDefinition, on composition, specType back linkage multiplicity should be 1 (and shown as 1 in Fig10.3 p30 ) -> 1 multiplicity
    §10.8.9 p46 : AttributeDefinitionSimple associations (including composition) are redundant (when implemented) with associations of concrete realizations (AttributeDefinitionInteger, Boolean, Date ...)) -> to be removed
    §10.8.18 p53 : AttributeValueSimple associations : same as AttributeDefinitionSimple -> to be removed
    §10.8.18 p54 : AttributeValueSimple : description and semantics are identical -> precise Semantics if required
    §10.8.20 p55 : AttributeValueXHTML : already noticed -> theValue and theOriginal should better be considered as attributes
    §10.8.28 p64 : DatatypeDefinitionString, maxLength attribute, spelled in lower cases, but spelled with a L upper case in Fig10.9 &10.10 -> maxLength for consistency
    §10.8.30 p66 : EmbeddedValue : description and semantics are identical -> precise Semantics if required
    §10.8.31 p66 : EnumValue : misspelling in role name of back linkage to DatatypeDefinitionEnumeration, missing 'y' and 'T' shoulf be 't' for consistencies -> datatypeDefEnum
    §10.8.31 p66 : EnumValue : properties association role name while 1 multiplicity, already mentioned
    §10.8.31 p67 : EnumValue : description and semantics are identical -> precise Semantics if required
    §10.8.32 p67 : Identifiable : oonstraint #2 are redundant with Identifier attribute description
    §10.8.35 p70 : ReqIFContent associations : redundant composition association with RelationGroupType and with SpecType
    §10.8.36 p71 : SpecHierarchy : description and semantics are identical -> precise Semantics if required
    §10.8.37 p73 : Specification : description and semantics are identical -> precise Semantics if required
    §10.8.40 p75 : SpecObjectType back linkage associations : redundant back linkage with SpecType, back to ReqIFContent
    §10.8.41 p76 : SpecRelation : description and semantics are identical -> precise Semantics if required
    §10.8.42 p77 : SpecRelationType back linkage associations : redundant back linkage with SpecType, back to ReqIFContent

    => the documentation should better be automatically generated from the UML model (document and diagrams would be consistent). Or at least, one should implement this metamodel from the spec in a tool to check the consistency.

  • Reported: ReqIF 1.0.1 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    As this issue mentions several topics, each paragraph and the disposition for it is listed in the following table. As the disposition is either resolved or closed, this issue is considered resolved. see pages 7 - 8 of dtc/2012-11-01 for more details

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Associations of RelationGroup are limited to XML document scope

  • Key: REQIF11-7
  • Legacy Issue Number: 16014
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    ReqIF uses two distinct ways to reference XML identifiers in its XML schema:
    1. LOCAL-REF (which is used for XML references within the same XML document) and
    2. GLOBAL-REF (which is used for arbitrary, meaning document scope or cross document, XML references).
    By mistake, the XML references representing the associations of the RelationGroup type have been made LOCAL-REF references.

    The consequence of the mistake is: the source specification and target specification associated to a RelationGroup instance must be contained in the same XML document as the RelationGroup instance, or otherwise the references would be broken and the XML document would not validate against the ReqIF XML schema.

    Putting both the source specification, the target specification and the relation group in one XML document can significantly increase the size of XML documents.
    Even more important, it would affect almost all exchange processes between companies and their suppliers who use older (pre-OMG) versions of Requirements Interchange Format, as they have been able to exchange single specifications and relation groups separately with these older versions.
    This would be a step backwards for these companies and reduce their willingness to use tools that adopt the ReqIF standard.

    Resolution:
    Simply change two XML attributes in the ReqIF XML schema (lines: <xsd:element name="SPECIFICATION-REF") from LOCAL-REF to GLOBAL-REF as shown below :

    Before resolution of the issue:
    <xsd:complexType name="RELATION-GROUP">
    <xsd:all>
    …
    <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    …
    <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    …
    </xsd:complexType>

    After resolution of the issue:
    <xsd:complexType name="RELATION-GROUP">
    <xsd:all>
    …
    <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    …
    <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    … </xsd:complexType>

    As a side effect, the XML namespace needs to based on a new date (page 84 of the beta2 specification).

  • Reported: ReqIF 1.0.1 — Wed, 9 Feb 2011 05:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    Change two XML attributes in the ReqIF XML schema dtc/10-12-14, (lines:
    <xsd:element name="SPECIFICATION-REF") from LOCAL-REF to GLOBAL-REF as
    shown below :

    Old text:
    <xsd:complexType name="RELATION-GROUP">
    <xsd:all>
    ...
    <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    ...
    <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:LOCAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    ...
    </xsd:complexType>

    New text:
    <xsd:complexType name="RELATION-GROUP">
    <xsd:all>
    ...
    <xsd:element maxOccurs="1" minOccurs="1" name="SOURCE-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    ...
    <xsd:element maxOccurs="1" minOccurs="1" name="TARGET-SPECIFICATION">
    <xsd:complexType>
    <xsd:choice maxOccurs="1" minOccurs="1">
    <xsd:element name="SPECIFICATION-REF" type="REQIF:GLOBAL-REF"/>
    </xsd:choice>
    </xsd:complexType>
    </xsd:element>
    ... </xsd:complexType>

  • Updated: Fri, 6 Mar 2015 23:15 GMT

XHTML integration does not work as expected

  • Key: REQIF11-6
  • Legacy Issue Number: 16013
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    A key feature of the Requirements Interchange Format is the ability to exchange formatted content (e.g. bulleted lists, text with fonts applied etc.) between requirements authoring tools.
    Transporting formatted content is implemented in ReqIF by the use of W3C’s XHMTL, and the XHTML integration does not work as proposed in the beta2 version of ReqIF, rendering the format almost useless for non-trivial exchanges.

    Background:
    In earlier, “non-OMG” versions of the Requirements Interchange Format, XHTML had already been incorporated, but using a proprietary, customized XHTML schema.
    For better compliance with international standards, XHTML has been incorporated using a XML schema driver for the beta2 OMG version.

    As only a subset of XHTML should be included, the project group needed to incorporate so-called XHTML XML schema “modules”, which proved to be a complex task.
    Not until the implementation of a ReqIF based transformation tool, it turned out that some XHTML element definitions were not pulled in from the W3C modules, but only their XML schema types.

    This currently makes it impossible to use these XHTML elements in XML documents conforming to the ReqIF XML schema.

    Resolution:
    Rewrite the XHTML schema driver (which incorporates XHTML in ReqIF), in a way that all needed XHTML elements can be used in ReqIF XML documents.
    In other words: replace the file driver.xsd with a new version that works as expected and adapt chapter 11.4 of the specification, which shows the content of driver.xsd, accordingly.
    This new version has already been created and tested by ProSTEP.

  • Reported: ReqIF 1.0.1 — Wed, 9 Feb 2011 05:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    Replace the ReqIF 1.0 driver.xsd file (dtc/10-12-15) by the revised version
    dtc/11-02-12, and adapt chapter 11.4 of the specification dtc/10-12-11,
    which shows the content of driver.xsd, accordingly.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Move Annex A (Mapping Table) to implementation guide

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

    As stated in issue 15436, the implementation specific, informative part of the ReqIF specification should be factored out in a separate implementation guide.

    As the mapping table belongs to the implementation specific part, it should become part of the implementation guide as well.

  • Reported: ReqIF 1.0.1 — Mon, 11 Oct 2010 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    Remove the contents of Annex A. Also, all references made to the Annexes in
    the text need to be updated.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Remove inconsistency in AttributeValueEnumeration description

  • Key: REQIF11-5
  • Legacy Issue Number: 15717
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    Section 10.8.15 "AttributeValueEnumeration" states:

    "NOTE: The definition association references an AttributeValueEnumeration element [..]"

    This is obviously wrong and should read:

    "NOTE: The definition association references an AttributeDefinitionEnumeration element [..]"

  • Reported: ReqIF 1.0.1 — Mon, 11 Oct 2010 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    Replace the text as described in the issue.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

XHTML schema import should be more inclusive

  • Key: REQIF11-3
  • Legacy Issue Number: 15437
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    The way the XHTML schema is imported in the ReqIF XML schema works for some tools (like XML Spy 2010 or Eclipse Web Tools Plattform),
    but leads to validation errors in other tools (like Eclipse Standard xsd-validator and Eclipse EMF generator).

    There is an easy way to make validation work for all of those tools by incorporating a separate XML schema driver file.
    Such a XML schema has been worked out already by supporters/submitter of the specification.

    Section 11.4 of the specification needs to be adapted to reflect the new XML schema.

  • Reported: ReqIF 1.0.1 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    As the issue describes, a driver file needs to be created – this is the normative
    XML schema driver.xsd. Instead of the previous way of importing XML schemas,
    only the driver file is imported.
    Additionally, clause 11.4 needs to be adapted to reflect the change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Associate RelationGroup to source specification and target specification

  • Key: REQIF11-1
  • Legacy Issue Number: 15435
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    In the RFC, a "RelationGroup" element is associated to "specRelations".

    However, in contrast to prior versions of the Requirements Interchange Format,
    the ReqIF RFC does not account for the fact that grouped relations should either link
    requirements of two specifications (e.g. Customer Requirements Specification and
    System Requirements Specification) or requirements within one specification.

    Thus, two associations should be added to "RelationGroup", called "sourceSpecification" and
    "targetSpecification" to point out the specifications in which the
    source "SpecObject" elements and the target "SpecObject" elements connected by
    the "specRelations" are located.

    Note that having these associations in place would also greatly increase performance of ReqIF tool
    implementations.

    An additional constraint should be added to the RelationGroup section that defines that the "specObject" elements
    connected by the "specRelations" must be referenced by a (SpecHierarchy element) of the respective specification.

  • Reported: ReqIF 1.0.1 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    Update the textual description and the diagrams shown in the specification, the
    machine-readable file reqif.cmof and the XML schema file reqif.xsd to reflect the
    change as described in the issue.
    Also, update the textual description of SpecRelationType to clarify the distinction
    to RelationGroup.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Remove Annex B

  • Key: REQIF11-2
  • Legacy Issue Number: 15436
  • Status: closed  
  • Source: ProSTEP iViP Association ( Bertil Muth [X] (Inactive))
  • Summary:

    Remove the non-normative Annex B "Hints for Implementing ReqIF tools",
    as it is a legacy artefact from earlier RIF specifications and may be
    contradictory to the contents of the specification.
    Factor out implementation specific content in a separate, informative
    "Implementation Guide".

  • Reported: ReqIF 1.0.1 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — ReqIF 1.1
  • Disposition Summary:

    As the issue says, remove Annex B. Then, include a description pointing to the
    implementation guide

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Class descriptions are incomplete

  • Key: REQIF101-1
  • Legacy Issue Number: 15311
  • Status: closed  
  • Source: Heinrich-Heine UniversitäDüorf ( Michael Jastram)
  • Summary:

    According to the diagram on page 39, Specification, SpecObject, SpecRelation and RelationGroup all have an association named "type" to their respecive SpecType. This association is missing from the corresponding class descriptions in section 10.8.

  • Reported: ReqIF 1.0 — Mon, 28 Jun 2010 04:00 GMT
  • Disposition: Resolved — ReqIF 1.0.1
  • Disposition Summary:

    The statement of the issue has been verified, it is true. While the model contains
    the “type” associations, the specification text does not reflect that.
    Therefore, a “type” association needs to be added to the class descriptions
    mentioned in the summary

  • Updated: Fri, 6 Mar 2015 23:15 GMT