Reference

ReqIF Types and Schema

Version: N/A
Status: N/A
Lineage: N/A

Overview

This page documents the ReqIF types used in M45.

They provide a normalized in-memory representation of a ReqIF document:

  • Close to the OMG ReqIF standard model
  • Focused on data M45 actually needs for analysis, intent inference, and safety workflows
  • Independent of any particular ReqIF exporter

At the top level, a parsed ReqIF file is represented as a ReqIFData object.

Example: GNSS spoofing detection ReqIF → ReqIFData

Raw ReqIF (excerpt)

This example includes a header, datatype definitions (string + enumerations), a requirement SpecObject type with several attributes, a specification tree, and explicit traceability links:

<REQ-IF-HEADER IDENTIFIER="HDR_GNSS_SPOOF_001">
  <CREATION-TIME>2025-12-10T00:00:00Z</CREATION-TIME>
  <REQ-IF-TOOL-ID>ReqIF-Generator</REQ-IF-TOOL-ID>
  <SOURCE-TOOL-ID>Authoring-Assistant</SOURCE-TOOL-ID>
  <TITLE>GNSS Spoofing Detection Device Requirements</TITLE>
</REQ-IF-HEADER>

<DATATYPE-DEFINITION-STRING IDENTIFIER="DT_STRING" LONG-NAME="String" MAX-LENGTH="8000"/>

<DATATYPE-DEFINITION-ENUMERATION IDENTIFIER="DT_STATUS" LONG-NAME="Requirement Status">
  <SPECIFIED-VALUES>
    <ENUM-VALUE IDENTIFIER="STATUS_PROPOSED" LONG-NAME="Proposed"/>
    <!-- ... -->
  </SPECIFIED-VALUES>
</DATATYPE-DEFINITION-ENUMERATION>

<SPEC-OBJECT-TYPE IDENTIFIER="REQ_TYPE" LONG-NAME="Requirement Type">
  <SPEC-ATTRIBUTES>
    <ATTRIBUTE-DEFINITION-STRING IDENTIFIER="REQ_TEXT" LONG-NAME="Requirement Text" TYPE="DT_STRING"/>
    <ATTRIBUTE-DEFINITION-ENUMERATION IDENTIFIER="STATUS" LONG-NAME="Status" TYPE="DT_STATUS"/>
    <!-- ... -->
  </SPEC-ATTRIBUTES>
</SPEC-OBJECT-TYPE>

<SPEC-OBJECT IDENTIFIER="SYS-001" LONG-NAME="System: Alert on suspected GNSS spoofing">
  <TYPE><SPEC-OBJECT-TYPE-REF>REQ_TYPE</SPEC-OBJECT-TYPE-REF></TYPE>
  <VALUES>
    <ATTRIBUTE-VALUE-STRING THE-VALUE="The device shall generate a flight-crew alert when it detects suspected GNSS spoofing.">
      <DEFINITION><ATTRIBUTE-DEFINITION-STRING-REF>REQ_TEXT</ATTRIBUTE-DEFINITION-STRING-REF></DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-ENUMERATION>
      <DEFINITION><ATTRIBUTE-DEFINITION-ENUMERATION-REF>STATUS</ATTRIBUTE-DEFINITION-ENUMERATION-REF></DEFINITION>
      <VALUES><ENUM-VALUE-REF>STATUS_PROPOSED</ENUM-VALUE-REF></VALUES>
    </ATTRIBUTE-VALUE-ENUMERATION>
  </VALUES>
</SPEC-OBJECT>

<SPECIFICATION IDENTIFIER="GPS_SPOOF_SPEC" LONG-NAME="GNSS Spoofing Detection Device Requirements">
  <!-- In most ReqIF exports, the specification tree references SpecObjects via SPEC-HIERARCHY nodes -->
  <CHILDREN>
    <SPEC-HIERARCHY IDENTIFIER="H_SYS_001" LONG-NAME="System Requirement">
      <OBJECT><SPEC-OBJECT-REF>SYS-001</SPEC-OBJECT-REF></OBJECT>
      <!-- ... -->
    </SPEC-HIERARCHY>
  </CHILDREN>
