Annex C: Requirements [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Annex C: Requirements ======

[[dido:03-dido-te:99-annexes:start|Go to Annexes]]

Annex C contains the canonical requirements register for this specification.

The requirements are organized according to defined requirement categories. Each requirement has a stable identifier and resides on a separate requirement page so that architecture pages, ConOps activities, realization artifacts, tests, [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], and other records can reference the requirement through a stable URI.

A requirement page may be a leaf page containing an independently verifiable normative obligation or a non-leaf page organizing subordinate requirements.

The requirements register distinguishes between:

  * The governance status of a requirement
  * The delivery phase associated with a requirement
  * The source and derivation of a requirement
  * The architecture and operational concepts associated with a requirement
  * The ConOps activities associated with a requirement
  * The verification activities used to determine whether a realization satisfies a requirement

Requirements in this register define required capabilities and constraints without prescribing a particular product, implementation, or realization technology.

Traceability maintains relationships between requirements and specific Reference Architectures, products, architectural capabilities, ConOps activities, or implementations.

===== Requirement Categories =====

The requirements register uses the following requirement categories:

  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:start|C.1 Mission Objectives]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:02-operational-requirements:start|C.2 Operational Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:start|C.3 Functional Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-01-test-environment-requirements:start|C.3.1 Test Environment Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-02-node-requirements:start|C.3.2 Node Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:start|C.3.3 Twin Node Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-04-virtual-network-and-communication-requirements:start|C.3.4 Virtual Network and Communication Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-05-state-and-time-control-requirements:start|C.3.5 State and Time Control Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-06-test-definition-requirements:start|C.3.6 Test Definition Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-07-test-execution-requirements:start|C.3.7 Test Execution Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-08-record-and-playback-requirements:start|C.3.8 Record and Playback Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-09-baseline-and-comparison-requirements:start|C.3.9 Baseline and Comparison Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-10-validation-requirements:start|C.3.10 Validation Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-11-monitoring-and-evidence-requirements:start|C.3.11 Monitoring and Evidence Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-12-catalog-and-reuse-requirements:start|C.3.12 Catalog and Reuse Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:04-security-requirements:start|C.4 Security Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:05-logging-and-auditing-requirements:start|C.5 Logging and Auditing Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:06-reliability-requirements:start|C.6 Reliability Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:07-performance-requirements:start|C.7 Performance Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:08-maintainability-requirements:start|C.8 Maintainability Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:09-data-management-requirements:start|C.9 Data Management Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:10-interoperability-requirements:start|C.10 Interoperability Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:11-conformance-requirements:start|C.11 Conformance Requirements]]

===== Requirement Identifiers =====

Each requirement has a stable requirement identifier.

The requirement identifier identifies the requirement independently of its location within the requirements hierarchy. Moving a requirement to another category or namespace does not, by itself, change the requirement identifier.

For example, a Node requirement identified as ''NOD-013'' remains ''NOD-013'' if the Node Requirements namespace is relocated within Annex C.

Requirement identifiers SHALL NOT be reused for a different requirement after assignment.

A requirement that is withdrawn, deprecated, or superseded retains its identifier and governance history.

===== Requirement Prefixes =====

Requirement identifiers use a controlled prefix that identifies the requirement family.

The prefix identifies the subject area of the requirement and remains stable even if the requirement is moved within the Annex C hierarchy.

^ Prefix ^ Requirement Category ^
| MO | Mission Objective |
| OPR | Operational Requirement |
| ENV | Test Environment Requirement |
| NOD | Node Requirement |
| TWIN | Twin Node Requirement |
| NET | Virtual Network and Communication Requirement |
| STC | State and Time Control Requirement |
| TDF | Test Definition Requirement |
| TEX | Test Execution Requirement |
| RPB | Record and Playback Requirement |
| BLC | Baseline and Comparison Requirement |
| VAL | Validation Requirement |
| EVD | Monitoring and Evidence Requirement |
| CAT | Catalog and Reuse Requirement |
| SEC | Security Requirement |
| AUD | Logging and Auditing Requirement |
| REL | Reliability Requirement |
| PER | Performance Requirement |
| MNT | Maintainability Requirement |
| DAT | Data Management Requirement |
| INT | Interoperability Requirement |
| CON | Conformance Requirement |

