Quick Navigation
Requirements
Customer, System, Design, and User Need work items that capture system capabilities and flow through the V-Model.
Risk & Safety
Hazards, Safety Goals, Failure Modes, Risk Controls, and Risk Records for ISO 26262 and FMEA analysis.
Design
System Elements, Functions, Characteristics, and SC/CC Classifications for design decomposition.
Verification & Validation
Test Cases, Verification Test Cases, and Validation Test Cases for evidence collection.
Process & Control
Control Plan Items, Process Steps, and Process Failure Modes for manufacturing and AIAG-VDA workflows.
Complete Work Item Type Catalog
Requirements Domain
Customer Requirement — Captures customer-facing needs and use cases. Stored as Polarion requirement work items with custom fieldkind = "customer". Links flow into System Requirements via refinedBy relationship.
System Requirement — High-level system-level behavioral requirements derived from customer needs. Forms the top of the V-Model left side. Traces to System FMEA, System Verification test cases, and Design Requirements via refinedBy.
Subsystem Requirement — Intermediate level requirements allocated to subsystem (e.g., ECU Processing, Sensor Housing). Used when defining subsystem-level FMEAs and verification. Refines System Requirements and is refined by Design Requirements.
Design Requirement — Lowest-level requirements specifying implementation details (voltages, timing, algorithms, interfaces). May be marked as subtype = "Design" and classified as SC/CC (Special Characteristics). Directly links to characteristics, failure modes, and Design Verification test cases.
User Need — Describes operational scenarios, actor goals, and environmental constraints. Separate from Customer Requirements, used for validation analysis and SOTIF hazard identification. Links to Validation test cases via validatedBy.
Use Step — Decomposes User Needs into discrete operational steps. Helps define operational phases for HARA and FMEA scoping. Stored in Operational Steps documents and linked to hazard scenarios.
Risk & Safety Domain
Hazard — ISO 26262 hazard: potential source of harm identified in HARA/HAZID analysis. Attributes include Severity (S0–S3), Exposure (E0–E4), Controllability (C0–C3), and computed ASIL (QM, A–D). Located in HAZID/HARA risksheet. Links to Safety Goals viamitigatedBy and to Harm via causes.
Harm — ISO 14971 harm outcome: physical injury or damage to people/property. Bridges ISO 14971 risk management into ISO 26262 hazard analysis. Attributes: Harm Severity (Negligible–Catastrophic), Probability. Links from Hazard via causes relationship.
Safety Goal — ISO 26262 safety goal: top-level mitigation strategy for a hazard. Inherits ASIL from hazard. Stored in HAZID risksheet as derived-from row. Links to System Requirements via implementedBy for traceability. Critical for Part 3 (Concept Phase) compliance.
Failure Mode — ISO 26262 FMEA failure mode: potential deviation from intended function. Attributes: Severity (1–10), Occurrence (1–10), Detection (1–10), Action Priority (H/M/L). Pre- and post-mitigation ratings tracked. Located in SFMEA/DFMEA/PFMEA risksheets. Links to Risk Controls via mitigatedBy.
Process Failure Mode — AIAG-VDA PFMEA failure mode specific to manufacturing processes. Follows same rating structure as FMEA but scoped to process steps and control plan. Located in PFMEA risksheet. Links to Control Plan Items via controlledBy.
Risk Control — Design or process measure that mitigates a failure mode or hazard. Attributes: Control Type (Preventive/Detective/Warning), evidence requirement (test case linkage). Pre- and post-mitigation effectiveness measured. Links to Risk Records for evidence tracking.
Risk Record — Container for aggregated risk metrics and compliance evidence. Tracks ASIL, RPN, post-mitigation action priority, verification status. Used in Risk Control Effectiveness Report and Safety Readiness Scorecard dashboards.
Design Domain
System Element — Hierarchical decomposition unit (System → Subsystem → Component). ASIL allocated top-down. Each element corresponds to one or more FMEA documents (SFMEA at system level, DFMEA at component level). Links to Functions viacontains and to Characteristics via hasProperty.
Function — Allocated to System Elements. Describes functional behavior (e.g., “Obstacle Detection”). May be decomposed into sub-functions. Links to failure modes (what functions can fail?), test cases (how is function verified?), and Design Requirements via implementation traceability.
Characteristic — Design property or performance attribute (dimension, voltage, response time, tolerance). Links to Design Requirements, failure modes (as root causes), and Control Plan Items. Classified as SC (Safety Characteristic) or CC (Control Characteristic) per IATF 16949/APQP. Used in Design FMEA and risk matrix rows.
Testing Domain
Test Case — Generic test specification. Used as parent for Verification Test Cases and Validation Test Cases. Attributes: Expected Result, Acceptance Criteria, Status (Pass/Fail/Not Run). Links to requirements, failure modes, and risk controls to show evidence of mitigation. Verification Test Case — Verifies that implementation meets specification (Design Req → Design VC, System Req → System VC). Part of the right side of the V-Model. Aggregated in System Verification Sheet and Design Verification Sheet powersheets. Metrics: Coverage %, Completion %. Validation Test Case — Validates that system meets user needs and operational requirements (User Need → Validation TC, Customer Requirement → Validation TC). Includes on-vehicle testing, scenario-based testing. Aggregated in User Need Validation Sheet. Required for SOTIF compliance.Process & Control Domain
Control Plan Item — IATF 16949 control plan row: method, frequency, sample size, reaction plan for a characteristic at a process stage. Links to characteristics, process steps, and process failure modes. Stored in Control Plan risksheet and managed through Process FMEA workflow. Process Step — Manufacturing or assembly operation (e.g., “Solder camera connector”). Parent for Process Failure Modes in PFMEA. Links to Control Plan Items viacontrolledBy. Used to organize PFMEA hierarchy and define reaction plans.
Work Item Type Hierarchy Diagram
Key Relationships
| From | To | Link Role | Purpose |
|---|---|---|---|
| Customer Requirement | System Requirement | refinedBy | Requirement flow-down |
| System Requirement | Design Requirement | refinedBy | System decomposition |
| Design Requirement | Characteristic | implements | Implementation binding |
| Hazard | Safety Goal | mitigatedBy | Safety strategy |
| Safety Goal | System Requirement | implementedBy | Functional allocation |
| Failure Mode | Risk Control | mitigatedBy | Mitigation linkage |
| Risk Control | Test Case | verifiedBy | Evidence collection |
| Requirement | Test Case | verifiedBy / validatedBy | Coverage tracking |
| System Element | Failure Mode | analyzedBy (implicit via FMEA doc) | Scope binding |
| Characteristic | Control Plan Item | controlledBy | Process control |
Related References
- RTM Domain Model — Full entity definitions and relationship cardinality
- Enumerations — ASIL, Severity, Occurrence, Detection, Action Priority scales
- Custom Fields — Per-work-item-type field definitions and validation rules
- Risksheet Configurations — How work items are displayed in HARA, SFMEA, DFMEA, PFMEA, Control Plan
- PowerSheet Configurations — How work items are organized in Requirements, Functions, Characteristics, Verification sheets