Overview
| Property | Value |
|---|
| Work Item Type ID | customerRequirement |
| Polarion Type | sysReq (reused with document constraint) |
| Document Constraint | CUSTOMER-REQS module in Requirements folder |
| Classification | User-visible requirement (subject to SC/CC marking) |
| V-Model Position | Level 1 — top of requirements cascade |
| Primary Link Role | refines (outgoing to System Requirements) |
| Validation Link Role | validates (incoming from Validation Test Cases) |
| Standards | ISO 26262 Part 3 (Concept), ISO 14971, AIAG-VDA APQP |
Core Properties
| Name | Type | Default | Description |
|---|
title | String | (required) | Requirement statement (e.g., “System shall detect obstacles within 100m”) |
description | Text (rich HTML) | (empty) | Detailed explanation, rationale, and context for the requirement |
outlineNumber | Auto-generated | Hierarchical (e.g., CustReq-1.2.3) | Automatic outline numbering based on document hierarchy |
status | Enum (workflow) | DRAFT | Document workflow state: DRAFT → SUBMITTED → APPROVED → PUBLISHED |
classification | Enum | (none) | Safety classification: SC (Safety Critical), CC (Critical Characteristic), or QM (Quality Management) |
Classification and Traceability
Safety Classification
Customer requirements can be marked as safety-critical to trigger traceability and FMEA coverage checks:
classification: "SC" # Safety Critical - must be decomposed to safety goals and FMEA
classification: "CC" # Critical Characteristic - must link to control plan
classification: "QM" # Quality Management - standard traceability only
Use SC when the requirement directly relates to hazard mitigation (e.g., “System shall detect obstacles”). Use CC for non-safety requirements that affect product quality or manufacturability (e.g., “Housing shall withstand 5G vibration”).
RTM Relationships
Customer Requirements participate in the following traceability relationships:
| Link Role | Direction | Target Type | Description |
|---|
refines | Outgoing | System Requirement | Decomposes into system-level requirements (1:many) |
validates | Incoming | Validation Test Case | Verified by validation test execution |
linkedWorkItems | Bidirectional | Any | Generic link for coverage tracking |
Document Constraints
Customer Requirements are always created within the CUSTOMER-REQS module, which is automatically scoped to the Requirements folder:
Auto-creation workflow:
When you create a Customer Requirement work item in the risksheet or from the Requirements dashboard, Polarion automatically:
- Creates or locates the
CUSTOMER-REQS LiveDoc module
- Places the work item in that module
- Applies document-level workflow (DRAFT → SUBMITTED → APPROVED → PUBLISHED)
Do not manually move customer requirements to other modules. The document constraint ensures they stay in CUSTOMER-REQS for proper data integrity and RTM queries.
Custom Fields
Customer Requirements inherit standard custom fields from the system requirements template:
| Field Name | Type | Example | Purpose |
|---|
customRequirementType | Enum | Functional, Performance, Safety, Interface | Categorizes requirement type for filtering and reporting |
regulatory.standard | Multi-select | ISO 26262, SOTIF, IATF | Standards that motivated this requirement |
traceability.upstreamSource | Link | External specification document | Links to regulatory spec or customer RFP |
traceability.parentSystem | Work item link | System Element | Optional scoping to system, subsystem, or component |
Usage in TestAuto2
Typical Workflow
- Create Customer Requirement in CUSTOMER-REQS module
- Mark as SC/CC if safety-related
- Create System Requirements that refine it (1 customer req to N system reqs)
- Link to Validation Test Cases (validates relationship for end-to-end verification)
- Approve document workflow (status changes to PUBLISHED)
Example: AEB System Customer Requirements
| CustReq ID | Title | Classification | Validation Link |
|---|
| CustReq-1 | System shall detect obstacles at speeds above 10 km/h | SC | ValTC-01 (Obstacle Detection Test) |
| CustReq-2 | System shall apply emergency braking within 500ms | SC | ValTC-02 (Braking Latency Test) |
| CustReq-3 | System shall operate in fog, rain, and snow conditions | SC | ValTC-03 (Weather Robustness Test) |
| CustReq-4 | System shall not brake during normal lane changes | SC | ValTC-04 (False Positive Mitigation Test) |
| CustReq-5 | Housing shall be IP67 rated (dust/water ingress) | CC | ValTC-05 (Environmental Sealing Test) |
Decomposition to System Requirements
Customer Requirements are never implemented directly—they are always decomposed into System Requirements through the refines relationship:
- CustReq-1: “Detect obstacles at speeds > 10 km/h”
- refines to:
- SR-10: “Sensor fusion shall provide obstacle distance within 0.5m”
- SR-11: “ECU shall process sensor data within 100ms”
- SR-12: “CAN interface shall transmit decision at 50Hz rate”
This decomposition ensures:
- Traceability: Every customer need is explicitly satisfied by system requirements
- Testability: Validation tests verify the top-level requirement
- Coverage: Requirements Traceability Report checks that all customer reqs have at least one system req refinement
One customer requirement typically decomposes to 2–5 system requirements. If decomposition is 1:1, consider whether the customer requirement should be promoted to system requirement level instead.
Integration with Safety Analysis
HARA Linkage
If a Customer Requirement relates to hazard mitigation, create a corresponding Safety Goal and link both to the hazard:
Hazard: “Failure to detect obstacle”
├─→ derives Safety Goal: “Ensure reliable obstacle detection”
└─→ satisfies Customer Req: “System shall detect obstacles at >10 km/h”
└─→ ASIL Classification: D
FMEA Coverage
Safety-critical customer requirements (SC classification) must have corresponding failure mode analysis:
Coverage check rule:
For each Customer Requirement with classification=SC:
✓ At least one System Requirement must refine it
✓ Each System Requirement must have ≥1 related Function or System Element
✓ Each Function/System Element must have ≥1 Failure Mode (FMEA)
✓ Each Failure Mode must have Risk Controls (mitigates relationship)
PowerSheet Queries
Customer Requirements are queried by the Whole RTM PowerSheet and role-based RTM views:
<expansionQuery>
itemType: customerRequirement
where: status != "DRAFT"
sortBy: outlineNumber
</expansionQuery>
Validation and Verification
Validation Test Cases
Validation Test Cases verify that customer requirements are satisfied end-to-end from a user/system perspective:
| Validation Test Case | Links Customer Req | Test Scenario |
|---|
| ValTC-01 | CustReq-1 | Drive at 15 km/h, obstacle at 80m ahead, verify detection trigger |
| ValTC-02 | CustReq-2 | Triggered detection, measure braking response time |
| ValTC-03 | CustReq-3 | Repeat detection tests in fog/rain/snow conditions |
| ValTC-04 | CustReq-4 | Lane change maneuver without obstacle, verify no false braking |
Traceability Metrics
The Safety Readiness Scorecard tracks customer requirement validation coverage:
Customer Requirements Validation Coverage =
(Customer Reqs with ≥1 linked Validation Test Case) / Total Customer Reqs × 100%
Example: 12 CustReqs validated out of 25 total = 48% coverage
Document Workflow
Customer Requirements follow the standard Polarion document workflow:
| State | Editable | Visible in RTM | Purpose |
|---|
| DRAFT | Yes | No | Work-in-progress, not yet shared |
| SUBMITTED | No | Yes (read-only) | Awaiting approval review |
| APPROVED | No | Yes | Approved, awaiting publication |
| PUBLISHED | No | Yes | Active, used in traceability chains |
Best Practices
Write customer requirements in positive, testable language: “System shall detect…” (not “System should try to detect…”). Each requirement must be independently verifiable by a test case.
Keep customer requirements at the stakeholder/user level, not design details. “System shall brake smoothly” is customer-level; “Brake pressure shall ramp at 500 psi/s” is design-level (System Requirement).
Review SC/CC classifications annually. If a customer requirement is marked SC but no System Requirements derive from it, it may be unnecessary or should be deleted. Use the Safety Readiness Scorecard to audit stale requirements.
If a customer requirement is superseded, mark it as DEPRECATED (if workflow allows) rather than deleting. Deletion breaks historical traceability and FMEA coverage audits.
Related Pages
