Skip to main content

​
Overview

System Requirements occupy the second level of the requirements V-model cascade: diagram System Requirements are managed in systemRequirementsSpecification LiveDocs within the Requirements space and participate in bidirectional traceability with verification test cases, design requirements, and FMEA failure modes.
System Requirements describe system-level functionality applicable across all subsystems (e.g., “System shall detect obstacles within 100m”). Subsystem Requirements add component-specific constraints (e.g., “Camera subsystem shall provide 100m detection range”). The Polarion RTM model enforces this decomposition via the SubsystemRequirement entity type, which uses the same polarion type (sysReq) but constrains to subsystemRequirementsSpecification documents.

​
Standard Properties

PropertyTypeDefaultDescription
IDTextAuto-generatedUnique system requirement identifier within the project prefix (e.g., TST2-SR-001). Assigned by Polarion on work item creation.
TitleTextRequiredConcise, single-sentence requirement statement using imperative mood. Example: “System shall detect obstacles within specified range”.
DescriptionRich TextEmptyDetailed requirement specification including rationale, constraints, exceptions, and references to customer requirements or standards. Supports formatted text, tables, and embedded images.
StatusEnumerationDraftWork item lifecycle state: Draft (authoring), In Review (awaiting approval), Approved (accepted), Obsolete (superseded). Managed via document workflow transitions.
Outline NumberAuto-generatedHierarchicalNumeric outline position within the parent document (e.g., 1, 1.1, 1.1.1). Enables logical navigation and reference in traceability reports.
SeverityEnumerationNoneOptional field indicating criticality for prioritization. Values depend on project configuration.
  • Use imperative voice: “System shall detect…” not “Detection capability…”
  • Quantify objectives where possible: “within 100m range” not “at long range”
  • One requirement per work item—avoid compound statements with “and”
  • Keep under 100 characters for readability in PowerSheet and list views

​
Classification Properties

System Requirements use classification fields to support ISO 26262, AIAG-VDA FMEA, and IATF workflows:
PropertyTypeDefaultDescription
classificationEnumerationNoneSC/CC (Special Characteristic) categorization per IATF 16949 APQP. Values: SC (Special Characteristic—critical to safety/function), CC (Critical Characteristic—key performance), None (standard requirement). Used to prioritize characteristics linked to this requirement for design verification and control plan inclusion.
subTypeEnumerationFunctionalDesign Requirement subtype (used when requirement is later refined into design requirements). Values: Functional, Non-Functional, Interface, Performance, Constraint. Inherited by refined Design Requirements; allows filtering by engineering discipline.
Example classification workflow:
  • Customer Requirement: “Vehicle shall brake safely” (unclassified)
  • System Requirement: “System shall apply proportional braking force to all wheels” (SC—safety-critical)
  • Design Requirements (refined): “ECU shall compute brake pressure” (SC, Functional), “CAN interface shall transmit brake command within 50ms” (SC, Interface)
System Requirements participate in the following link relationships within the RTM domain model:
Link RoleTarget TypeDescriptionCardinality
refinesCustomer RequirementFlows from customer needs into system-level detail. Each system requirement refines one or more customer requirements to provide specific measurable targets. Bidirectional traceability.Many-to-Many
refinesFromCustomer RequirementReverse view of refines link. Queried in RTM PowerSheets to show parent customer requirements.Many-to-Many
Link RoleTarget TypeDescriptionCardinality
refined bySubsystem RequirementDecomposes system requirement across subsystems. Each subsystem adds constraints and allocates functionality to hardware/software components. Enables multi-team parallel development.One-to-Many
refinesIntoSubsystem RequirementReverse view of refined by. Used in RTM PowerSheets to show child requirements.One-to-Many
refined byDesign RequirementDirect refinement when system-level design requirements exist (bypass subsystem level).One-to-Many
Link RoleTarget TypeDescriptionCardinality
verifiesTest CaseBackward link from verification test cases to system requirements. Test cases marked with verifies link role verify one system requirement per test case. Used in System Verification PowerSheet to track coverage.One-to-Many
verified byTest CaseForward link showing which test cases verify this requirement. Central to V-model traceability and safety compliance reporting.One-to-Many
Link RoleTarget TypeDescriptionCardinality
assessedByFailure ModeFMEA failure modes assessing this requirement’s potential failures. Used to ensure FMEA covers all system requirements at appropriate decomposition level.One-to-Many
assessesSafety GoalSafety Goals derived from system requirements in ISO 26262 HARA. System requirement may flow to multiple safety goals.One-to-Many
linkedWorkItemsAnyGeneral-purpose link for cross-references (e.g., to design documents, standards clauses, regulatory notes).Many-to-Many

