Configuring Validation Rules

In the template for the Document Object Type you can also define the possible validation rules that should apply to the object. The available rules and their parameters are:

The ”Traced to” - rule enforces the relationship between the parent object and at least one child object. E.g. A requirement should have at least one trace to a specification:

<TracedToRule ToTraceTypeName="Specification"/>

The ”Traced from” - rule enforces the relationship between a child object and at least one parent object of a given type. E.g. A specification should have at least one trace from a requirement:

<TracedFromRule FromTraceTypeName="Requirement"/>

The ”Illegal Trace”- rule signalizes if there exist a forbidden relationship between the parent object and at least one child object. E.g. A requirement may not trace to a test case:

<IllegalTraceToRule IllegalTraceToTypeName="TestCase"/>

The “Not Reviewed” - rule enforces that the document object has been reviewed:

<HasOpenIssueRule TypeNameIssue="Issue" OpenAttributeName="Status"> <ExpectedAttributeValue>Closed</ExpectedAttributeValue>

<ExpectedAttributeValue>Duplicate</ExpectedAttributeValue> <ExpectedAttributeValue>Misunderstood</ExpectedAttributeValue> </HasOpenIssueRule>

The “Suspect Trace” - rule, decides if the traces to the child objects should be set suspect if the parent object is changed to a new revision:

<SuspectTraceRule/>

The “Risk Not Mitigated”- rule is implemented in the Failure Mode and checks if the risk probability number for the hazard after mitigation is above the treashold:

<RiskNotMitigatedRule RiskTypeName="Hazard" MitigationTypeName="Mitigation"

StopAtFirstInconsistency="false" AnyMitigationClearsSeverityInconsistency="true"/>

The “Harm Not Mitigated” - rule, is the equivalent for Risk Anylsis and checks the probaility and severity for the combination on the ProbailityOfHarm object before and after measures:

<HarmNotMitigatedRule ProbabilityOfHarmTypeName="ProbabilityOfHarm" HarmTypeName="Harm"

MeasureTypeName="Measure"/>

The “Consistent Classification” – rule, can be used in systems where a Risk Analysis is used. It checks that the Safety classification for e.g. a Sw Item is consistent with the Risk Analysis. For Sw Items with the lowest Safety Classification , i.e. ‘A’, there may optionally be a trace to a NoCause to justify that the Item is not implying any Harms in the system:

<HasConsistentClassification AttributeName="SafetyClassification" TypeNameCause="Cause"

TypeNameRiskAnalysis="RiskAnalysis" TypeNameNoCause="NoCause"> <CheckTracesOfType>

<Trace TypeName="SoftwareItem"/> <Trace TypeName="SoftwareUnit"/> <Trace TypeName="SOUP"/>

</CheckTracesOfType> <ClassificationMapping>

<Classification Value="A" MaxSeverity="1"/> <Classification Value="B" MaxSeverity="3"/> <Classification Value="C" MaxSeverity="5"/> </ClassificationMapping>

</HasConsistentClassification>

The “Attribute Value”- rule allows to consider an object inconsitent if an attribute doesn’t hold a certain value, e.g. an executed test case was not passed:

<AttributeValueRule AttributeName="Status"> <ExpectedValue>Closed</ExpectedValue> <ExpectedValue>Duplicate</ExpectedValue> <ExpectedValue>Misunderstood</ExpectedValue> </AttributeValueRule>

The “Related Attribute Value”-rule checks that the combination of 2 attribute values in an object are consistent. This rule can also be enforced before saving any objects (the user is then

prompted with the inconsistency). Here an example from a Measure where the type of Measure should match the probability reduction:

<RelatedAttributeValueRule AttributeNameA="Type" AttributeNameB="ProbabilityReduction"

EvaluateAtCommit="true">

<ValueMap ValueA="Design"> <ValidValue ValueB="4"/> </ValueMap>

<ValueMap ValueA="Protective"> <ValidValue ValueB="3"/>

<ValueMap ValueA="Warning"> <ValidValue ValueB="2"/> </ValueMap>

<ValueMap ValueA="Information"> <ValidValue ValueB="1"/> </ValueMap>

</RelatedAttributeValueRule>

To validate if all document objects in a file are up to date (have the most current revision), you can add the rule below:

<ObjectsInFileUpToDateRule AttributeName="ObjectsInFile"/>

To ensure that a certain document object type has been added to a file, use the following rule:

<ObjectInFileRule FileTypeName="File" AttributeName="ObjectsInFile"/>

Test Cases can be configured to have the rule

<ExecutedFromLastRevision/>

to ensure that the current revision of the Test Case has been executed. To check if a date has been passed or not, use the DueDate rule:

<DateOverdueRule AttributeName="DueDate" WarnDaysInAdvance="1"/>

This validation rule is useful in combination with other validation rules which can be linked through the usage of the Combine Rule.

Below is an example of a combination of trace rules to ensure that the document object either “has a trace to a specification” OR “to a use case”. If one of the rules are fullfilled then no

inconsistencies are mentioned:

<CombinedRules Combination="OR">

<TracedToRule ToTraceTypeName="Specification" /> <TracedToRule ToTraceTypeName="UseCase" />

</CombinedRules>

It is also possible to create and combine conditional rules.

<ConditionalRule> <Condition>

<AttributeValueRule AttributeName="RequirementType"> <ExpectedValue>Software</ExpectedValue>

</AttributeValueRule> <Condition>

<EvaluateIfConditionIsMet>

<TracedToRule ToTraceTypeName="Specification" /> </EvaluateIfConditionIsMet>

<EvaluateIfConditionIsNotMet>

<TracedToRule ToTraceTypeName="TestCase" /> <EvaluateIfConditionIsNotMet>

</ConditionalRule>

The rule above evaluates the AttributeValueRule om the condition clause and then generates inconsistencies based the outcome of the condition. If the attribute “RequirementType” has the value “Software”, the value rule MissingTrace to specification is evaluated and generates an inconsistency if there is no specification trace. If the attribute value is not “Software”, then the MissingTrace to UseCase is evaluated.

To validate objects based on states of traced objects the following validation rule can be used:

<ValidationOnTracesRule TypeName="Specification"> <RulesToCheck>

<TracedToRule ToTraceTypeName="Requirement" /> </RulesToCheck>

</ValidationOnTracesRule>

If the above rule is applied to e.g. the type requirements, a requirement with a trace to a specification with a trace back to a requirement would generate an inconsistency for the first requirement.

6.7.4.1 Consistency Coverage parameters in Validation Rule definitions

1) To exclude a validation rule from the consistency calculation, use the ExcludeFromCoverage

attribute (false by default.

2) To set the coverage weight for a validation rule, use the CoverageWeight attribute to set a weight (decimal value).