</SPECIFICATION>

<SPEC-RELATION IDENTIFIER="TR_SYS_HLR_001" LONG-NAME="SYS-001 to HLR-001">
  <SOURCE><SPEC-OBJECT-REF>SYS-001</SPEC-OBJECT-REF></SOURCE>
  <TARGET><SPEC-OBJECT-REF>HLR-001</SPEC-OBJECT-REF></TARGET>
</SPEC-RELATION>

Normalized ReqIFData (illustrative slice)

M45 normalizes the XML into the types on this page (IDs preserved, data extracted into values[] arrays, and hierarchy represented explicitly):

{
  "header": {
    "identifier": "HDR_GNSS_SPOOF_001",
    "creationTime": "2025-12-10T00:00:00Z",
    "reqIfToolId": "ReqIF-Generator",
    "sourceToolId": "Authoring-Assistant",
    "reqIfVersion": "1.0",
    "title": "GNSS Spoofing Detection Device Requirements",
    "comment": "ReqIF generated from system description: GPS spoofing detection device",
    "version": null
  },
  "dataTypes": [
    {
      "identifier": "DT_STRING",
      "longName": "String",
      "type": "string",
      "maxLength": 8000,
      "accuracy": null,
      "max": null,
      "min": null,
      "specifiedValues": null
    },
    {
      "identifier": "DT_STATUS",
      "longName": "Requirement Status",
      "type": "enumeration",
      "specifiedValues": [
        { "identifier": "STATUS_PROPOSED", "longName": "Proposed", "properties": null }
      ]
    }
  ],
  "specTypes": [
    {
      "identifier": "REQ_TYPE",
      "longName": "Requirement Type",
      "specAttributes": [
        { "identifier": "REQ_TEXT", "longName": "Requirement Text", "type": "DT_STRING" },
        { "identifier": "STATUS", "longName": "Status", "type": "DT_STATUS" }
      ]
    }
  ],
  "specObjects": [
    {
      "identifier": "SYS-001",
      "longName": "System: Alert on suspected GNSS spoofing",
      "type": "REQ_TYPE",
      "values": [
        { "definition": "REQ_TEXT", "value": "The device shall generate a flight-crew alert when it detects suspected GNSS spoofing." },
        { "definition": "STATUS", "value": "STATUS_PROPOSED" }
      ]
    }
  ],
  "specRelations": [
    {
      "identifier": "TR_SYS_HLR_001",
      "longName": "SYS-001 to HLR-001",
      "type": "TRACE_TYPE",
      "source": "SYS-001",
      "target": "HLR-001",
      "values": [
        { "definition": "TRACE_KIND", "value": "decomposes_to" }
      ]
    }
  ],
  "specifications": [
    {
      "identifier": "GPS_SPOOF_SPEC",
      "longName": "GNSS Spoofing Detection Device Requirements",
      "type": "SPEC_TYPE",
      "children": [],
      "specObjects": [],
      "specRelations": []
    }
  ],
  "standard": null
}

Top-level ReqIFData object

{
  "header": "ReqIFHeader",
  "dataTypes": ["DataType"],
  "specTypes": ["SpecType"],
  "specifications": ["Specification"],
  "specObjects": ["SpecObject"],
  "specRelations": ["SpecRelation"],
  "standard": "ReqIFStandard | null"
}

Fields

  • header (ReqIFHeader): Metadata about the ReqIF document itself.
  • dataTypes (DataType[]): All data type definitions used in attributes.
  • specTypes (SpecType[]): Schemas for requirements and relations.
  • specifications (Specification[]): Hierarchical containers for requirements.
  • specObjects (SpecObject[]): Flat list of all requirement objects.
  • specRelations (SpecRelation[]): Flat list of all traceability links.
  • standard (ReqIFStandard?): Detected assurance or domain standard, if any.

