Skip to main content

​
Prerequisites

  • Requirements exist at customer, system, subsystem, or design level
  • You understand which requirements relate to safety or regulatory compliance
  • You have edit permissions on the requirement documents

​
Steps

​
1. Open the Requirement Document

Navigate to the Requirements space and open the document containing the requirements you need to classify:
  • Customer Specification → Requirements/CUSTOMER-REQS
  • System Requirements Specification → Requirements/SYS-REQS
  • Subsystem Requirements Specification → Requirements/SUBRS-*
  • Design Requirements Specification → Design/DRS-*

​
2. Open the Work Item Editor

Click on the requirement ID or title to open the work item detail view. Click Edit to enable editing mode.

​
3. Set the Classification Field

Locate the Classification field in the work item form. Select one of the following values:
  • SC (Safety Critical) — Requirement directly impacts functional safety per ISO 26262
  • CC (Conformance Critical) — Requirement mandated by regulatory standards (ECE R79, FMVSS, etc.) but not safety-classified
  • (Leave blank) — Standard requirement with normal traceability obligations
Use SC for requirements that trace to Safety Goals from HARA analysis. Use CC for regulatory requirements that don’t carry ASIL classification but still require verification evidence.

​
4. Save the Work Item

Click Save to persist the classification. The requirement will now appear with SC/CC indicators in PowerSheet views.

​
How Classification Affects Traceability

SC and CC classified requirements trigger enhanced traceability rules:
The FMEA Coverage Report on the Design space dashboard flags any SC/CC requirement that lacks a linked failure mode through the refinement chain. Gaps will block document approval in the review workflow.

​
Visual Indicators in PowerSheet Views

SC/CC classification appears with color-coded labels in traceability matrices:
ViewColumnSC ColorCC Color
Whole RTMClassificationOrange labelRed label
Component RTMClassificationOrange labelRed label
Design Verification SheetClassificationOrange labelRed label
The classification field uses a custom renderer that displays SC or CC text instead of the raw enumeration value.

​
Bulk Classification Workflow

For large document sets, use Polarion’s table view for efficient bulk editing:
  1. Navigate to the document containing multiple requirements
  2. Switch to Table view (icon in document toolbar)
  3. Add the Classification column to the table layout
  4. Click cells to edit classification inline
  5. Use Ctrl+S to save all changes at once

​
Verification

After classifying requirements, verify correct propagation:
  1. Open the Safety Readiness Scorecard from the Home dashboard
  2. Check the SC/CC Requirements Count metric — your newly classified requirements should appear in the count
  3. Open the FMEA Coverage Report from the Design space dashboard
  4. Verify that newly SC/CC classified requirements appear in the gap analysis if not yet linked to failure modes
Classification propagates through the requirement hierarchy. If a parent requirement is SC, child requirements typically inherit SC classification to maintain traceability chain integrity.

​
Common Pitfalls

If a parent requirement is SC but child requirements are unclassified, the Safety Readiness Scorecard will flag incomplete classification propagation. Ensure consistency across refinement levels.
CC classification should reference the applicable standard in the requirement description (e.g., “Per ECE R79 §5.3.2”). Without explicit standard citation, reviewers cannot validate conformance claims during document approval.

​
See Also