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

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.

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.

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.

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.

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.

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.

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.