​
Document Constraints

System Requirements are created exclusively within systemRequirementsSpecification LiveDocs. The Polarion RTM model enforces this via: 
SystemRequirement:
  polarionType: "sysReq"
  constraint: "pick"
  documentType: "systemRequirementsSpecification"
  moduleFolder: "Requirements"
  description: "System-level requirement. Must be placed in an SRS document."
Constraint Behavior:
  • When creating a new System Requirement, Polarion presents a picker dialog filtered to show only LiveDocs of type systemRequirementsSpecification
  • Existing System Requirements cannot be moved to other document types via drag-and-drop (Risksheet or direct edit)
  • Bulk operations that would violate document type constraint are rejected
If you encounter a System Requirement appearing in a non-SRS document (e.g., riskSpecification), this indicates either:
  • A data migration error during project import
  • Manual manipulation via SVN (not recommended)
  • A configuration inconsistency
Always use the Consistency Checker to validate RTM model integrity before reporting the issue.

​
Custom Fields

System Requirements support custom fields to capture safety and quality metadata:
Custom FieldTypeValuesUsed ByDescription
requirementPriorityEnumerationHigh, Medium, LowRoadmap planningPriority for phased implementation or MVP scope
traceabilityStatusRead-onlyTraced, Partial, UntracedCoverage reportsAuto-set based on presence of refines/refined-by/verified-by links
safetyRelevantBooleanTrue / FalseVerification planningFlags requirements linked (direct or via Safety Goal) to ASIL hazards for enhanced V&V rigor
releaseTargetEnumerationv1.0, v1.1, v2.0, etc.Release planningMaps requirement to product release version for scheduling
Access custom fields via System Requirement Custom Fields Reference for detailed enumeration values and usage rules.

​
Verification and Test Traceability

System Requirements are verified at the System Verification phase of the V-model. Each requirement must have:
  1. At least one System Verification Test Case linked via verified by
  2. Test case execution evidence (test run results, pass/fail status)
  3. Coverage closure before document approval

​
System Verification PowerSheet

The System Verification PowerSheet provides interactive traceability matrix:
  • System Requirement (from SRS)
    • Test Case ID (from Testing/SystemVerificationSpec)
    • Test Title
    • Test Status
    • Verification Evidence
      • Test Run Result (PASS/FAIL/BLOCKED)
      • Attachment (test report, log, measurement data)
    • Verification Owner
Query Example: 
SELECT SystemRequirement 
WHERE document.type = "systemRequirementsSpecification"
  AND verified_by count = 0
ORDER BY id
This query identifies unverified system requirements—top candidates for coverage closure in safety readiness audits.

​
FMEA Integration

System Requirements participate in FMEA at multiple levels:
FMEA LevelAssessmentLink PatternPurpose
System FMEAFunctions (derived from system requirements)Failure Mode assesses FunctionIdentify how system-level functions can fail; trace back to requirements impact
Subsystem FMEASubsystem Requirements (refined from system reqs)Failure Mode assesses Subsystem RequirementDecomposed FMEA following system decomposition
Design FMEADesign Requirements (refined from system reqs)Failure Mode assesses CharacteristicComponent-level FMEA tied to measurable design criteria
Example Traceability Chain:
  • SR-001: “System shall detect obstacles within 100m range”
    • refines: CR-001 (Customer Requirement)
    • refined by: SubsystemReq (Camera subsystem detection requirement)
    • verified by: Test Case (System Verification — Range Test)
    • assesses Failure Mode: “Object detection fails due to camera malfunction”
      • Control: “Add redundant sensor fusion”
      • Pre-Mitigation AP: High
      • Post-Mitigation AP: Medium (detection coverage reduced to 90%)
    • assesses Safety Goal: SG-02 “Ensure obstacle detection reliability” (ASIL B)

