This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Domain Analysis Model ArB"

From HL7Wiki
Jump to navigation Jump to search
m
m
Line 1: Line 1:
 
{{Arb Done Item}}
 
{{Arb Done Item}}
 
'''NEW definition'''
 
'''NEW definition'''
Approved by the ARB in on [20120412_arb_minutes | April 12, 2012 Teleconference]]:
+
Approved by the ARB in during the [[20120412_arb_minutes | April 12, 2012 Teleconference]]:
  
 
*A Domain Analysis Model(DAM) is a collection of traceable artifacts at the conceptual level that represent a subject area of interest the purpose of which is to harmonize the perspectives of the stakeholders and inform work required to build logical and implementable representations of the subject.   
 
*A Domain Analysis Model(DAM) is a collection of traceable artifacts at the conceptual level that represent a subject area of interest the purpose of which is to harmonize the perspectives of the stakeholders and inform work required to build logical and implementable representations of the subject.   

Revision as of 22:04, 12 April 2012

NEW definition Approved by the ARB in during the April 12, 2012 Teleconference:

  • A Domain Analysis Model(DAM) is a collection of traceable artifacts at the conceptual level that represent a subject area of interest the purpose of which is to harmonize the perspectives of the stakeholders and inform work required to build logical and implementable representations of the subject.
  • A DAM:
    • SHALL have a definition of the shared purpose scoping the domain.
    • SHALL define the stakeholders.
    • SHALL express either the information and/or behaviour(enterprise and computational) semantics as understood by the domain experts.
    • SHALL focus on the conceptual, but MAY have logical constraints.
    • SHOULD contain references to other material used to create it.
    • SHOULD be understandable by subject matter experts that were not present during the development.
    • SHOULD have both the information and behaviour(enterprise and computational) semantics as understood by the domain experts.
    • MAY specify data types: if so, the definitions must be contained in the model or referenced from a publically available source.
    • SHOULD NOT include logical and/or implementable artifacts that distract from the clarity
      • e.g. Foreign key constraints.