Issues for Mailing list of the Requirements Interchange Format V1.1 (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 16399: Specification inconsistencies and misspelllings
Issue 17553: AttributeDefinition should allow mutliplicities for attribute values
Issue 17554: Allowed source and target elements on SpecRelationType level
Issue 18147: Missing class description for SpecElementsWithAttributes
Issue 18148: AttributeValue should not be subclass of Identifiable

Issue 16399: Specification inconsistencies and misspelllings (reqif-rtf)

§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.

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

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.

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.

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.