Overview
| Property | Value |
|---|
| Polarion Type | sysReq |
| Document Type Constraint | subsystemRequirementsSpecification |
| RTM Entity | SubsystemRequirement |
| Module Location | Design space, scoped by system element |
| Traceability Roles | refines (outbound to System Requirements), refined by (inbound from Design Requirements), verifies (to Verification Test Cases), validates (to Validation Test Cases) |
| Outline Numbering | Yes (hierarchical numbering within document) |
| Classification Field | classification (SC/CC special characteristics) |
| Typical Cardinality | One System Requirement → 2–5 Subsystem Requirements |
Purpose and Usage
Subsystem Requirements serve as the bridge between system-level functional requirements and implementation-level design specifications. They enable:
- Scoped decomposition: Each subsystem requirement is constrained to a specific system element (subsystem or component), preventing cross-team confusion and supporting parallel design workflows
- Traceability continuity: Every subsystem requirement must trace upward to at least one parent System Requirement via the
refines link role, ensuring full requirements coverage per ISO 26262 Part 4
- Design clarity: Subsystem requirements are specific enough to guide design but abstract enough to permit multiple valid design solutions
- Verification anchoring: Subsystem requirements serve as the middle verification level in the V-model, verified by Subsystem Verification Test Cases
Large projects create separate Subsystem Requirements documents per system element (e.g., Subsystem Requirements - Sensor Housing, Subsystem Requirements - ECU Processing). This document isolation simplifies parallel development and version control.
Standard Properties
Identification
| Property | Type | Default | Description |
|---|
ID | String | Auto-generated | Unique identifier within project (e.g., SUBRS-001). Polarion assigns automatically from module naming. Read-only. |
Title | String | — | Brief name of the subsystem requirement. Example: "Sensor fusion data output timing ≤ 50 ms" |
Description | String (rich text) | — | Full requirement specification with acceptance criteria. May include formulas, embedded tables, or references to external specifications. |
Outline | Integer hierarchy | Auto-generated | Hierarchical outline number (e.g., 1.1.2) enabling nested requirement structures and parent-child traceability within the document. Auto-maintained by Polarion. |
Classification and Scope
| Property | Type | Default | Description |
|---|
classification | Enum: none, SC, CC | none | Special Characteristics (SC) or Critical Characteristics (CC) classification per IATF 16949 / AIAG-VDA standards. Marks requirements that correspond to safety-critical or quality-critical product properties. SC/CC requirements must be flowed down to Design Requirements and linked to Failure Modes for FMEA analysis. |
assignedTo | Work Item (System Element) | — | Scoping field: Links subsystem requirement to parent System Element (subsystem or component). Required for RTM traceability. Constrains requirement to one system element boundary, enabling cross-reference validation and system structure navigator reports. |
Traceability Relationships
Upstream (Incoming) Links
| Link Role | Source Type | Cardinality | Purpose |
|---|
refines | SystemRequirement | 1..* | Every subsystem requirement must refine at least one parent System Requirement. The refines link establishes the V-model decomposition chain: System Req → Subsystem Req → Design Req. Checked by traceability coverage reports. |
refined by | DesignRequirement | 0..* | Design Requirements that implement this subsystem requirement. Multiple design requirements may refine a single subsystem requirement if the subsystem requirement is complex enough to require multiple design solutions. |
Downstream (Outgoing) Links
| Link Role | Target Type | Cardinality | Purpose |
|---|
verifies | VerificationTestCase | 0..* | Verification test cases that verify this subsystem requirement. Verification tests check that the subsystem is “built correctly per specification” (ISO 26262 Part 4 §6.3.2). At least one verification test case should target each subsystem requirement; zero test cases triggers a coverage gap warning. |
validates | ValidationTestCase | 0..* | Validation test cases that validate this subsystem requirement against customer needs. Less common at subsystem level (more typical for System Requirements), but used when subsystem requirements directly implement customer-visible features. |
mitigates | RiskControl | 0..* | Risk controls (design decisions, mitigation actions) that reduce risk associated with this requirement. Link used in traceability reports to show how design choices address identified risks. |
assesses | FailureMode | 0..* | Failure modes that assess (analyze the behavior of) this subsystem requirement. Example: if subsystem requirement is “sensor timeout detection,” the failure mode “timeout detection circuit fails silent” assesses this requirement. |
Document Type Constraint
Subsystem Requirements are created only in documents of type subsystemRequirementsSpecification. Polarion enforces this via document type constraint in the work item type definition.
<!-- Example: allowed document types for SubsystemRequirement -->
<subsystemRequirementsSpecification>
<name>Subsystem Requirements Specification</name>
<description>Document type for subsystem-level requirements derived from system requirements</description>
<parentDocumentType>systemRequirementsSpecification</parentDocumentType>
</subsystemRequirementsSpecification>
- Subsystem requirements remain organized in dedicated DRS documents per system element
- PowerSheet queries can reliably identify subsystem requirement documents for RTM views
- Version control and document lifecycle workflows apply consistently
RTM Integration
PowerSheet Views
Subsystem Requirements appear in several PowerSheet configurations:
- Component RTM PowerSheet — Left-side column group displaying subsystem requirement ID, description, and upward links to parent system requirements. Provides read-only context for design engineers working on child design requirements.
- System Verification Sheet — Shows subsystem requirements with linked verification test cases, used by V&V engineers to track verification coverage at the subsystem level.
Semantic Cross-Reference
When a subsystem requirement is created in the RTM domain model, Polarion:
- Auto-creates the requirement in the designated
subsystemRequirementsSpecification document
- Registers the requirement’s ID in the system element’s traceability context
- Indexes it for PowerSheet expansion queries (e.g.,
@expand(refines)->subsystemRequirement)
This enables dynamic RTM views that automatically include all subsystem requirements for a given system element without manual configuration.
Relationship Diagram
Below is the subsystem requirement’s position in the V-model requirement cascade and verification hierarchy:
Classification and Special Characteristics
If a subsystem requirement corresponds to a product property that is safety-critical (SC) or quality-critical (CC) per IATF 16949, mark it with the classification field:
| Classification | Usage | Downstream Impact |
|---|
SC (Special Characteristic) | Requirement related to safety performance, environmental robustness, or regulatory compliance | Must flow down to Design Requirements; linked Characteristics must be included in Control Plan; design variations require FMEA failure mode analysis; test coverage must include critical boundary conditions |
CC (Critical Characteristic) | Requirement related to customer satisfaction, reliability, or cost-critical performance | Must flow down to Design Requirements; design changes require design review and Change Control Board approval; design variations must be analyzed in DFMEA |
none | Standard requirement with no special classification | No additional downstream requirements; standard change control applies |
When you classify a subsystem requirement as SC or CC, you must propagate that classification down to all child Design Requirements and linked Characteristics. Failure to propagate causes Control Plan gaps and missed FMEA coverage.
Coverage and Metrics
Subsystem Requirements are tracked in several coverage reports:
| Metric | Definition | Target |
|---|
| Refinement Coverage | Count of Subsystem Requirements that trace upward to at least one System Requirement via refines link / total Subsystem Requirements | 100% (every subsystem requirement must refine a parent) |
| Verification Coverage | Count of Subsystem Requirements with at least one linked Verification Test Case / total Subsystem Requirements | ≥90% (ISO 26262 Part 4 §6.3.2 requires verification for all requirements) |
| Decomposition Coverage | Count of Subsystem Requirements that have been refined into Design Requirements / total Subsystem Requirements | ≥80% for APQP phases, 100% for production |
| SC/CC Completeness | Count of SC/CC Subsystem Requirements with SC/CC Design Requirements and linked Characteristics / total SC/CC Subsystem Requirements | 100% (required for IATF 16949) |
Example Subsystem Requirement
The following example shows a typical subsystem requirement for an AEB (Automatic Emergency Braking) system:
ID: SUBRS-012
Title: Sensor fusion output availability during degraded mode
Description:
During degraded sensor mode (one sensor offline), the ECU fusion
algorithm shall maintain output availability ≥ 95% over 10-second
windows during highway speeds (80–120 km/h).
Acceptance Criteria:
- Output value (position/velocity estimate) is valid ≥ 95% of time windows
- Output latency does not exceed 150 ms (validated against SYS-008)
- Timestamp precision ≥ 1 ms (validated against SYS-009)
Allocation: System Element = ECU Processing Subsystem
Classification: SC (Safety-Critical per ISO 26262 ASIL B)
Document: Subsystem Requirements - ECU Processing Subsystem (DRS-002)
Refines:
→ SYS-005: "Multi-sensor fusion shall provide reliable environment model"
Refined By:
→ DRS-021: "Redundant kalman filter initialization on sensor loss"
→ DRS-022: "Timeout detection and mode transition logic"
Verified By:
→ TC-108: "Subsystem verification: degraded mode sensor timeout recovery"
Linked Failure Modes (FMEA):
→ FM-156: "Kalman filter divergence during sensor transition"
→ FM-157: "Output timestamp invalid after mode switch"
Related Pages
- System Requirement — Parent level; view subsystem requirements as refinements of system requirements
- Design Requirement — Child level; design requirements refine subsystem requirements into implementation details
- Verification Test Case — Verification at subsystem level via Subsystem Verification Sheet
- System Element — System decomposition hierarchy; subsystem requirements are scoped to system elements
- System Hierarchy — Conceptual introduction to three-level system decomposition (System/Subsystem/Component)
- V-Model Methodology — How requirements flow through the V-model across all levels
- Component RTM PowerSheet — Interactive traceability view showing subsystem-to-design requirement decomposition