This object is the canonical input to ReqIF-based workflows (parsing, inventory, intent inference).

ReqIFHeader

{
  "comment": "string",
  "creationTime": "ISO‑8601 string",
  "identifier": "string",
  "reqIfToolId": "string",
  "reqIfVersion": "string",
  "sourceToolId": "string",
  "title": "string",
  "version": "string | null"
}
  • comment: Optional free‑text description of the document.
  • creationTime: Creation timestamp in ISO‑8601 format.
  • identifier: Tool‑assigned unique identifier for this ReqIF payload.
  • reqIfToolId: Identifier for the tool that generated the ReqIF file.
  • reqIfVersion: Version of the ReqIF standard (e.g. "1.0").
  • sourceToolId: Identifier for the originating requirements tool, if different from reqIfToolId.
  • title: Human‑readable title of the requirements document.
  • version: Optional version string for the specification (often carried in specification attributes).

The header is informational and used for logging, provenance, and validation reporting.

AttributeValue

{
  "definition": "string",
  "value": "string | number"
}
  • definition: Identifier of the AttributeDefinition that defines this attribute.
  • value: Concrete attribute value (string or number) for a requirement or relation.

Every SpecObject and SpecRelation carries its data via an array of AttributeValue instances.

SpecObject (requirements)

{
  "identifier": "string",
  "longName": "string",
  "type": "string",
  "values": ["AttributeValue"]
}
  • identifier: Unique ID for this requirement object inside the ReqIF document.
  • longName: Human‑readable label (often the requirement title or short ID).
  • type: Identifier of the SpecType that defines this requirement’s schema.
  • values: Attribute values for this requirement (e.g. text, status, safety level, domain‑specific tags).

SpecObject is the core requirement unit used for:

  • Detecting domain‑specific attributes (e.g. objectives, safety levels, ML fields)
  • Downstream traceability and coverage analysis

SpecRelation (traceability links)

{
  "identifier": "string",
  "longName": "string",
  "type": "string",
  "source": "string",
  "target": "string",
  "values": ["AttributeValue | null"]
}
  • identifier: Unique ID for the relation.
  • longName: Human‑readable description of the relation, if provided.
  • type: Identifier of the relation’s SpecType.
  • source: identifier of the source SpecObject.
  • target: identifier of the target SpecObject.
  • values: Optional attributes on the relation (e.g. rationale, status, labels).

These relations are used to construct:

  • Traceability‑aware intent and coverage checks

DataType

{
  "identifier": "string",
  "longName": "string",
  "type": "string | integer | real | enumeration",
  "maxLength": "number | null",
  "accuracy": "number | null",
  "max": "number | null",
  "min": "number | null",
  "specifiedValues": ["EnumValue | null"]
}
  • identifier: Unique ID for the data type.
  • longName: Human‑readable name for the type.
  • type: Base kind, one of:
    • string
    • integer
    • real
    • enumeration
  • maxLength: Maximum allowed length for string values.
  • accuracy: Decimal precision for real values.
  • max / min: Numeric bounds for integer or real types.
  • specifiedValues: Enumeration members if type === "enumeration".

DataType is used to interpret AttributeValue.value payloads and to normalize status, objective, and safety‑related fields.

EnumValue (enumeration member)

{
  "identifier": "string",
  "longName": "string",
  "properties": "object | null"
}
  • identifier: Unique ID for this enum entry.
  • longName: Display label (e.g. "Draft", "Approved", "A").
  • properties: Optional additional metadata from the exporter.

Enum values are typically used for:

  • Requirement status
  • Objective or classification values
  • Safety relevance flags and categories

SpecType (schema for SpecObjects and relations)

{
  "identifier": "string",
  "longName": "string",
  "specAttributes": ["AttributeDefinition | MLAttributeDefinition"]
}
  • identifier: Unique ID for this specification type.
  • longName: Human‑readable name (e.g. "Software Requirement").
  • specAttributes: Attribute definitions allowed on objects of this type.

