[DTE5] DIDO-TE Requirements Register

Go to Annex B: References

DIDO Solutions, Inc. DIDO-TE Requirements Register. Draft requirements register.

The DIDO-TE Requirements Register records source requirements, acceptance criteria, explanatory information, and supporting material for the Distributed Immutable Data Object Test Environment (DIDO-TE).

The register contains source requirements identified as REQ-0001 through REQ-0091.

The register serves as source material for the canonical DIDO-TE requirements maintained in Annex C: Requirements.

The source requirement identifiers preserve traceability to the register. They do not constitute canonical DIDO-TE requirement identifiers.

The register addresses DIDO-TE subject areas associated with:

• Test Environment configuration
• Nodes and Deployment Targets
• Twin Nodes
• Virtual networks and communication
• State and time control
• Test definition
• Test execution
• Record and playback
• Baselines and comparison
• Validation
• Monitoring and Evidence
• Catalogues and reuse
• Governance and Communities of Interest
• DIDO-TE operations
• Security
• Logging and auditing
• Reliability
• Performance
• Maintainability
• Data management
• Interoperability

The register may contain compound statements, acceptance criteria, explanatory material, implementation suggestions, and other supporting information. Annex C analyses and dispositions this material before establishing canonical requirements.

This reference provides source-requirement provenance for the DIDO-TE requirements corpus.

Annex C uses `[DTE5]` to:

• Identify source requirements
• Preserve source identifiers and titles
• Preserve original source wording
• Identify independently interpretable obligations
• Identify independently verifiable obligations
• Record requirement decomposition
• Record terminology normalisation
• Establish traceability between source and canonical requirements
• Distinguish normative obligations from acceptance criteria and supporting material

A source requirement does not become a canonical DIDO-TE requirement until the requirements process analyses, normalises, traces, reviews, and approves it.

DIDO-TE pages cite this reference using:

[DTE5]

A citation identifies the applicable source requirement identifier and title.

For example:

[[dido:03-dido-te:99-annexes:annex-b-references:dte-005|[DTE5]]], ''REQ-0010 — Domain-scoped environments''.

When a canonical requirement derives from one obligation within a compound source requirement, the citation identifies the applicable source obligation.

For example:

[[dido:03-dido-te:99-annexes:annex-b-references:dte-005|[DTE5]]], ''REQ-0010 — Domain-scoped environments'', source obligation concerning creation of a Domain-owned Test Environment.

When an acceptance criterion supports a requirement or its verification criteria, the citation identifies the applicable acceptance criterion.

Annex C preserves the original identifier, title, and wording of each source requirement cited from `[DTE5]`.

The requirements process:

1. Applies Specification Discipline and Authoring (SDA) analysis to identify candidate weaknesses
2. Applies Common Specification Weakness Enumeration (CWE) evaluation to confirm and classify defects
3. Separates compound source statements into independently interpretable and independently verifiable obligations
4. Normalises spelling, capitalisation, spacing, and terminology without changing the source meaning
5. Distinguishes normative obligations from acceptance criteria, rationale, explanation, examples, and implementation guidance
6. Records the lineage between each canonical requirement and its source obligation
7. Assigns a canonical DIDO-TE identifier following review and approval

The canonical requirement retains traceability to its source requirement even when analysis produces several independently verifiable leaf requirements.

The identifiers REQ-0001 through REQ-0091 identify requirements within `[DTE5]`.

These identifiers remain source-reference identifiers.

Annex C assigns canonical identifiers according to the applicable requirement class, including:

• MO for Mission Objectives
• OR for Operational Requirements
• FR for Functional Requirements
• SEC for Security Requirements
• LOG for Logging and Auditing Requirements
• REL for Reliability Requirements
• PER for Performance Requirements
• MNT for Maintainability Requirements
• DAT for Data Management Requirements
• INT for Interoperability Requirements

Annex C does not replace the source identifier. Its traceability record preserves both identifiers.

[DTE5] provides source requirements associated with concepts, proposals, and model content recorded in other DIDO-TE references.

See:

• [DTE1] U.S. Patent Application US20220237111A1
• [DTE2] Non-Traditional BAA Submission
• [DTE3] Draft BAA White Paper
• [DTE4] DIDO Reference Data Model

[DTE1] records patented subject matter. [DTE2] and [DTE3] describe proposed applications of DIDO-TE. [DTE4] supplies a historical Conceptual Model. [DTE5] records the source requirements considered during development of the canonical DIDO-TE requirements corpus.

Cite the reference that directly supports the applicable statement or requirement derivation.

[DTE5] records draft source material.

The register does not, by itself, establish the current normative DIDO-TE requirements corpus. Annex C: Requirements contains the canonical requirements following analysis, normalisation, traceability, review, and approval.

The source identifiers, original wording, version, date, and provenance remain part of the source record.

Preserve `[DTE5]` and this page namespace as stable citation identifiers.

Preserve the authoritative source file as the canonical source artefact.

Record the authoritative filename, version, date, file format, and publication status when that metadata becomes available.

Preserve the identifiers REQ-0001 through REQ-0091 in derivation and traceability records.

Do not assign a source REQ-#### identifier to a canonical DIDO-TE requirement.

Identify the precise source requirement, source obligation, and applicable acceptance criterion when deriving a canonical requirement from `[DTE5]`.

Apply SDA analysis before CWE evaluation.

Do not derive requirements solely from a source title, category heading, summary, or inferred architectural intent.

Preserve the original source statement in the provenance record. Record the normalised requirement separately.

Do not classify a change to scope, actor, behaviour, value, constraint, cardinality, relationship, or meaning as an editorial correction.

Do not treat acceptance criteria, explanatory material, examples, implementation suggestions, or supporting information as independent normative requirements without analysis, traceability, review, and approval.

Separate compound source requirements into independently interpretable and independently verifiable obligations.

Record the revision, provenance, and supersession relationship before replacing `[DTE5]` with another requirements register.

Preserve `[DTE5]` when existing requirements, Evidence, reports, or externally published documents cite it.