Skip to main content
System requirements form the first level of technical specification derived from customer needs. They establish the boundary conditions for subsystem and design requirement decomposition, ensuring traceability from stakeholder intent through to verification testing.

​
Form Layout Overview

The System Requirement form organizes fields into five logical sections supporting the complete system requirement lifecycle: identification, derivation and classification, safety linkage, verification mapping, and document management. diagram

​
Identification Fields

NameTypeDefaultDescription
IDString (Read-only)Auto-generated (e.g., SR-001)Unique system requirement identifier automatically assigned by Polarion. Serves as stable reference for traceability queries and RTM views. Cannot be modified after creation.
TitleString—Concise requirement title (50-100 characters). Appears in PowerSheet headers and traceability reports. Examples: “Obstacle Detection Latency ≤ 200ms”, “Sensor Fusion Availability ≥ 99.5%”.
DescriptionText (Rich)—Detailed requirement narrative. Can include acceptance criteria, operational context, and implementation constraints. Supports Velocity macros and HTML formatting for cross-linking to design elements and test specifications.
VersionString1.0Version identifier tracking requirement evolution. Incremented when requirement is modified post-approval. Supports traceability auditing in Safety Readiness Scorecard. Format: N.N (e.g., 1.2, 2.0).

​
Derivation and Classification Fields

NameTypeDefaultDescription
Derived FromLink (Multi-item)—Upstream parent requirement(s) from which this system requirement is derived. Supports two link roles: refines (decomposition from customer requirement) and implements (realization in subsystem requirement). Enables V-model traceability validation. MultiItem: true allows one system requirement to refine multiple customer requirements.
ClassificationEnumeration—Categorizes requirement by safety context: functional (standard operational requirement), safety (ISO 26262 safety-related), interface (CAN, sensor protocol, vehicle network), performance (timing, throughput, accuracy), environmental (temperature, EMI). Used in Safety Readiness Scorecard filtering and FMEA coverage analysis.
SubtypeEnumerationFunctionalDistinguishes requirement type for ISO 26262 compliance reporting: functional (behavioral requirement), non-functional (performance/quality attribute), interface (external system boundary), safety-related (directly supports ASIL objective). Affects RTM view filtering and verification method selection.
PriorityEnumerationMediumImplementation sequence priority: Critical (blocking other features), High (priority 1 phase), Medium (priority 2 phase), Low (phase 3/deferred). Influences Gantt scheduling and risk assessment.
Risk LevelEnumeration—Pre-development risk assessment: Critical (safety risk if unimplemented), High (functional gap), Medium (performance degradation), Low (enhancement). Linked to HARA hazard severity (S) for ISO 26262 traceability.

​
Safety and Compliance Fields

NameTypeDefaultDescription
Special Characteristics (SC/CC)EnumerationNoneFlags requirement as Safety Critical (SC) or Conformance Critical (CC) per IATF 16949 APQP: SC (ASIL-derived, failure impacts functional safety), CC (regulatory/customer requirement, non-safety), none (standard requirement). Rendered in Whole RTM PowerSheet with orange (SC) and red (CC) highlighting. Used to filter control plan scope and design verification emphasis.
ASIL Derived FromLink (Single)—Links back to HARA Safety Goal with ASIL assignment (QM, A, B, C, D). Establishes bidirectional traceability: ASIL D system requirement must have corresponding ASIL D safety goal. Supports automated Safety Readiness Scorecard calculation. ASIL value automatically inherited if link is populated.
Safety GoalLink (Multi-item)—References one or more Safety Goals derived from HARA analysis that this system requirement implements. MultiItem: true for requirements satisfying multiple safety goals. Enables traceability from hazard through safety goal through system requirement through design requirement and test case.
Verification MethodEnumerationAnalysisSpecifies verification approach per ISO 26262 Part 8: Analysis (engineering review), Inspection (visual/dimensional), Test (dynamic test), Demonstration (operational proof), Review (formal review with evidence). Constrains acceptable test case type in V-model verification view.

​
Verification and Traceability Fields

NameTypeDefaultDescription
Verification Test CasesLink (Multi-item)—Links to Verification Test Cases that validate this system requirement through system-level test execution. Role: verifiedBy (incoming link). Enables V-model verification chain validation. PowerSheet filters by test status (Passed/Failed/Pending) to compute verification coverage percentage for Safety Readiness Scorecard.
Design RequirementsLink (Multi-item)—Downstream child design requirements refined from this system requirement. Role: refines (outgoing link). PowerSheet expansion query designRequirementChildren() used in Component RTM sheet to show decomposition hierarchy. Enables consistency validation: all child design requirements must inherit ASIL and SC/CC classification.
Validation Test CasesLink (Multi-item)—Links to Validation Test Cases verifying this system requirement against customer specifications (less common at system level; primarily used for top-level customer requirement validation). Role: validatedBy (incoming link). Distinguishes validation (customer intent) from verification (technical correctness).
Coverage StatusEnumeration (Computed)UncoveredAuto-calculated based on linked test cases: Covered (at least one test case linked and status=Passed), Partial (test cases linked but some pending/failed), Uncovered (no test cases). Appears in Safety Readiness Scorecard traceability metrics. Read-only; computed from verification test case links and their execution status.