Requirement identifiers use the form:

<code>
PREFIX-NNN
</code>

where:

  * ''PREFIX'' identifies the requirement family
  * ''NNN'' is a sequential identifier within that family

For example:

<code>
ENV-001
NOD-013
TEX-004
SEC-002
</code>

A requirement prefix SHALL NOT change solely because the requirement page or requirement category is reorganized within Annex C.

A retired or superseded requirement identifier SHALL NOT be reassigned to a different requirement.

===== Requirement Decomposition =====

A source requirement may contain multiple independently verifiable obligations.

A source requirement containing multiple independently verifiable obligations may be decomposed into multiple requirements when decomposition improves atomicity, clarity, traceability, or verification.

Derived requirements preserve traceability to the source requirement, architectural concept, model element, or other authoritative basis from which they were derived.

Decomposition SHALL NOT change the approved intent of the source obligation.

A derived requirement does not acquire independent authority merely because it has been decomposed from another statement. Its authority remains traceable to its source and applicable governance process.

===== Source and Derivation Traceability =====

Each requirement identifies its authoritative source or derivation basis where applicable.

A requirement may originate from:

  * A source requirement
  * A normative specification or other controlled document
  * A policy or governed constraint
  * A conceptual or logical model
  * An architectural decomposition
  * An approved governance determination
  * Another requirement

Source material may be normalized when necessary to produce an atomic, clear, verifiable requirement.

Normalization may correct:

  * Terminology
  * Grammar
  * Active or passive voice
  * Normative modality
  * Ambiguous subjects
  * Compound obligations
  * Undefined references
  * Implementation-specific wording that is inappropriate at the architectural level

Normalization SHALL preserve the source's approved intent.

The applicable governance process SHALL approve a material change in requirement intent.

Editorial normalization SHALL NOT introduce a material change in intent.

===== Requirement Page Structure =====

Each requirement page uses the following sections where applicable:

  * Statement
  * Source
  * Rationale
  * Applies To
  * Verification
  * Traceability
  * ConOps Relationship
  * Delivery Phase
  * Requirement Status

A leaf requirement page contains an independently verifiable normative obligation and therefore includes a ''Statement'' section and a ''Verification'' section.

A non-leaf requirement page organizes subordinate requirements and does not establish a separate conformance obligation unless explicitly stated otherwise. A non-leaf requirement page therefore normally omits ''Statement'' and ''Verification'' sections.

Additional sections SHALL NOT be added to individual requirement pages merely to duplicate information maintained through backlinks, traceability records, or another authoritative register.

===== Normative Language =====

Requirement statements use the following normative terms:

  * **SHALL** identifies a mandatory requirement
  * **SHALL NOT** identifies a mandatory prohibition
  * **MAY** identifies a permitted capability or action
  * **SHOULD** identifies a recommendation when advisory language remains appropriate

Normative modal verbs are written in uppercase.

A requirement page may editorially correct source wording for terminology, atomicity, clarity, active voice, normative style, or verification without changing the approved intent of the requirement.

===== Requirement Quality =====

Requirements are reviewed for specification quality before approval.

Requirement review examines characteristics including:

  * Atomicity
  * Clear identification of the responsible subject
  * Defined terminology
  * Appropriate normative modality
  * Active voice
  * Unambiguous scope
  * Verifiability
  * Traceability
  * Consistency with related requirements
  * Absence of unnecessary implementation constraints
  * Absence of unresolved conflicts or ambiguous precedence

