Skip to main content

​
Overview

Design characteristics are engineering specifications for measurable product features. Each characteristic has a target value and tolerance band, and serves as the focal point for DFMEA analysis — failure modes in DFMEA are directly linked to characteristics via the “assesses” link role. The Characteristic Type enumeration provides a classification system for organizing characteristics by their engineering discipline or analysis purpose.
This page documents the Characteristic Type enumeration structure based on source code configuration. Specific enumeration values and their usage patterns should be verified in your Aerospace Safety Solution project configuration.

​
Characteristic Type Enumeration

Value IDDisplay NameDescriptionTypical Usage
See applicationSee applicationCharacteristic type values are defined in .polarion/tracker/fields/characteristic-type-enum.xmlClassification of measurable design attributes
The enumeration values for Characteristic Type are not currently exposed in the available extracted source code. The enumeration definition file exists (characteristic-type-enum.xml), but the specific type values, IDs, and descriptions require direct inspection of the Polarion tracker configuration or consultation with your project administrator.

​
Characteristic Entity Overview

Characteristics form a critical bridge between requirements specification and design risk analysis: diagram

​
Characteristic Custom Fields

Characteristics are minimal entities with only three custom fields:
Field NameTypeDefaultDescription
classificationEnum: Classification(none)Safety classification: SC (Safety-Critical) or CC (Configuration-Critical). Flows from parent design requirement. Enables filtering of failure modes by criticality.
targetValueString(none)Engineering specification for the nominal or desired value of the characteristic. Example: “3.3V ±0.1V” for a power supply voltage characteristic.
toleranceString(none)Engineering tolerance band for the characteristic. Example: “±5%” for a frequency tolerance, or “±0.01mm” for a mechanical dimension.
The classification field uses the same Classification enumeration as Design Requirements and other safety-critical work items. The enum values are sc and cc internally, but display as SC and CC in the Polarion UI. The classification should be inherited from the parent Design Requirement via traceability rules.

​
Role in DFMEA Analysis

Characteristics are the primary analysis target in Design FMEA:
  1. Decomposition: Each Design Requirement specifies one or more Characteristics
  2. Failure Analysis: Each Characteristic has Failure Modes that could violate it (via the “assesses” link role)
  3. Risk Scoring: Failure Modes on Characteristics are scored using FMEA severity, occurrence, and detection scales
  4. Traceability: RPN (Risk Priority Number) and post-mitigation status flow back to parent Design Requirements

​
DFMEA Document Structure

In a Component DFMEA risksheet, characteristics typically appear as:
  • Column Group: Design Characteristics (expanded from component design requirements)
  • Row Structure: One row per characteristic, grouping failure modes that assess that characteristic
  • Cell Content: Target value, tolerance, classification, and linked failure mode details
  • Views: Can be filtered by system element, classification level, or RPN threshold

​
Traceability Path

diagram Each Design Requirement can specify multiple Characteristics. Each Characteristic can be assessed by multiple Failure Modes. This many-to-many relationship enables comprehensive DFMEA coverage.

​
Design Verification Connection

Characteristics are also linked to Design Verification via test cases:
  • Verification Method: Test cases verify that design implementations meet characteristic target values and tolerances
  • Test Specification: Environmental test categories (DO-160G sections) may be attached to characteristics for qualification testing
  • Evidence: Passing test results provide evidence that the design requirement’s characteristics are met
EnumerationPurposeLink
ClassificationSC/CC safety classification (also used on design requirements, system requirements, and failure conditions)Classification Enumeration
Test LevelVerification test levels (Unit, Integration, System, Acceptance, Qualification)Test Level Reference
Environmental CategoryDO-160G environmental test categories (Sections 4–27)Characteristic and Test Case Environmental Categories

​
Best Practices

  • Be specific: Target value and tolerance should be measurable and testable
  • Inherit classification: Ensure characteristics inherit SC/CC classification from their parent design requirement
  • Link to failure modes: Every characteristic should have at least one failure mode in the component DFMEA
  • Allocate to elements: Link characteristics to the system element (component) responsible for meeting them
  • Verify coverage: Ensure test cases exist to validate that each characteristic is met in the final design
  • Incomplete characteristics: Characteristics without target values or tolerances cannot be analyzed or tested
  • Missing links: Unlinked failure modes or test cases create traceability gaps
  • Misclassification: Failing to classify characteristics correctly can mask safety-critical failures
  • Scope creep: Adding too many characteristics per requirement dilutes focus and increases DFMEA analysis burden

​
See Also

Code: .polarion/tracker/fields/systemElementType-enum.xml, systemElement-status-enum.xml (0.50) · .polarion/documents/fields/document-type-enum.xml (0.49) · .polarion/tracker/fields/designRequirement-subType-enum.xml, environmentalCategory-enum.xml, fta-gateType-enum.xml, cca-analysisType-enum.xml, controlType-enum.xml, riskControlType-enum.xml, verificationMethod-enum.xml, testLevel-enum.xml (0.48) · .polarion/tracker/fields/testCase-custom-fields.xml, desReq-custom-fields.xml, processStep-custom-fields.xml, characteristic-custom-fields.xml, systemElement-custom-fields.xml, commonCauseEvent-custom-fields.xml, riskControl-custom-fields.xml, task-custom-fields.xml, custom-fields.xml (0.46) · .polarion/nextedy/models/rtm.yaml (0.45) · .polarion/pages/spaces/_default/Data Model/page.xml (0.45) · .polarion/nextedy/sheet-configurations/DO-160G Environmental Qualification.yaml, Component RTM.yaml, Configuration Index.yaml, Design Verification Sheet.yaml, Interface Control Matrix.yaml, Problem Report Tracker.yaml, Process Steps.yaml, Review Action Item Tracker.yaml, SOI Stage Gate Dashboard.yaml, Use Steps Specification.yaml, User Need Validation Sheet.yaml, characteristics.yaml, component-characteristics.yaml, customer-requirements.yaml, design-requirements.yaml, subsystem-functions.yaml, subsystem-verification.yaml, system-elements.yaml, test-verification.yaml (0.42) · .polarion/tracker/fields/mappings.xml (0.39) · .polarion/tracker/fields/complianceObjective-standard-enum.xml, complianceObjective-status-enum.xml, complianceRequirement-complianceStatus-enum.xml, complianceRequirement-evidenceType-enum.xml (0.38) · .polarion/pages/scripts/velocity/nextedy_solutions.vm (0.37)