Annex C: Requirements

Go to Annexes

Annex C contains the canonical requirements register for the Distributed Immutable Data Object Test Environment (DIDO-TE).

The requirements are organized by requirement class. Each normative requirement receives a stable identifier and resides on a separate Wiki page. Architecture pages, implementation artifacts, tests, Evidence, verification records, and other records can reference each requirement through its stable identifier and URI.

The draft Requirements Register provides source requirements and supporting information for this annex. The identifiers REQ-0001 through REQ-0091 identify requirements in the source register. Annex C preserves those identifiers for traceability but assigns new canonical identifiers to the DIDO-TE requirements.

DIDO-TE requirements conform to the:

Common Specification Weakness Enumeration (CWE)OMG Specification Discipline and Authoring (SDA)DIDO Solutions shared Terms and DefinitionsAnnex C distinguishes among:

The canonical DIDO-TE requirementThe source requirementThe requirement classThe governance status of the requirementThe delivery phase associated with the requirementThe implementation status of DIDO-TE relative to the requirementThe verification activities used to determine whether DIDO-TE satisfies the requirementThe Evidence required to support the verification resultThe architecture, ConOps, and operational concepts that support the requirement

Requirement Categories

Requirement Categories

Requirement Identifiers

DIDO-TE uses the following requirement-class identifiers:

Requirement Class	Prefix
Mission Objective	MO
Operational Requirement	OR
Functional Requirement	FR
Security Requirement	SEC
Logging and Auditing Requirement	LOG
Reliability Requirement	REL
Performance Requirement	PER
Maintainability Requirement	MNT
Data Management Requirement	DAT
Interoperability Requirement	INT
Future Capability Requirement	FUT
Key Value Proposition Requirement	KVP

Each requirement identifier consists of the requirement-class prefix followed by a three-digit number.

Examples include:

MO-001OR-001FR-001SEC-001PER-001A requirement identifier remains stable when the requirement moves to another section or undergoes an editorial revision that does not substantively change the requirement.

A retired, withdrawn, deprecated, or superseded identifier is not reassigned to another requirement.

Requirement Decomposition

Each normative requirement expresses one independently interpretable and independently verifiable obligation.

When a source requirement contains multiple normative obligations, Annex C preserves the source requirement on a non-leaf parent page and assigns a lowercase suffix to each derived requirement.

For example:

FR-040 identifies the source requirement represented by the parent pageFR-040a identifies the first derived requirementFR-040b identifies the second derived requirementThe non-leaf parent page retains a trailing :start in its namespace. Each derived leaf requirement omits the trailing :start.

A derived requirement includes a Derived From section that identifies:

The parent requirementThe Original RequirementThe obligation preserved by the derived requirementOther requirements derived from the same parent requirementA requirement that does not require decomposition uses a Source section rather than a Derived From section.

Requirement Page Structure

Each leaf requirement page uses the following sections where applicable:

StatementSourceDerived FromRationaleApplies ToVerificationReferenced ByDelivery PhaseImplementation StatusRequirement StatusIssuesNotes for EditorsThe Source and Derived From sections are mutually exclusive.

A requirement page uses Source when the requirement does not result from the decomposition of another requirement.

A requirement page uses Derived From only when the requirement results from the decomposition of a parent requirement.

Normative Language

Requirement Statements use the following normative terms:

SHALL identifies a mandatory requirementSHALL NOT identifies a mandatory prohibitionMAY identifies a permitted capability or actionSHOULD identifies an advisory recommendationThe Statement section contains only the normative requirement.

Rationale, examples, implementation information, verification information, source information, and editorial guidance remain outside the Statement section.

Requirement Quality

Each DIDO-TE requirement conforms to the applicable CWE and SDA rules.

Each requirement:

Has a unique and stable identifierExpresses a single, independently interpretable obligationIdentifies the responsible actorIdentifies the required behavior, outcome, permission, or prohibitionUses defined terminology consistentlyUses explicit normative languageAvoids vague, weak, open-ended, and logically ambiguous expressionsAvoids implementation-specific mechanisms unless the mechanism constitutes an approved constraintSupports objective verificationPreserves traceability to the source materialPreserves traceability to architecture, implementation, test, Evidence, and conformance artifacts

Requirement Status

Requirement Status identifies the governance state of the requirement.

Possible states include:

DraftProposedApprovedDeprecatedSupersededWithdrawn

Implementation Status

Implementation Status identifies the state of DIDO-TE relative to the requirement.

Possible states include:

ImplementedPartially ImplementedDemonstratedPlannedDeferredStrategic UnscheduledUnsupportedNot AssessedRequirement Status and Implementation Status remain separate.

An approved requirement can remain planned, partially implemented, deferred, unsupported, or not assessed.

Contents

Notes for Editors

Annex C is the authoritative source for DIDO-TE normative requirements.

The draft Requirements Register remains source material. Its REQ-0001 through REQ-0091 identifiers remain source-reference identifiers and do not become canonical DIDO-TE requirement identifiers.

Do not change an assigned requirement identifier because the requirement moves to another section.

Do not reuse an identifier assigned to a retired, withdrawn, deprecated, or superseded requirement.

Apply SDA pattern detection before performing CWE evaluation.

Preserve traceability from each DIDO-TE requirement to:

The source requirementSupporting source materialApplicable ConOps scenariosApplicable architecture sectionsImplementation artifactsVerification activitiesVerification resultsEvidenceIdentified issuesUse a non-leaf parent page only when requirement decomposition requires one.

Leaf requirement pages omit a trailing :start from their namespaces.

Non-leaf requirement pages retain a trailing :start in their namespaces.

Do not rename a requirement page after an external citation unless a redirect or move plan is in place.

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.