SAIF-CD Compliance Statemenst for ISM

SAIF-CD Compliance_Statements for ISM

• SAIF CD-compliance SAIF Implementation Guide (SAIF IG) SHALL utilize IG-selected subsets (up to and including the whole) of the various SAIF CD languages to define SAIF IG-specific modeling grammars which are then collectively used within the SAIF IG to define and organize the various artifacts that collectively define the interoperability aspects of a given software component (e.g. service, message, document, etc.). Following are specific requirements for a SAIF IG relative to the canonical specifications and definitions presented in the SAIF CD.

Requirements for compliant SAIF IGs are organized using the ISO/IEC modal verbs: [[Modal_verbs}SHALL, SHOULD, MAY, SHALL NOT, SHOULD NOT, MAY NOT]].

• As such, a SAIF CD-conformant SAIF IG is required to fulfill, at minimum, all of the SHALL requirements. In addition, SAIF IG developers are encouraged to fulfill as many of the SHOULD requirements as are appropriate to the mission and goals of the organization for whom the SAIF IG is targeted. Although the distinction between SHOULD and MAY may seem somewhat fuzzy and qualitative, the general guideline applied for separating requirements into these two categories is to indicate to SAIF IG developers that Best Practices would encourage that all – or nearly all – of the SHOULD requirements be fulfilled over the course of the development of a specific SAIF IG, the MAY requirements being truly optional. The separation of the SHALL and SHOULD requirements is therefore to enable iterative development of a SAIF IG, the first version satisfying the SHALL requirements, and subsequent versions moving progressively through the SHOULD requirements prioritized according to organization-specific needs and ultimately reaching a relatively stable end-state where all (or nearly all) of the SAIF CD SHOULD requirements have been met. As mentioned above, MAY requirements are less critical and may only be appropriate for some organizations. The SAIF CD uses the SHALL NOT – to specify explicit negatives, i.e. practices/strategies that, if included in a SAIF IG, render that IG non-compliance with the SAIF CD. (This is a distinct departure from the “WON’T have of the original MuSCoW framework in which the “W” stands for “WON’T have but WOULD like to have in a future version.” )

• A SAIF Implementation Guide (SAIF IG) SHALL define at least one IG-specific Interoperability Specification Template (IST) which constrains and/or explicitly clarifies and instantiates the Behavioral, Informational, and Governance modeling languages defined in the SAIF CD as IG-specific modeling grammars.
• An IST SHALL contain five columns and three rows arranged in the order specified in the SAIF CD.
• An IST SHALL use the semantics of the columns as defined in the ODP and SAIF CD.
• An IST SHOULD use the semantics of the SAIF CD for the semantics of the rows of the matrix realizing differences in role definitions and responsibilities across organizations.
• An IST SHALL specify the both the content and representation of each artifact template it defines using the IG-specific modeling grammars specified using the Behavioral and Information Framework compliance statements.
• Each artifact template that is defined within an IST SHALL contain at least one Conformance Statement.
• Each Conformance Statement SHALL be written so as to be testable/verifiable, i.e. its evaluation SHALL result in a Boolean TRUE or FALSE value.
• Evaluation of individual Conformance Statements SHOULD be testable via automated or semi-automated processes whenever possible. However, Conformance Statements that are only testable via human evaluation are allowable as long as there is sufficient inter-rater reliability to classify the statement as truly Boolean testable/verifiable.
• At least one artifact template SHOULD be defined for each of the 15 cells in the IST.
• The placement of artifact templates within a particular IST cell is not specified by the SAIF CD. However, place SHOULD be consistent within a given IST.
• An IST SHALL NOT replace the semantics of the IST rows with software engineering semantics (e.g. the OMG MDA semantics) as this takes away from the critical notion of the rows representing stakeholder Perspectives and not levels of software engineering abstraction.