​
Document and Workflow Fields

NameTypeDefaultDescription
StatusEnumerationDraftRequirement lifecycle state per document workflow: Draft (under development), Proposed (ready for review), Under Review (formal review in progress), Approved (review passed, baseline established), Rework Requested (review failed, changes required), Superseded (replaced by newer version). Controls field editability and approval visibility. Workflow transitions governed by system-requirement-workflow.xml.
AuthorUserCurrent userPolarion user who created the requirement. Read-only; automatically set at creation. Enables audit trail for ISO 26262 Part 8 documentation requirements. Displayed in document history and traceability reports.
CreatedTimestampNowTimestamp of requirement creation. Read-only. Used for version history and baseline dating. Format: ISO 8601 (YYYY-MM-DDTHH:MM:SSZ).
ModifiedTimestampNowTimestamp of last modification. Read-only; auto-updated by Polarion on any field change. Enables change tracking across review cycles. Used in Safety Readiness Scorecard to flag recently modified requirements.
ApproversUser (Multi-select)—List of users with approval authority for this requirement. Set by document owner or configuration manager. Approvers must sign off (via LiveDoc workflow transition) before requirement reaches Approved status. Supports role-based approval: Safety Lead, Design Lead, Architect.
CommentsText—Internal review comments and approval justification. Supports rich formatting and @mentions. Visible in requirement history. Not exported to formal specification documents. Used for ISO 26262 audit trail documentation.

​
Configuration Dependencies

​
Enumeration Definitions

Classification values (used in Safety Readiness Scorecard filtering):
  • functional — Operational behavior requirement
  • safety — Directly supports ISO 26262 ASIL allocation
  • interface — External system boundary (CAN, LIN, sensor protocols)
  • performance — Timing, accuracy, throughput constraint
  • environmental — Operating temperature, EMI, vibration
Subtype values (affects RTM filtering and verification method constraints):
  • functional — Behavioral requirement (most common)
  • non-functional — Quality attribute (performance, reliability, maintainability)
  • interface — Protocol or data structure specification
  • safety-related — Linked to functional safety objective
SC/CC Classification (IATF 16949 APQP):
  • SC — Safety Critical: ASIL-derived, failure violates functional safety (orange highlighting in PowerSheet)
  • CC — Conformance Critical: regulatory/customer critical, non-safety (red highlighting in PowerSheet)
  • none — Standard requirement (white background)
Verification Method (ISO 26262-3:2018 Section 7.4.5):
  • Analysis — Engineering review of requirement feasibility
  • Inspection — Visual, dimensional, or configuration audit
  • Test — Dynamic test with acceptance criteria measurement
  • Demonstration — Operational proof under real or simulated conditions
  • Review — Formal review with stakeholder sign-off
System requirements participate in bidirectional traceability: 
UPSTREAM (Refined From):
  refines link role: customerRequirement ←→ [derivation]
  System requirement derived by decomposing customer requirement

DOWNSTREAM (Refines Into):
  refines link role: [decomposition]→ subsystemRequirement
  System requirement refined into subsystem requirements
  
  refines link role: [decomposition]→ designRequirement (via subsystem)
  System requirement transitively refines design requirements

VERIFICATION TRACEABILITY:
  verifiedBy link role: [test link]← verificationTestCase
  System requirement verified by system-level test execution

SAFETY ALLOCATION:
  derivedFrom link role: [asil allocation]← safetyGoal
  System requirement traces back to ASIL-assigned safety goal

​
Rendering in PowerSheet Views

​
Whole RTM Sheet

System requirements appear in the System Requirements Column Group (purple header) of the Whole RTM PowerSheet:
ColumnPurpose
SR IDRead-only system requirement identifier (auto-highlighted in outline number order)
SR DescriptionEditable requirement text; collapse target when SR group is minimized
Customer Req UplinkMulti-item expansion column showing parent customer requirements; green header indicates upstream traceability
Design Req DownlinkMulti-item expansion column showing child design requirements; blue header indicates downstream decomposition
Verification TestsMulti-item test case column; orange header indicates test traceability
SC/CC ClassificationCustom renderer displays ‘SC’ or ‘CC’ label with color coding (orange/red) instead of raw enum value
Collapse Behavior: When System Requirements column group is minimized, SR Description column remains visible for quick scanning; all other columns collapse.

​
Component RTM Sheet

