This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Domain Analysis Model ArB"
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 | + | 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.