Requirements-Constraint Derivation

Constraint derivation is a methodology whereby a single high-level artifact or set of artifacts (i.e. the Reference Information Model, Universal Datatypes and Universal Vocabulary model) are developed to encompass all possible requirements in the domain space. Then subsequent artifacts are developed that represent constraints of the high level artifact to reflect the requirements in a narrower domain space. This refinement process is repeated multiple times creating more rigorous specifications for ever narrower domain areas until you reach a tightly constrained fully defined implementable specification.

Requirement	Within a 'derived' artifact, it must be possible to know for every element in that artifact what corresponding element it is derived from.
Rationale	The derivation methodology is dependent on an assumption that you can only constrain, not extend. This ensures that a given piece of information (however rare) will always be communicated in the same way. To enforce this methodology, there needs to be a correspondence between each element in the derived model with the corresponding element in the base model. In some situations, derivation may also need to be asserted "after the fact". E.g. This template I created happens to be a proper subset of model A and model B. The only way to show that is to trace the derivation relationship of each element within the model.
NOTE	Only elements that could conceivably be constrained require derivation relationships. For example, a "constraint" annotation could conceivably be made tighter and therefore requires a derivation relationship. On the other hand, a mapping which provides no semantic meaning cannot be constrained and therefore requires no relationship
MIF	???/derivationSupplier

Requirement	When capturing derivation relationships between a child and parent model, there's a need to know the 'type' of relationship.
Rationale	In some places, the rationale allows extension as well as constraint. In some places, derived models will be constructed that are incompatible in some way. While undesirable, it occurs and needs to be exposed. Also, derivation relationships can be asserted after the fact. E.g. "This profile is 'almost' compatible with this specification'
Methodology	Possible derivation relationships are: restriction: The current element is a proper subset of the element it was derived from, but is not identical. extension: The element derived from is a proper subset of this element, but is not identical. conflicting: Neither the element nor the element derived from are proper subsets of the other. annotated: The element is unchanged from the element it is derived from with the exception of descriptive annotations. For datatype derivations, this effectively creates an Alias for an existing type. unchanged: The element is unchanged from the element it is derived from.
MIF	mif-core-base.xsd/Derivation/@relationship

Requirement	When derivations are assessed, they need to indicate whether free-text portions have been assessed in determining the derivation relationship
Rationale	Some relationships can't be assessed by automated means. For example, changing a free-text constraint or definition. However, these changes can make a semantic break with the parent artifact. I.e. Changing the wording might extend, restrict or even be conflicting with the base wording.
MIF	mif-core-base.xsd/Derivation/@areAnnotationsReviewed

Requirement	When a model is derived from another model and constraints or extensions are applied there needs to be a mechanism to capture the reason for the change.
Rationale	Whenever a change is made in a derived model, there's a reason for the change. Understanding this reason is essential to understanding the model as well as to ongoing maintenance. E.g. "Why did we tighten the cardinality from 0..* to 1..1 in this derived model again?"
MIF	mif-core-base.xsd/Derivation/reason