Skip to main content

​
The Document-Type Relationship

Think of document types as blueprints and modules as buildings. A document type defines what kind of content a module can hold, what work item types it accepts, and how that module participates in traceability queries and reporting. The module is the actual container where engineers create and edit work items. diagram

​
Why This Matters

This two-layer architecture enables:
  • Automated filtering: PowerSheet RTM queries can automatically filter documents by type (e.g., “show only system requirements from systemRequirementsSpecification documents”)
  • Workflow enforcement: All modules of a given type follow the same approval workflow (Draft → In Review → Approved → Published)
  • Tooling integration: Risksheet knows which modules to render as interactive risk analysis tables based on document type
  • Reporting consistency: Coverage reports can calculate metrics across all modules of a specific type

​
TestAuto2 Document Type Taxonomy

TestAuto2 defines 10 document types organized around two core workflows: the V-Model requirements cascade and risk analysis.

​
V-Model Document Types (Requirements Hierarchy)

These document types implement the ISO 26262 V-Model decomposition from customer needs down to design specifications:
Document TypePurposeWork Item TypesExample Module
customerSpecificationTop-level customer and regulatory requirementsCustomer Requirement, User NeedCUSTOMER-REQS
systemRequirementsSpecificationSystem-level functional requirements derived from customer needsSystem RequirementSystem Requirements Specification
subsystemRequirementsSpecificationSubsystem requirements refining system requirements for component teamsSystem Requirement (scoped to subsystem)ECU & Processing Subsystem Requirements
designRequirementsSpecificationImplementation-level design specificationsDesign RequirementCamera Module - Design Requirements
testsSpecificationVerification and validation test casesTest Case, Verification Test Case, Validation Test CaseSystem Verification Tests
Notice that both systemRequirementsSpecification and subsystemRequirementsSpecification use the same work item type (sysReq) but different document types. This allows PowerSheet queries to distinguish “system-level” from “subsystem-level” requirements based on which document they live in, enabling scoped traceability views.

​
Risk Analysis Document Types

These document types support FMEA, HARA, and control plan workflows using Nextedy Risksheet:
Document TypePurposeWork Item TypesRisksheet Config
riskSpecificationRisk assessment modules (HAZOP, HAZID, HARA, FMEA, PFMEA)Hazard, Failure Mode, Process Failure Mode, Risk Control, Control Plan Itemrisksheet.json attachment
characteristicsSpecificationProduct characteristics catalog with target values and tolerancesCharacteristicCan use PowerSheet or Risksheet
functionsSpecificationSystem function catalog describing behavioral capabilitiesFunctionCan use PowerSheet or Risksheet
The riskSpecification type is the most powerful and flexible. It enables engineers to create:
  • HAZID/HARA modules: Analyzing hazards, operational situations, and ASIL classifications
  • System/Subsystem/Component FMEA modules: Three-level failure mode analysis hierarchy
  • Process FMEA modules: Manufacturing process failure analysis
  • Control Plan modules: Quality control planning for critical characteristics
Each module of type riskSpecification has an attached risksheet.json configuration file that defines:
  • Column structure and grouping
  • Formula logic (e.g., ASIL calculation, RPN computation, Action Priority)
  • Cell decorators (traffic lights, conditional formatting)
  • Workflow views (progressive disclosure: initial assessment → mitigation → post-mitigation)

​
Special-Purpose Document Types

Document TypePurposeTool Integration
powersheetDynamic traceability matrix views driven by RTM model expansion queriesNextedy PowerSheet YAML config
genericCatch-all for unstructured content (narrative documents, meeting notes)Standard LiveDoc editor
Unlike other document types, powersheet modules don’t contain work items. Instead, they query and display work items from other modules based on RTM model expansion paths defined in their YAML configuration. Think of them as “live views” rather than “storage containers.”

​
How Document Types Control Workflow

Every document in TestAuto2 follows a formal approval workflow defined by its document type. The riskSpecification workflow is representative: diagram State meanings:
  • Draft: Editable, no signature requirements. Suitable for iterative FMEA/HARA development.
  • In Review: Locked for editing, awaiting signature from project_approver role holders.
  • Approved: Formal sign-off complete. Suitable for publication but still allows rework if needed.
  • Published: Final release. Typically read-only in practice, used as stable baseline for compliance audits.
