Internal Review Approval Checklist

Capability Review Checklist

Use of this Check List

This checklist is intended to provide quality assessment criteria for developers of OASIS/PLCS DEX standards.

This checklist shall be completed by the PLCS Technical Oversight Group in OASIS prior to submitting a capability for clearance for OASIS ballot. The data modeller shall check items marked “M”. Subject domain experts shall check items marked “S”. Either may check unmarked items.

For each question, check the box that applies.

If "N/A" (not applicable) is checked, explain the reason why the question is not applicable in the comment field.

If “No” is checked, the comment should be raised as an issue against the capability on DEXLib (…\capability_name\dvlp\issue.xml). Each issue should be identified as RI-XX where XX is a serial number beginning with RI-1 (RI = Review Issue). Each issue id should also be written into the comments field for the question against which it has been raised.

NOTE: In cases where Subject domain experts can’t access DEXLib as a developer, use comment field within this document. The modeller should then be responsible for updating the issue file on dDEXLib.

The process diagram illustrating the capability review process is attached to this checklist (Appendix A).

Review information

This review is made against the following capability:

Capability id:

Capability number:

Version (CVS):

Review performed by:

Modeller review

Name :

Date :

Subject domain expert reviewer

Name :

Date :

1

Internal Review Checklist ISO TC184/SC4/QC N244

N-number of this completed checklist: N

Name of person who completed this checklist

Date this checklist was completed

For each question, check the box that applies. If "N/A" (not applicable) is checked, explain the reason the question is not applicable in the comment field.

FIGURES

1. (M) All figures shall be stored in png format.

1. (M) All images are stored in the “images” folder.

1. (M) For relevant Figures, all attributes are populated with /IGNORE etc. according to agreements.

1. (M) All Figures are sequential numbered.

1. (M) The text in figures and diagrams are easy to read on screen.

1. (M) The colour coding is consistent throughout the capability.

1. (M) There shall be a clear separation between those entities that are defined within the usage section of this capability and those entities being brought in by dependent capabilities. This separation shall be illustrated with colour codes inside entities (i.e. entities reflecting one capability have the same colour). There shall be a description of colour codes used.
   Entities representing the capability under consideration shall be left uncoloured. Also be consistent across capabilities with respect to colours.
   The capability number and identification shall be given for each colour code used.

1. (M) All capabilities used in the example figures shall be visualized by using graphical presentation of the templates.

1. (M) All ‘id’, ‘role’, ‘name’, ‘date’ attributes on the figures are marked with ‘REMOVE’ / ‘IGNORE’.
   NOTE: The usage of these attributes shall be replaced with the usage of the following assignment capabilities; ‘assigning_identifiers’, ‘assigning_reference_data’, ‘assigning_identifiers’, ‘assigning_date_time’, respectively.

references

1. (M) Are all references to Stepmod or DEXLib entries from the textual description of the information model overview represented as hyperlinks?

“COVER” section

1. (M) The capability id, name and number shall be consistent with the DEX coordinator capability master list.
   Comments:

1. (M) The keywords include assigning, referencing or representing as keywords.

1. (M) For relevant Figures, all attributes are populated with /IGNORE etc. according to agreements.

1. (M) The AP239 key entities used by the capability are included as keywords.

1. (S) The key business concepts are included as keywords.
   All keywords to be given with an upper case. References to key entities shall reflect their real names (including the underscore).

1. (M) Names of project leader, editor, model reviewer and business reviewer is in accordance with the OASIS PLCS resource matrix.

1. (M) The status of the capability shall be “end_modelling”.

1. (M) Date of completion should be the estimated date when the capability is to be assigned with the state “complete” by the PLCS Technical Oversight Group in OASIS. Format: <year-month-day>

1. (M) There shall be no open issues against this capability.
   Comments:

“introduction” section

1. (S) Is the Introduction section understandable from a subject domain expert (business user) perspective? The introduction shall give a clear view of the scope covered by the capability.

1. (M) Is the Introduction section understandable from a modeller perspective? The introduction shall give a clear view of the scope covered by the capability.

1. (M) The Introduction start with “This capability provides the ability to….”

1. (M) The Introduction does not use links to entities or modules.

“CONTENT” section

1. (M) The content section contains the following subsections in the following order:

1. (M) Each section starts with a statement “This section describes….”.

