Constraint Types Overview
RTM constraints operate at three levels: entity constraints (which documents can contain a work item type), relationship constraints (which link roles are valid between entities), and validation constraints (which rules must be satisfied for workflow transitions).
Constraints are enforced at create time (entityFactory validation), link time (relationship validation), and publish time (workflow state validation). Violations prevent work item creation or document publishing.
Document Constraints
Document constraints control which Polarion modules (documents) can contain specific work item types and establish organizational structure for the V-Model.
| Name | Type | Default | Description |
|---|
documentModulePath | string | (required) | Polarion module path where work items of this type are stored (e.g., Requirements/CustomerRequirements) |
documentType | enum | (required) | Polarion document type filter (e.g., Document, Specification, TestLog); constrains which document types can contain the entity |
scopeDocument | boolean | true | If true, PowerSheet queries are scoped to the currently open document; if false, queries span all documents of the type |
allowMultipleModules | boolean | false | If true, entity instances can be distributed across multiple modules; if false, all instances must be in the single documentModulePath |
autoCreateTarget | string | (empty) | Module path where entityFactory auto-creates linked work items (e.g., when user creates a new VerificationTestCase, it targets Testing/DesignVerificationSpecification) |
Document Module Path Patterns
TestAuto2 uses organizational patterns for document modules:
| Entity Type | Typical Module Path | V-Model Phase |
|---|
CustomerRequirement | Requirements/CustomerRequirements | Left-side (concept) |
SystemRequirement | Requirements/SystemRequirements | Left-side (system design) |
DesignRequirement | Requirements/DesignRequirements | Left-side (detailed design) |
Function | Design/Functions | Left-side (design) |
Characteristic | Design/Characteristics | Left-side (design) |
Hazard | Risks/HAZID | Left-side (HARA analysis) |
FailureMode | Risks/SFMEA, Risks/DFMEA, Risks/PFMEA | Left-side (FMEA analysis) |
VerificationTestCase | Testing/SystemVerification, Testing/DesignVerification | Right-side (V-Model verification) |
ValidationTestCase | Testing/Validation | Right-side (V-Model validation) |
Entity Factory Configuration
Entity Factory constraints define auto-creation targets for linked work items:
entities:
VerificationTestCase:
displayName: Verification Test Case
documentModulePath: Testing/DesignVerification
autoCreateTarget: Testing/DesignVerification
documentType: Specification
- Link creation is initiated — user adds a new test case row
- Entity Factory validation — system checks if VerificationTestCase can be created in
Testing/DesignVerification
- Auto-creation — system creates new VerificationTestCase work item in the target module
- Link establishment — system creates the
verificationTestCases link between requirement and newly created test case
- Constraints applied — the new work item inherits context from parent (e.g., component scope, document assignment)
If autoCreateTarget does not match a valid PowerSheet documentFilters path, link creation fails silently. The error logs to Polarion’s backend; users see “Unable to create linked item.” Always verify that autoCreateTarget paths exist in Polarion before deployment.
Relationship Constraints
Relationship constraints define which link roles are valid between specific entity type pairs and enforce cardinality rules.
| Name | Type | Default | Description |
|---|
linkRole | string | (required) | Polarion link role identifier (e.g., verifies, verificationTestCases, mitigates) |
sourceEntityType | string | (required) | Entity type that initiates the link (e.g., SystemRequirement) |
targetEntityType | string | (required) | Entity type that receives the link (e.g., VerificationTestCase) |
cardinality | enum | N:N | Allowed cardinality: 1:1 (one-to-one), 1:N (one-to-many), N:1 (many-to-one), N:N (many-to-many) |
bidirectional | boolean | true | If true, the link role and its reverse can both be traversed in PowerSheet queries |
validateOnCreate | boolean | true | If true, creating this link validates that both source and target entities exist and are valid |
allowMultipleTargets | boolean | true | If false, source entity can only link to one target of this type (enforces 1:N constraint at data level) |
Relationship Matrix
TestAuto2’s RTM model defines relationships across the V-Model:
| Source | Link Role | Target | Cardinality | Purpose |
|---|
CustomerRequirement | refines | SystemRequirement | 1:N | Requirements refinement (concept to system level) |
SystemRequirement | refines | DesignRequirement | 1:N | Requirements refinement (system to design level) |
DesignRequirement | refines | Characteristic | 1:N | Design requirement allocation to characteristics |
SystemRequirement | verifies | VerificationTestCase | 1:N | System verification traceability |
DesignRequirement | verifies | VerificationTestCase | 1:N | Design verification traceability |
CustomerRequirement | validates | ValidationTestCase | 1:N | User need validation traceability |
FailureMode | assesses | Function | 1:N | Failure mode analysis for functions |
FailureMode | assesses | Characteristic | 1:N | Failure mode analysis for design characteristics |
FailureMode | mitigates | RiskControl | 1:N | Risk control mitigation linking |
Hazard | causes | SafetyGoal | 1:N | Hazard-to-safety-goal derivation |
Function | decomposes | Function | N:N | Functional decomposition (parent-child functions) |
Constraint Validation Rules
When establishing a link between two work items:
Field Validation Constraints
Field-level constraints enforce data types, enumeration values, and required fields for each entity type.
| Constraint Type | Name | Example | Validation Rule |
|---|
| Enumeration | asil | ASIL A, ASIL B, ASIL C, ASIL D, QM | Work item field must match one of allowed enum values from ../enumerations/hara-asil.md |
| Enumeration | severity | S0 (no injury), S1 (light injury), S2 (serious injury), S3 (fatal) | HARA severity must match ../enumerations/hara-severity.md |
| Enumeration | exposure | E0 (never), E1 (very low), E2 (low), E3 (medium), E4 (high) | HARA exposure must match ../enumerations/hara-exposure.md |
| Enumeration | controllability | C0 (fully controllable), C1 (generally controllable), C2 (barely controllable), C3 (not controllable) | HARA controllability must match ../enumerations/hara-controllability.md |
| Enumeration | actionPriority | High, Medium, Low | FMEA action priority must match ../enumerations/action-priority.md |
| Type | description | Free text (up to 2000 chars) | String field; no enum validation |
| Type | rationale | Free text | String field; optional in most entities |
| Required | objectId | HAZ-001, SG-002, FM-045 | Every work item must have unique identifier; auto-generated or manually assigned per project convention |
| Required | title | Failure to detect obstacle | Every work item must have non-empty title |
| Cardinality | linkedWorkItems | Link to one or more upstream requirements | For compliance, most work items must have at least one incoming link (e.g., FailureMode must link to upstream Characteristic or Function) |
Custom Field Constraints (Example: Hazard)
Hazard work items include domain-specific custom fields with validation:
Hazard:
customFields:
hazardId:
type: string
required: true
pattern: "^HAZ-\\d{3}$" # Matches HAZ-001, HAZ-002, etc.
description: Unique hazard identifier
severity:
type: enum
required: true
values: [S0, S1, S2, S3]
description: HARA Severity rating per ISO 26262
exposure:
type: enum
required: true
values: [E0, E1, E2, E3, E4]
description: HARA Exposure rating per ISO 26262
controllability:
type: enum
required: true
values: [C0, C1, C2, C3]
description: HARA Controllability rating per ISO 26262
asil:
type: enum
readOnly: true
computed: "calculateASIL(severity, exposure, controllability)"
values: [QM, A, B, C, D]
description: Auto-calculated ASIL from S-E-C matrix
The asil field is typically read-only and computed from severity, exposure, and controllability using the ISO 26262 ASIL matrix. This enforces consistency: if a user changes severity/exposure/controllability, the ASIL automatically recalculates per the standard.
Workflow State Constraints
Workflow constraints control state transitions and enforce document lifecycle rules required for compliance.
| Constraint | State | Allowed Next States | Validation Rules |
|---|
| Document Workflow | Draft | Review, Published | Requirements must be linked; coverage checks optional |
| Document Workflow | Review | Published, Rework | All work items must have status ≥ “Ready for Review” |
| Document Workflow | Published | Draft (history only) | Document is immutable until rolled back to Draft |
| Document Workflow | Rework | Review | Author must address review comments; re-submit for approval |
| Work Item Workflow | Draft | Ready for Review | All required fields completed; min 1 incoming link if compliance-tracked |
| Work Item Workflow | Ready for Review | Approved | Assigned reviewer approves; no open review comments |
| Work Item Workflow | Approved | Closed | Item is frozen; can only be archived |
Transition Validation Decision Matrix
When a user attempts a workflow transition, the system validates:
- All work items exist (count > 0)
- All mandatory fields populated
- All enums match allowed values
- Traceability coverage meets threshold
- No broken cross-document links
- All reviewers assigned
- Document metadata valid
If all checks pass, the document transitions to Review state.
If any check fails, transition is blocked with error message:
"Cannot transition document to Review: 12 requirements missing ASIL assignment.
Please complete HARA analysis before resubmitting."
Validation Rules by Standard
Different standards enforce different constraint sets:
| Standard | Key Constraints |
|---|
| ISO 26262 | ASIL assignment required; S-E-C severity/exposure/controllability enum validation; safety goal traceability mandatory; post-mitigation FMEA coverage required |
| AIAG-VDA FMEA | Action Priority (H/M/L) required for all failure modes; severity/occurrence/detection (1-10) numeric ranges; process FMEA links to control plans |
| IATF 16949 | SC/CC classification required for design characteristics; control plan item cardinality (1:1 with characteristics); process step cross-reference |
| ISO 21448 (SOTIF) | Hazard source enum values (functional vs. non-functional); operational phase classification; SOTIF-specific safety goal derivation |
Constraint Violation Handling
When a constraint is violated, Polarion returns an error message with context:
Error: Constraint Validation Failed
Entity: FailureMode FM-045
Link Role: assesses
Target: Characteristic CHAR-018
Violation: Cardinality constraint exceeded
Message: FailureMode FM-045 is already linked to 3 Characteristics
via 'assesses' role, but cardinality rule allows maximum 1.
Suggested Action: Use 'affects' link role for multiple characteristics,
or split failure mode into sub-modes.
Handling Strategy
| Violation Type | Resolution |
|---|
| Missing Required Field | Complete the field; document shows field highlight until populated |
| Invalid Enum Value | Select valid value from dropdown; clear field and re-enter if data is corrupted |
| Cardinality Exceeded | Remove excess links or split entity into multiple work items with separate analyses |
| Broken Cross-Document Link | Re-establish link using PowerSheet RTM UI or manual link dialog |
| Missing Traceability | Add upstream or downstream links; use Coverage Report to identify gaps |
| Workflow Transition Blocked | Address all violations listed in error message; re-submit when all constraints satisfied |
While Polarion administrators can disable constraints via project configuration, bypassing validation is not recommended for safety-critical projects. Disabled constraints increase risk of incomplete analyses and compliance violations. Always resolve constraints before publishing safety documents.
See Also
