Subsystem Verification Sheet

​

Purpose and Use Case

Subsystem Verification Sheet supports the left-side of the ISO 26262 V-model: requirements flow down from System Requirements through Subsystem Requirements to Design Requirements, with corresponding verification flowing up from Design Verification Tests through Subsystem Verification Tests to System Verification Tests. This sheet is used by V&V engineers and subsystem leads to:

• Plan verification test cases for each subsystem requirement
• Link test cases to requirements via the testCases relationship
• Track verification evidence and test status
• Ensure complete subsystem-level coverage before system integration testing
• Generate verification traceability reports

​

Configuration Properties

​

Entity Source Query

The source query starts with all SubsystemRequirement work items in the current document context and expands through the testCases link role to show all linked VerificationTestCase items. Each test case creates a denormalized row under its parent requirement.

​

Column Group Architecture

​

Subsystem Requirements Column Group

Each subsystem requirement appears as a single row with the following columns: Requirement ID (objectId) — Read-only, stable work item identifier (e.g., SUBRS-001)

• Formatter: readOnly
• Width: 80px
• Serves as cross-reference anchor for traceability reports

Requirement Title — Primary navigation field with bold formatting and keyboard focus

• Formatter: boldReadOnly
• Width: 250px
• Has keyboardFocus: true — pressing Tab from ID field lands here
• Enables efficient keyboard-driven navigation through requirements

Requirement Description — Full requirement statement, read-only, serves as collapse target

• Formatter: readOnly
• Width: 400px
• Visible when group is expanded; hidden when collapsed to maximize test case columns
• Provides requirement context without horizontal scrolling

Classification — Safety classification level (e.g., safety-related, non-safety)

• Formatter: readOnly
• Width: 150px
• Indicates safety criticality; inherited from parent System Requirement
• Used by V&V engineers to tailor verification rigor

Parent System Requirement — Upward traceability link showing parent requirement

• Type: link expansion
• Formatter: readOnly
• Shows parent system requirement ID and title
• Documents V-model decomposition chain for traceability audits

​

Verification Tests Column Group

Each test case linked to a subsystem requirement appears as a sub-row under that requirement with the following columns: Test Case ID (testCases.testCase.objectId) — Verification test case identifier

• Formatter: readOnly
• Width: 80px
• References work item created in Testing space document
• Links to test case details via work item ID

Test Title (testCases.testCase.title) — Test case name and objective

• Formatter: boldReadOnly
• Width: 300px
• Multi-line support enabled for detailed test descriptions
• Serves as collapse target for test group

Test Status (testCases.testCase.status) — Workflow state (draft, approved, passed, failed)

• Formatter: conditional background color
• Width: 100px
• Editable; reflects test execution state
• Color-coded: green=passed, red=failed, orange=pending

Coverage Evidence (testCases.testCase.evidenceLink) — Link to test result artifact

• Type: URL or document link
• Width: 250px
• Editable; points to test report, analysis document, or test run result
• Enables audit trail linking requirements → tests → evidence

​

Relationship Expansion Pattern

The PowerSheet traverses RTM relationships as follows: Expansion Cardinality: One-to-many. Each subsystem requirement can have zero or more linked test cases. If a requirement has no test cases, it appears with empty test columns—highlighting verification gaps. Document Scope: The query constrains to the current document. When embedded in a Polarion LiveDoc, it shows only requirements and tests from that document. Standalone PowerSheets (via wiki page widgets) can optionally filter by document parameter.

​

Entity Factory Configuration

The PowerSheet includes entity factory settings to streamline test case creation directly from the sheet: Usage: When a user clicks the “Add Test Case” action on a requirement row, the system:

1. Creates a new VerificationTestCase work item in Testing/SubsystemVerificationSpecification
2. Auto-populates the verifiableRequirement field with the parent SubsystemRequirement ID
3. Creates the testCases link connecting the requirement to the new test
4. Focuses the cursor on the test title field for immediate documentation

This eliminates manual document navigation, ensuring test cases land in the correct module with proper traceability established.

​

Visual Elements and Formatting

​

Read-Only Protection

All requirement columns use the readOnly formatter, displaying a light grey background to signal that editing is prohibited. This design principle reflects the fact that requirements are authored and maintained in their source documents (Requirements space); the Verification Sheet is for tracking test coverage, not editing requirements.

​

Conditional Formatting

Test status fields use conditional formatting to provide visual workflow state:

• Green background: Status = “Passed” (verification complete)
• Orange background: Status = “Pending” or “In Progress” (verification ongoing)
• Red background: Status = “Failed” (verification failed, rework needed)
• Grey background: Status = “Blocked” (external dependency preventing test)

This color-coding enables quick scan of verification completion across subsystems.

​

Collapse Behavior

Both column groups support collapsing to maximize screen real estate: Requirement Group Collapsed: Shows only ID + Description columns, hiding Title/Classification/Parent fields. Test columns remain fully visible, allowing focus on verification details. Test Group Collapsed: Shows only ID + Title columns, hiding Status/Evidence fields. Requirement columns remain visible, maintaining context. Users toggle collapse via the group header arrow or via PowerSheet “View” menu presets.

​

Workflow Integration

​

Verification Sequence

1. Subsystem Requirements Authored — In Requirements space, system requirements are decomposed into subsystem requirements (in SubsystemRequirementSpecification documents)
2. Subsystem Verification Sheet Opened — V&V engineer opens SubsystemVerificationSpecification LiveDoc with embedded PowerSheet
3. Test Cases Created or Linked — Engineer uses entity factory or manual linking to associate test cases with requirements
4. Test Execution — Test cases are executed; results captured in test result documents (in Testing space)
5. Status Updated — Status field in test group is updated to “Passed”, “Failed”, or “Blocked”
6. Coverage Reported — Coverage report queries this sheet to compute ”% of SubsystemRequirements with ≥1 linked test case”

​

Document Scoping

When the PowerSheet is embedded in a Polarion LiveDoc (via the {powersheet} widget macro), it automatically filters to the document’s scope:

• SubsystemRequirement entities = only requirements in this document
• VerificationTestCase entities = only test cases linked to those requirements

This enables each subsystem team to have a focused verification dashboard for their subsystem only.

​

Linking to Related Documentation

For detailed guidance on using this sheet in verification workflows, see:

• Use Verification PowerSheet — Step-by-step workflow instructions
• Verification vs Validation — Understanding the verification distinction
• Link Tests to Requirements — How to establish and maintain test-to-requirement links
• Check Verification Coverage — Computing and reporting coverage gaps
• RTM Domain Model — Full documentation of testCases link role and RTM relationships
• Verification Test Case — Work item type reference
• Subsystem Requirement — Work item type reference

​

Configuration File Location

Path: .polarion/nextedy/sheet-configurations/subsystem-verification.yaml Format: YAML — PowerSheet configuration schema (see PowerSheet Configurations for schema reference) Version: Aligned with TestAuto2 solution version; updated when RTM model or verification process changes Edit Restrictions: Configuration Manager role; modifications require understanding of RTM relationships and Polarion field mappings