​
RTM Model Integration

System Requirements are the anchor point for the whole system V-model: 
┌─────────────────────────────────┐
│   System Requirement (CENTER)   │
└─────────────────────────────────┘
        ↙           ↓           ↖
   Upstream    Lateral      Downstream
        ↙           ↓           ↖
Customer      Safety Goal    Subsystem
Requirement   (HARA)         Requirement
                ↓                  ↓
          Function           Design
          (FMEA)            Requirement
                ↓                  ↓
          Failure Mode      Characteristic
          (RPN calc)        (Meas. target)
                ↓                  ↓
          Risk Control      Test Case (SV)
          (Mitigation)      (Verification)
See RTM Domain Model for complete entity relationship diagram and Traceability Model for detailed link semantics.

​
Common Workflows

​
Creating a System Requirement

  1. Open or create a systemRequirementsSpecification LiveDoc in the Requirements space
  2. Right-click → “Create Work Item” → Select SystemRequirement type
  3. Enter Title (imperative: “System shall…”)
  4. Add Description with acceptance criteria and rationale
  5. Set Classification (SC/CC if safety-critical per IATF 16949)
  6. Save and link upstream to Customer Requirement via refines
  7. Create System Verification Test Case and link via verified by
Related Guide: Create System Requirements

​
Deriving Subsystem Requirements

  1. Open System Requirement in RTM PowerSheet or work item view
  2. In “Refined By” section, create Subsystem Requirements for each subsystem
  3. Each Subsystem Requirement inherits classification and adds subsystem-specific constraints
  4. Link each Subsystem Requirement refines the System Requirement (auto-created)
  5. Continue decomposition to Design Requirements as needed
Related Guide: Refine Requirements Across Levels

​
Verifying System Requirements

  1. Open System Verification PowerSheet
  2. System Requirements appear in left column (read-only)
  3. For each requirement, add Test Cases in center column
  4. For each Test Case, add Verification Evidence in right column
  5. System coverage report auto-calculates: (Verified Requirements / Total Requirements) × 100%
Related Guide: Check Verification Coverage

​
Enumerations and Allowed Values

​
Status Enumeration

ValueMeaningTransition Rules
DraftAuthoring in progress→ In Review (submit)
In ReviewAwaiting approval from safety engineer or design lead→ Approved (approve) or → Draft (reject)
ApprovedAccepted and baselined→ Obsolete (supersede)
ObsoleteReplaced by newer requirementRead-only; cannot transition back

​
Severity Enumeration (Optional)

ValueMeaningUsed For
CriticalSafety-critical; ASIL ≥ A or SC characteristicHighlights in verification planning
HighPerformance-critical; affects user experienceMedium priority for test execution
MediumStandard functional requirementStandard priority
LowNice-to-have or future considerationBacklog/phase-2 candidates

​
Common Questions

Q: What’s the difference between System Requirements and Subsystem Requirements? A: System Requirements describe end-to-end system capabilities (e.g., “detect obstacles”). Subsystem Requirements add component-specific constraints (e.g., “camera subsystem shall provide 100m range”). Both use the same Polarion type (sysReq) but different document types to enforce separation of concerns and enable multi-team parallel work. Q: Can I move a System Requirement between documents? A: No. The document type constraint enforces that System Requirements stay in systemRequirementsSpecification documents. To restructure requirements, delete the work item and recreate it in the target document, then re-establish all links. Q: How do I track requirement status changes? A: Use the Traceability Status read-only field (auto-set by Polarion) and enable change history auditing via Document Workflow. Approval workflows integrate with Polarion’s built-in change notification system. Q: What happens if a system requirement is never refined? A: Unrefined System Requirements are flagged in the Requirements Traceability Report as coverage gaps. They remain valid (may represent system-level qualities not decomposed further) but should be explicitly reviewed during safety readiness audits to confirm intentionality.