System requirements appear in the upward traceability column from subsystem requirements:
ColumnPurpose
System Req UplinkMulti-item expansion column under each subsystem requirement; displays parent system requirements this subsystem refines
This enables engineers to trace subsystem requirement back to originating system requirement and verify parent/child consistency.

​
Code Example: System Requirement XML Definition

<workitemType>
  <id>sysReq</id>
  <name>System Requirement</name>
  <category>requirement</category>
  <customFields>
    <customField>
      <id>derivedFrom</id>
      <type>link</type>
      <linkRole>refines</linkRole>
      <multiItem>true</multiItem>
      <description>Upstream customer requirements</description>
    </customField>
    <customField>
      <id>classification</id>
      <type>enumeration</type>
      <enumId>requirementClassification</enumId>
      <required>false</required>
    </customField>
    <customField>
      <id>specialCharacteristics</id>
      <type>enumeration</type>
      <enumId>scccClassification</enumId>
      <description>IATF 16949 SC/CC flag</description>
    </customField>
    <customField>
      <id>asilDerivedFrom</id>
      <type>link</type>
      <linkRole>derivedFrom</linkRole>
      <multiItem>false</multiItem>
      <description>Single safety goal reference for ASIL allocation</description>
    </customField>
    <customField>
      <id>verificationMethod</id>
      <type>enumeration</type>
      <enumId>verificationMethod</enumId>
      <description>ISO 26262-3 verification approach</description>
    </customField>
  </customFields>
</workitemType>

​
Typical Workflow Sequence

  1. Creation: Customer requirement approved → engineer creates draft system requirement, references upstream via derivedFrom link
  2. Classification: Assign classification (safety vs. functional), subType (functional vs. interface), specialCharacteristics (SC/CC flag)
  3. Safety Linking: If safety-critical, populate asilDerivedFrom link to corresponding Safety Goal from HARA
  4. Decomposition: Create subsystem and design requirements; reference via refines link in downstream requirements
  5. Verification Planning: Identify verification test cases; populate verificationTestCases link
  6. Review & Approval: Transition workflow to Proposed → Under Review → Approved; approvers sign off
  7. Baseline: Approved system requirements become baseline for design phase; changes require change request
  8. Traceability Validation: Safety Readiness Scorecard computes coverage: system requirements with verification tests linked / total system requirements

​
Best Practices

Do not modify ASIL-derived system requirements without updating linked safety goals and child design requirements. ASIL classification must flow consistently down the V-model: Safety Goal (ASIL source) → System Requirement (inherited) → Design Requirement (inherited) → Test Case (inherited). Inconsistency triggers Safety Readiness Scorecard warning.
When marking a system requirement as Safety Critical (SC), ensure all child design requirements also marked SC. Control Plan items for SC design requirements require enhanced process controls per IATF 16949. This constraint is enforced in the Component RTM PowerSheet via validation formulas.
Select Verification Method conservatively per ISO 26262-3: if requirement is safety-critical (ASIL ≥ A), must use Test or Demonstration; Analysis alone insufficient for safety claims. Form layout can enforce this constraint via dependent field visibility rules (configure in document workflow XML).
System requirements with Coverage Status = Uncovered (no verification test cases) appear in orange on the Whole RTM PowerSheet and in the Safety Readiness Scorecard as gaps. Resolve before publishing document baseline. Use Reports → Requirements Traceability Report to generate detailed gap list.

​
Integration with Other Components

  • HARA Safety Goals — System requirements with ASIL allocation trace back via asilDerivedFrom link to safety goals that originated in HARA document
  • Design Requirements — Subsystem and design requirements downstream from system requirement inherit ASIL and SC/CC classification via link constraints
  • Verification Test Cases — Test cases linked via verificationTestCases compute coverage percentage in Safety Readiness Scorecard
  • Whole RTM PowerSheet — System requirements displayed in purple column group; comparison queries show parent customer requirements (green) and child design requirements (blue)
  • Component RTM PowerSheet — System requirements shown as uplink from subsystem requirements; enables traceability drill-down
  • FMEA Documents — System-level FMEA analyzes failure of functions allocated to system elements derived from system requirements; creates bidirectional traceability through function allocation and characteristic linking

​
Version Information

AspectVersion
Form Layout FormatPolarion 2024 LiveDoc Schema
ISO 26262 ReferencePart 3:2018 (Concept) and Part 4:2018 (System Design)
AIAG-VDA FMEA ReferenceFMEA Handbook 5th Edition (Action Priority formula)
IATF 16949 ReferenceSection 8.3.4.1 (Special Characteristics)
Last UpdatedFeb 15, 2026
For detailed information on system requirement traceability, see Traceability Model. For verification test case creation, see Create Verification Test Cases. For PowerSheet configuration reference, see Whole RTM PowerSheet.