The base of the subcheck framework is the documentation of the rules in a separate XML file (constraints XML).

The implementation assumption is that more than one specification needs be tested. These specifications need to be defined first. To keep the XML samples in the paper short we later use only one specification.

<Specifications>
    <Specification ID="ID-Aeto-Conditions">
        <Name>Conditions Aeto</Name>
        <Acronym>C-Aeto</Acronym>
        <Version>1.0</Version>
    </Specification>
    <Specification ID="ID-Oern-Conditions">
        <Name>Conditions Örn</Name>
        <Acronym>C-Örn</Acronym>
        <Version>1.0</Version>
    </Specification>
</Specifications> 

After that, the constraints can be documented with the necessary level of detail and linked back to the specification.

<Constraint ID="c1">
    <ShortName>
      Cabin Bag Max. Weight 8kg
    </ShortName>
    <SpecifiedBy ID="ID-cabinbag-8kg">
        <SpecificationReference>
          ID-Aeto-Conditions
         </SpecificationReference>
         <Error_Level>ERROR</Error_Level>
    </SpecifiedBy>
    <ShortDescription>
      Value should be equal or less than 8.
    </ShortDescription>            
    <ShortDescriptionUser>
      Cabin bag should not have more than 8kg weight.
    </ShortDescriptionUser>
</Constraint>

The following UML class diagram models the relationship between constraints and specifications.

Figure 1. UML Diagram Constraint - Specification

All information documented in the constraints XML should be specific to the constraint and not its implementation.

One constraint can be part of different specifications and each of these specifications may put the constraint in a different context. While one specification may specify the constraint as a mandatory requirement, another specification may just regard it as recommendation. The first context would result in an error and the second context would result in a warning.