SpecType acts as the schema template for requirements and relations.

AttributeDefinition

{
  "identifier": "string",
  "longName": "string",
  "type": "string"
}
  • identifier: Unique ID for this attribute definition.
  • longName: Display name (e.g. "Requirement Text", "Objective").
  • type: Identifier of the DataType that constrains values for this attribute.

Attribute definitions form the vocabulary of a given exporter or project and drive:

  • Attribute normalization (e.g. mapping "Status" → status)
  • Detection of domain‑ or safety‑specific fields (including ML‑related attributes)

MLAttributeDefinition (ML‑aware extension)

{
  "identifier": "string",
  "longName": "string",
  "type": "string",
  "trainingDataRequirements": "string | null",
  "dataCoverage": "HIGH_COVERAGE | STANDARD_COVERAGE | MINIMAL_COVERAGE | null",
  "modelType": "TRAINING_DATA_MANAGEMENT | MODEL_VALIDATION | MODEL_EXPLAINABILITY | INFERENCE_ENGINE | MODEL_MONITORING | ML_COMPONENT | null",
  "standardSupplement": "string | null",
  "acceptanceCriteria": "string | null",
  "runtimeAssurance": "RUNTIME_MONITORING | STANDARD_RUNTIME | null"
}

This extends AttributeDefinition for ML‑aware requirements contexts.

Additional fields:

  • trainingDataRequirements: Text description of training data constraints.
  • dataCoverage: Required coverage level for ML training data.
  • modelType: Category of ML component impacted by this attribute.
  • standardSupplement: Optional identifier indicating which standard, supplement, or guidance context applies (if any).
  • acceptanceCriteria: ML‑specific acceptance criteria.
  • runtimeAssurance: How runtime assurance is handled (RUNTIME_MONITORING vs STANDARD_RUNTIME).

These extensions support ML‑aware analysis, compliance checks, and inventory across different standards.

Specification (hierarchical containers)

{
  "identifier": "string",
  "longName": "string",
  "type": "string",
  "children": ["Specification | null"],
  "specObjects": ["SpecObject | null"],
  "specRelations": ["SpecRelation | null"]
}
  • identifier: Unique ID for this specification node.
  • longName: Human‑readable name (e.g. "System Requirements", "Safety Requirements").
  • type: Specification type identifier (schema for this container).
  • children: Optional nested Specification nodes (for hierarchy).
  • specObjects: Optional requirements contained directly in this node.
  • specRelations: Optional relations contained directly in this node.

Specification models the tree structure seen in most requirements tools and is used to derive spec_path and hierarchy views.

ReqIFStandard (detected assurance standard)

{
  "id": "string",
  "label": "string",
  "objectiveDefinition": "string | null",
  "supplementDefinition": "string | null"
}
  • id: Normalized identifier without punctuation (e.g. "DO178C", "DO254", or other domain‑specific codes).
  • label: Display label with punctuation (e.g. "DO-178C", "DO-254", or another standard name).
  • objectiveDefinition: Attribute identifier for any objective / classification field associated with the standard, if detected.
  • supplementDefinition: Attribute identifier for any supplement / annex selection (e.g. ML supplement), if present.

This object captures which standard or framework the ReqIF appears to follow and how to locate key attributes (objectives, supplements) within the attribute vocabulary.

How these types are used

  • Parsing: The ReqIF parser produces a ReqIFData instance using these types.
  • Inventory and normalization:
    • Header and standard inform overall context.
    • SpecType, AttributeDefinition, and DataType drive attribute normalization and canonicalization.
    • SpecObject and SpecRelation are consumed directly from the in-memory ReqIFData object.
  • Intent inference: Higher‑level workflows consume ReqIFData to:
    • Extract candidate components, modes, signals, and safety themes
    • Build relation‑ and hierarchy‑aware summaries
    • Drive domain‑ and standard‑aware compliance checks and intent mapping (including ML where applicable).