Specification Discipline and Authoring (SDA) identifies candidate weaknesses in requirement wording, structure, terminology, traceability, or semantics.

The Common Specification Weakness Enumeration (CWE) evaluates candidate findings, confirms applicable defects, and records their classification, severity, governing rule, and applicable defect pattern.

Automated or AI-assisted analysis may identify, compare, trace, or propose corrections to candidate issues.

Automated or AI-assisted analysis SHALL NOT resolve conflicts, ambiguities, or precedence among governed requirements, policies, specifications, profiles, or other authoritative constraints.

A conflict, ambiguity, or unresolved precedence among governed requirements, policies, specifications, profiles, or other authoritative constraints SHALL be referred to the appropriate governance authority through the applicable Community of Interest (CoI) structure.

===== Requirement Status =====

Requirement Status identifies the requirement's governance state.

Possible states include:

  * Draft
  * Proposed
  * Approved
  * Deprecated
  * Superseded
  * Withdrawn

Requirement Status describes the requirement's authority and lifecycle state. It does not describe whether a particular product or implementation satisfies the requirement.

===== Realization and Implementation Status =====

Requirements in this annex are product-neutral and may be realized by one or more architectural capabilities, Reference Architectures, products, services, or implementations.

The canonical requirement does not prescribe a specific realization unless such a constraint forms part of the approved requirement.

Traceability records maintain relationships between canonical requirements and their realizations.

The applicable realization maintains Implementation Status. Implementation Status is not a property of the canonical requirement.

A realization may identify its relationship to a requirement using implementation states such as:

  * Implemented
  * Partially Implemented
  * Demonstrated
  * Planned
  * Unsupported
  * Not Assessed

Requirement Status and realization-specific Implementation Status remain separate.

===== Contents =====

  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:start|C.1 Mission Objectives]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:02-operational-requirements:start|C.2 Operational Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:start|C.3 Functional Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-01-test-environment-requirements:start|C.3.1 Test Environment Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-02-node-requirements:start|C.3.2 Node Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:start|C.3.3 Twin Node Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-04-virtual-network-and-communication-requirements:start|C.3.4 Virtual Network and Communication Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-05-state-and-time-control-requirements:start|C.3.5 State and Time Control Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-06-test-definition-requirements:start|C.3.6 Test Definition Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-07-test-execution-requirements:start|C.3.7 Test Execution Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-08-record-and-playback-requirements:start|C.3.8 Record and Playback Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-09-baseline-and-comparison-requirements:start|C.3.9 Baseline and Comparison Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-10-validation-requirements:start|C.3.10 Validation Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-11-monitoring-and-evidence-requirements:start|C.3.11 Monitoring and Evidence Requirements]]
    * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-12-catalog-and-reuse-requirements:start|C.3.12 Catalog and Reuse Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:04-security-requirements:start|C.4 Security Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:05-logging-and-auditing-requirements:start|C.5 Logging and Auditing Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:06-reliability-requirements:start|C.6 Reliability Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:07-performance-requirements:start|C.7 Performance Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:08-maintainability-requirements:start|C.8 Maintainability Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:09-data-management-requirements:start|C.9 Data Management Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:10-interoperability-requirements:start|C.10 Interoperability Requirements]]
  * [[dido:03-dido-te:99-annexes:annex-c-requirements:11-conformance-requirements:start|C.11 Conformance Requirements]]

{{indexmenu>dido:03-dido-te:99-annexes:annex-c-requirements#1|js navbar nocookie maxjs#4 id#dido_te_annex_c_requirements_nav}}

----

===== Notes for Editors =====

<todo>Remove the explicit creation links under Contents after all planned requirement-category pages have been created and the indexmenu discovers them.</todo>

Preserve stable requirement identifiers when moving or reorganizing requirement pages.

Do not allocate canonical requirements directly to Crucible, DevSecOps, or another realization within the requirement Statement. Maintain realization relationships through Traceability.

----

<WRAP centeralign>
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
</WRAP>