Skip to main content

Steps

1. Navigate to Design Requirements Specification

  1. Click ** Design** in the left navigation
  2. Locate the appropriate Design Requirements Specification (DRS) document for your component
    • Document naming convention: DRS-<ComponentName>
    • Example: DRS-BrakingModule, DRS-SensorInterface
  3. Click the document title to open it
Large projects maintain separate DRS documents per subsystem or component. This enables parallel development across engineering teams while maintaining clean traceability boundaries.

2. Create New Design Requirement Work Item

  1. In the opened DRS document, click + New Work Item in the document toolbar
  2. Select Design Requirement from the work item type dropdown
  3. The work item form will open with required fields

3. Configure Required Fields

ID (auto-generated)
Polarion assigns the ID automatically based on project prefix. Example: DRS-456
Title
Enter a concise, implementation-focused title:
  • Good: “ECU shall process brake sensor input within 10ms”
  • Bad: “Braking system performance” (too vague)
Description
Provide detailed technical specification including:
  • Functional behavior
  • Interface definitions
  • Performance criteria
  • Constraints or dependencies
diagram SubType (enumeration)
Classify the design requirement:
SubTypeUse When
functionalDefines system behavior or operation
interfaceSpecifies inter-component communication
performanceSets timing, throughput, or resource limits
safetyAddresses safety mechanisms per ISO 26262 Part 5/6
The Safety Readiness Scorecard uses subType to separate ISO 26262 Part 5 (hardware) from Part 6 (software) compliance metrics. Always set this field to enable accurate compliance tracking.
Classification (SC/CC)
If the design requirement relates to a safety-critical or cybersecurity-critical characteristic, set classification:
  • sc → Safety Critical (orange badge)
  • cc → Conformance Critical (red badge)
  • Leave blank for non-critical requirements

4. Establish Upward Traceability

Link the design requirement to its parent subsystem requirement:
  1. Click Add Link in the work item form
  2. Select link role: refinesSubsystem Requirement
  3. Search for and select the parent subsystem requirement (e.g., SUBRS-123)
  4. Click Add
For efficient bulk authoring, use the Component RTM PowerSheet view. It displays subsystem requirements in the left group and lets you create child design requirements inline with automatic upward traceability links.
diagram While you can defer this until test authoring, establishing forward traceability early helps verification planning:
  1. In the design requirement form, click Add Link
  2. Select link role: verified byVerification Test Case
  3. If test cases already exist, select them; otherwise skip this step
  4. PowerSheet entity factory will create test cases in Testing/DesignVerificationSpecification module when you add tests from the Design Verification Sheet
Design requirements are verified (right side of V-model), not validated. Validation applies to customer requirements. Use verificationTestCases link role, not validationTestCases.

6. Save the Work Item

Click Save in the form toolbar. The design requirement is now:
  • Created in the DRS document
  • Linked to parent subsystem requirement (upward traceability)
  • Available for DFMEA analysis (if classified as SC/CC)
  • Ready for verification test case linkage

Verification

After saving, verify proper integration:
  1. Check Component RTM PowerSheet:
    Navigate to RequirementsComponent RTM. Your new design requirement should appear nested under its parent subsystem requirement with upward links visible.
  2. Verify Design Space Dashboard:
    Go to ** Design** space home. The “Design Requirements to System Requirements” coverage metric should reflect the new requirement with proper upward traceability.
  3. Check Safety Readiness Scorecard (if SC/CC):
    If you set classification: sc or cc, the requirement should increment the SC/CC Design Requirements count in the Safety Readiness Scorecard.
If a design requirement derives from a safety-critical subsystem requirement but lacks the classification field, it won’t appear in Safety Readiness metrics or DFMEA coverage reports. Always propagate SC/CC classification down the V-model.

See Also