1. (M) No unused files are stored in the capability folder in DEXLib.

1. (S) “Business overview” sub-section. The business overview reflects the business requirements for the capability.

1. (M) “Business overview” sub-section. Links to entities or modules are not used in the introduction.

1. (S) “Business overview” sub-section. The content is understandable from a business perspective.

1. (S) “Business overview” sub-section. The business overview section give a detailed description of the scope and key business concepts covered by the capability without getting into the details of the underlying AP239 data model.

1. (S) Possible figures reflect business key concepts rather than AP239 entities and attributes.

1. (M) “Information model overview” sub-section. The capability does not list possible selects.

1. (M) “Information model overview” sub-section. Enumerations of entities that can be selected are not documented in the capability.

1. (M) “Information model overview” sub-section. URN is used consistently throughout the capability (and DEXLib).

1. (M) Model diagram. Does the section (Information Model Overview) contain at least one EXPRESS-G like diagram illustrating the main entities used by this capability (the number of Figures depends on complexity of capability)?

1. (M) Model diagram. The EXPRESS-G diagram is the same as used in section “Template”.

1. (M) Model diagram. The section (Information Model Overview) contains at least one Instance diagrams (examples).

1. (M) Model explanatory text. The text gives an overview on how the entities within the EXPRESS-G and Instance diagram apply to the business key concepts.

1. (M) Model explanatory text. The textual description focus on entities introduced by this capability. Entities not belonging to this capability are referred to where required.

1. (M) Model explanatory text. There are no illustrations or textual description that limits the usage of the capability to AP239 by listing valid entities for a certain extensible select.

1. (M) Business key concepts. Each business key concept is mapped against entities and attributes in AP239.

1. (M) Business key concepts. The business key concepts are defined as reference data.

reference data

1. (M) All entities that may be classified are assigned with reference data in order to create an unambiguous exchange file.

1. (M) Enumeration of applicable reference data is performed as follows:
   If the reference data is normative, the text shall be; “entity_name should be classified as reference_data …”. If the reference data is given just as an example, the text should be; “Typical values include reference_data, reference_data …”.

1. (M) All identified reference data classes are defined in the Reference Data Library (RDL).

1. (S) All reference data identified within the Capability have accurate definitions.

EXAMPLES – Instance diagrams

1. (M) Each instantiableentity is defined in the usage section of the capability and represented in at least one example.

1. (M) Each example is illustrated as an Express instance diagram.

1. (M) The documentation does not contain examples in Part 21 format.

1. (M) The entities illustrated in examples are grouped in accordance with their originating capability. This grouping is illustrated with colour coding as described earlier in this checklist.

1. (M) Identification of entities is done by the usage of identification assignment and not by the usage of id attributes (where applicable). The identification assignment entity is classified and relevant reference data are applied.

1. (M) Where applicable, entities in the examples are classified, and relevant reference data are applied. Graphical presentation of templates is used. NOTE. All “assignment” and “relationship” entities are classified and relevant reference data classes are applied.

1. (M) There is no usage of role attribute in the examples. Roles are defined using classification_assignment and relevant reference data.

1. (M) The instance diagram illustrated by the example is compliant to the area of AP239 that it is being illustrated.

1. (M) Reference data is used in the examples represented in the textual description.

characterizations

1. (M) Description and examples. Capabilities containing a separate characterization section, complies with sections above.

template

1. (M) Template. The Template section contains at least one EXPRESS-G like figure and one example figure.

related capabilities

1. (M) All relevant related capabilities are listed. Candidates for relevant related capabilities are:

1. (M) The listing of capabilities is in an ascending order with respect to capability numbers.

dependent capabilities

1. (M) All capabilities are used in the information model overview and characterization sections listed under “dependent capabilities” section.

1. (M) The listing is done by capability number in an ascending order.

1. (M) For each dependent capability is it explicitly described how it shall be applied, either under the information model overview or the characterization sections.

related standards

1. References to related standards are complete, correct and appropriate.

hyperlinke

1. (M) Possible hyperlinks to DEXLib or Stepmod shall be syntactic and semantic correct.

1. (M) All references to entities, reference data, modules etc. are hyperlinked.

APPROVAL

I have reviewed and verified the items on this document.

NameDate

Appendix – A

Capability Review Process

1

Internal Review Checklist ISO TC184/SC4/QC N244