Issues for Mailing list of the Requirements Interchange Format V1.2 (ReqIF) Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 17553: AttributeDefinition should allow mutliplicities for attribute values
Issue 17554: Allowed source and target elements on SpecRelationType level
Issue 18784: Implementation Guide

Issue 17553: AttributeDefinition should allow mutliplicities for attribute values (reqif-rtf)

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

An implementation of the above requirements would require a change to the ReqIF model. The impact of such a change on the existing ReqIF implementations is unclear and needs further analysis. The ReqIF1.1 RTF, including the issue’s author Marc-Florian Wendland, agreed that changes to the ReqIF model should currently be omitted for standard stability.
Parts of the requested functionality can already be achieved using the ReqIF1.0.1 standard: by using an AttributeDefinitionEnumeration element with multiValued set to true, multiple string literals can be referenced from each SpecObject instance.
This issue will be reconsidered in a future RTF.
Disposition: Deferred

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.

An implementation of the above requirements would require a change to the ReqIF model. The impact of such a change on the existing ReqIF implementations is unclear and needs further analysis. The ReqIF1.1 RTF, including the issue’s author Marc-Florian Wendland, agreed that changes to the ReqIF model should currently be omitted for standard stability.
Parts of the requested functionality can already be achieved using the ReqIF1.0.1 standard: by using two Specification instances, each instance referencing only SpecObjects of one SpecObjectType, and then using a RelationGroup with a sourceSpecification attribute and targetSpecification pointing to the above Specification instances. The SpecRelation instances referenced by that RelationGroup instance are thereby constrained to use only SpecObject elements from the above Specification instances.
This issue will be reconsidered in a future RTF.
Disposition: Deferred

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.