The rework action provides workflow flexibility while maintaining approval integrity: all existing signatures are marked obsolete, and the signature verdict is reset. Users must repeat the review/approval cycle after corrections.

​
How Document Types Enable Traceability Filtering

The RTM domain model uses document type constraints to ensure traceability queries return only relevant results. Consider this entity definition from rtm.yaml: 
- name: SystemRequirement
  polarionType: sysReq
  fields:
    - description
    - classification
  createConstraint:
    documentType: systemRequirementsSpecification  # ← Type filter
  pickConstraint:
    documentType: systemRequirementsSpecification  # ← Type filter
This configuration means:
  1. Auto-creation: When PowerSheet creates a new System Requirement work item inline, it must place it in a document of type systemRequirementsSpecification.
  2. Picker filtering: When engineers link from a System Requirement to another entity, the picker dropdown only shows documents of type systemRequirementsSpecification.
This prevents common mistakes like accidentally linking a subsystem requirement to a system-level test case from a different module.

​
Common Misconceptions

​
”I can put any work item type in any document”

Not quite. While Polarion technically allows this, TestAuto2’s RTM model and Risksheet configurations assume that work item types match their document types. For example:
  • System Requirements should live in systemRequirementsSpecification documents
  • Failure Modes should live in riskSpecification documents
  • Test Cases should live in testsSpecification documents
Violating these conventions breaks PowerSheet expansion queries, Risksheet column formulas, and coverage reports.

​
”Document type and work item type are the same thing”

No. Document type defines the container (module/LiveDoc). Work item type defines the contents (individual requirements, hazards, failure modes). Multiple document types can share the same work item type (e.g., both systemRequirementsSpecification and subsystemRequirementsSpecification use sysReq).

​
”Generic documents are useless”

Not true. While generic documents don’t participate in automated traceability queries or Risksheet workflows, they’re perfect for:
  • Meeting notes and decision records
  • Narrative documentation (process guides, templates)
  • Unstructured analysis content that doesn’t fit the V-Model
Just don’t expect coverage reports to track them.

​
”I can change document type after creation”

Technically yes, but dangerous. Changing document type after a module contains work items can break:
  • PowerSheet expansion queries (documents disappear from views)
  • Risksheet configurations (columns fail to resolve custom fields)
  • Coverage reports (metrics suddenly exclude the module)
Always choose the correct document type before creating work items.

​
How to Choose the Right Document Type

Use this decision tree when creating a new module:
  • Does the module contain risk analysis (FMEA/HARA/HAZOP)?
    • YES: Use riskSpecification (attach risksheet.json configuration)
    • NO: Continue below
  • Is it a traceability matrix view?
    • YES: Use powersheet (attach PowerSheet YAML configuration)
    • NO: Continue below
  • Does it contain requirements?
    • YES: Choose by level:
      • Customer needs: customerSpecification
      • System functional: systemRequirementsSpecification
      • Subsystem scoped: subsystemRequirementsSpecification
      • Design/implementation: designRequirementsSpecification
    • NO: Continue below
  • Does it contain test cases?
    • YES: Use testsSpecification
    • NO: Continue below
  • Is it characteristics or functions?
    • Characteristics: characteristicsSpecification
    • Functions: functionsSpecification
    • None of the above: generic

​
Practical Implications

Understanding document types helps you:
  1. Navigate confidently: When you see a module in the document tree, its document type tells you what kind of content it holds and what workflow it follows.
  2. Troubleshoot traceability: If a module doesn’t appear in a PowerSheet view, check whether its document type matches the documentType constraint in the RTM model entity definition.
  3. Configure Risksheet correctly: Each riskSpecification module needs a risksheet.json attachment tuned to its specific risk analysis workflow (HARA vs SFMEA vs DFMEA vs PFMEA).
  4. Plan module creation: Before creating a module, decide its document type based on the work item types it will contain and how it participates in traceability.

​
How-To Guides