All comments should be raised as issues against the capability on dexlib (….\capability_name\dvlp\issue.xml).
Each issue should be identified as MRI-XX where XX is a serial number beginning with MRI-1 (MRI =
Modeller Review Issue). Each issue id should also be written into the comments field for the bullet against which
it has been raised.
Modellers review
Cover page
1. Capability identification, name and number
The capability id, name and number should be consistent with the DEX coordinator capability master list.
2. Reviewers
Names of model reviewer and business reviewer in accordance with Oasis PLCS resource matrix.
3. Status
The status of the capability should be “end_modelling”.
4. Completion date
Date of completion should be the date when the capability is planned to be complete i.e. accepted by the dex
coordination committee.
5. Issues
There should be no open issues against this capability.
Introduction
6. Content
Understandable from a modellers perspective? The introduction should give a clear view of the scope covered
by the capability.
7. Hyperlinks
Possible hyperlinks to dexlib or stepmod should be syntactic and semantic correct.
Content
8. Sections
The content section should contain the following subsections in the following order:
 Business concept overview
 Information model overview
 Characterization
 Related capabilities
 Dependent capabilities
 Model reference data
 Related standards
Business concept overview
9. Content
Understandable from a modellers perspective. The business concept overview section should 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.
10. Hyperlinks
Possible hyperlinks to dexlib or stepmod should be syntactic and semantic correct.
11. Figures
Possible figures should reflect business key concepts rather than AP239 entities and attributes.
Information model overview
12. Model diagram
There should be an Express-G diagram illustrating the main entities used by this capability.
There should 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 should be illustrated
with colour codings (i.e. background colours). There should be a description of colour codes used.
Text in the diagram should be easy to read on screen.
13. Model explanatory text
Should give an overview on how the entities within the Express-G diagram applies to the business key concepts.
The textual description should focus on entities introduced by this capability. Entities not belonging to this
capability should be referred to.
There should be no illustrations or textual descriptions that limits the usage of the capability to AP239 (e.g. list
of valid entities for a certain assignment).
14. Business key concepts
Each business key concept should be mapped against entities and attributes in AP239.
Each business key concept should be defined as reference data being assigned to the entity representing the
business key concept.
15. Applicable reference data
Entities, appart from those representing business key concepts, that may be classified should be assigned with
reference data in order to create a unambigous exchange file.
Has the enumeration of applicable reference data been done in the right way. If the reference data is normative,
the text should be as follows; “entity_name should be classified as reference_data …”. If the reference data is
descriptive, the text should be as follows; “Typical values include reference_data, reference_data …”.
Does the identified reference data exist in plcs_owl?
16. Examples (instance diagrams)
Each entity being defined in the usage section of the capability should be represented in at least one example.
Each example should be illustrated as an Express instance diagram. The instance diagram may be supplemented
with a part 21 example. (Part 21 examples are optional)
The entities illustrated in an example should be grouped in accordance with its originating capability. This
grouping should be illustrated with colour codings (i.e. background colours). The capability number and
identification should be given for each colour code used.
Has any entity been given an identifier? If so, has identification assignment been used and has “correct”
reference data been applied to the identification, i.e. does the reference data exist in plcs_owl? Any usage of
entity id attributes should be replaced with identification_assignments.
Has all relevant entities in the examples been classified, and has relevant reference data been applied. Make sure
that all “assignment” and “relationship” entities has been classified .
Has any role attribute been used in the examples. If so, this should be replaced with the usage of
classification_assignment and relevant reference data.
Are the examples compliant with AP239? Are all mandatory relationships visualized ? Are the entity names and
attribute names correct ?
Are the reference data used in the examples represented in the textual description ? If not, these should be added.
17. References
All references to stepmod or dexlib entries from the textual description of the information model overview
should be represented as hyperlinks. All hyperlinks should be syntactic and semantic correct.
Are URLs used to reference entities, capabilities and reference data? E.g. in XML has the following been used:
<express_ref linkend="product_as_individual:arm:Product_as_individual_arm.Product_as_realized"/>
<capability_ref linkend="representing_scheme"/>
<rdl_ref id="Activity_decomposition" rdl="plcs_owl"/>
Characterization
18. Descriptions and examples
For capabilities containing a separate characterization section, this should comply with 15 – 17 above.
Related capabilities
19. Listing
Are all relevant related capabilities listed. Candidates for relevant related capabilities are:
 corresponding reference/representing capabilities
 other capabilites including the same entities in the usage section (look at relevant entities under the
Entities menu option of Dexlib)
Dependent capabilities
20. Listing
Are all capabilities used in the information model overview or the characterization sections listed under
dependent capabilities.
21. Usage descriptions and examples
For each dependent capability it should be explicitly described how it should be applied, either under the
information model overview or the characterization sections.
Reference Data
22. Reference data being related
Are all relevant reference data classes used in the information model overview and/or characteization sections
identified and registered?
Related standards
23. Referenced standards
Does the referenced standards make sence ?
Usage
Assignment and/or relationship entities required to associate entities included in the usage section to entities out
of scope of this capability should be included in the usage section. (Example Project_assignment should be
included in the usage section of capabilities including the Project entity
Are entities in definined within the modules used but not shown in the examples should be marked with
‘REMOVE’ / ‘IGNORE’.
Are necessary supertypes should be included in the usage section.
All ‘id’, ‘role’, ‘name’, ‘date’ attributes should be marked with ‘REMOVE’ / ‘IGNORE’ and be replaced with
assignment capabilities, ‘assigning_identifiers’, ‘assigning_reference_data’, ‘assigning_identifiers’,
‘assigning_date_time’ respectivly.
Are all entities required by mandatory relationships in AP239 long form included in the usage section (possibly
marked with ‘IGNORE’ if they are not intended to be used)
Are entities required by module Functions/Rules included in the usage section (See the Express short form for
the respective module)
Are all entities not belonging to this capability omitted, i.e. entities included in the dependent capabilities.
Possible overridden definitions of entities and attributes in the usage section should comply with the originating
definition.
Keywords
Keyword should include assigning, referencing orrepresenting as keywords.
Main AP239 entities used by capability should be included as keywords.
Main business concepts should be included as keywords.