dido:03-dido-te:99-annexes:annex-c-requirements:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
dido:03-dido-te:99-annexes:annex-c-requirements:start [2026/08/07 09:36] – nick_didodido:03-dido-te:99-annexes:annex-c-requirements:start [2026/08/19 18:16] (current) – nick_dido
Line 3: Line 3:
 [[dido:03-dido-te:99-annexes:start|Go to Annexes]] [[dido:03-dido-te:99-annexes:start|Go to Annexes]]
  
-Annex C contains the canonical requirements register for the Distributed Immutable Data Object Test Environment (DIDO-TE).+Annex C contains the canonical requirements register for this specification.
  
-Annex C organises requirements 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 reference each requirement through its stable identifier and URI.+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.
  
-The draft Requirements Register provides one source of requirements and supporting information for this annex. The identifiers ''REQ-0001'' through ''REQ-0091'' identify requirements in that source register. Annex C preserves those identifiers for traceability but assigns canonical DIDO-TE identifiers to requirements derived from the register.+A requirement page may be a leaf page containing an independently verifiable normative obligation or a non-leaf page organizing subordinate requirements.
  
-Additional requirements may derive from the references identified in [[dido:03-dido-te:99-annexes:annex-b-references:start|Annex B: References]], including:+The requirements register distinguishes between:
  
-  * [[dido:03-dido-te:99-annexes:annex-b-references:dte-001|[DTE1] U.S. Patent Application US20220237111A1]] +  * The governance status of a requirement 
-  * [[dido:03-dido-te:99-annexes:annex-b-references:dte-002|[DTE2] Non-Traditional BAA Submission]] +  * The delivery phase associated with a requirement 
-  * [[dido:03-dido-te:99-annexes:annex-b-references:dte-003|[DTE3] Draft BAA White Paper]] +  * The source and derivation of a requirement 
-  * [[dido:03-dido-te:99-annexes:annex-b-references:dte-004|[DTE4] DIDO Reference Data Model]]+  * 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
  
-DIDO-TE requirements conform to the:+Requirements in this register define required capabilities and constraints without prescribing a particular product, implementation, or realization technology.
  
-  * Common Specification Weakness Enumeration (CWE) +Traceability maintains relationships between requirements and specific Reference Architectures, products, architectural capabilities, ConOps activities, or implementations.
-  * OMG Specification Discipline and Authoring (SDA) +
-  * DIDO Solutions shared [[dido:99_annexes:annex-b-terms-and-definitions:start|Terms and Definitions]]+
  
-SDA provides the detection layer for candidate specification weaknesses. CWE provides the authoritative evaluation layer for confirming defects, identifying governing rules, assigning classifications and severity, selecting applicable defect patterns, and recording traceable findings.+===== Requirement Categories =====
  
-Annex C distinguishes among: +The requirements register uses the following requirement categories:
- +
-  * The canonical DIDO-TE requirement +
-  * The source material +
-  * The requirement lineage +
-  * The requirement class +
-  * The governance status of the requirement +
-  * The delivery phase associated with the requirement +
-  * The implementation status of DIDO-TE relative to the requirement +
-  * The verification activities used to determine whether DIDO-TE satisfies the requirement +
-  * The Evidence required to support the verification result +
-  * The architecture, ConOps, and operational concepts that support the requirement +
- +
-===== 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:01-mission-objectives:start|C.1 Mission Objectives]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:02-functional-requirements:start|C.2 Functional Requirements]] +  * [[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:02-functional-requirements:02-01-test-environment-configuration:start|C.2.1 Test Environment Configuration]] +  * [[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:02-functional-requirements:02-02-nodes-and-deployment-targets:start|C.2.2 Nodes and Deployment Targets]] +    * [[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:02-functional-requirements:02-03-twin-nodes:start|C.2.3 Twin Nodes]] +    * [[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:02-functional-requirements:02-04-virtual-networks-and-communication:start|C.2.4 Virtual Networks and Communication]] +    * [[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:02-functional-requirements:02-05-state-and-time-control:start|C.2.5 State and Time Control]] +    * [[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:02-functional-requirements:02-06-test-definition:start|C.2.6 Test Definition]] +    * [[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:02-functional-requirements:02-07-test-execution:start|C.2.7 Test Execution]] +    * [[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:02-functional-requirements:02-08-record-and-playback:start|C.2.8 Record and Playback]] +    * [[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:02-functional-requirements:02-09-baseline-and-comparison:start|C.2.9 Baseline and Comparison]] +    * [[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:02-functional-requirements:02-10-validation:start|C.2.10 Validation]] +    * [[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:02-functional-requirements:02-11-monitoring-and-evidence:start|C.2.11 Monitoring and Evidence]] +    * [[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:02-functional-requirements:02-12-catalogs-and-reuse:start|C.2.12 Catalogs and Reuse]] +    * [[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:02-functional-requirements:02-13-governance-and-communities-of-interest:start|C.2.13 Governance and Communities of Interest]] +    * [[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:02-functional-requirements:02-14-dido-te-operations:start|C.2.14 DIDO-TE Operations]] +  * [[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:03-security-requirements:start|C.3 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:04-logging-and-auditing-requirements:start|C.4 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:05-reliability-requirements:start|C.5 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:06-performance-requirements:start|C.6 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:07-maintainability-requirements:start|C.7 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:08-data-management-requirements:start|C.8 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:09-interoperability-requirements:start|C.9 Interoperability Requirements]]+  * [[dido:03-dido-te:99-annexes:annex-c-requirements:11-conformance-requirements:start|C.11 Conformance Requirements]]
  
 ===== Requirement Identifiers ===== ===== Requirement Identifiers =====
  
-DIDO-TE uses the following requirement-class identifiers:+Each requirement has a stable requirement identifier.
  
-^ Requirement Class ^ Prefix ^ +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.
-| 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.+For example, a Node requirement identified as ''NOD-013'' remains ''NOD-013'' if the Node Requirements namespace is relocated within Annex C.
  
-Examples include:+Requirement identifiers SHALL NOT be reused for a different requirement after assignment.
  
-  * ''MO-001'' +A requirement that is withdrawn, deprecated, or superseded retains its identifier and governance history.
-  * ''OR-001'' +
-  * ''FR-001'' +
-  * ''SEC-001'' +
-  * ''PER-001''+
  
-A requirement identifier remains stable when the requirement moves to another section or undergoes an editorial revision that does not substantively change the requirement.+===== Requirement Prefixes =====
  
-Annex C does not reassign a retired, withdrawn, deprecated, or superseded identifier to another requirement.+Requirement identifiers use a controlled prefix that identifies the requirement family.
  
-===== Requirement Decomposition =====+The prefix identifies the subject area of the requirement and remains stable even if the requirement is moved within the Annex C hierarchy.
  
-Each normative requirement expresses one independently interpretable and independently verifiable obligation.+^ 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 |
  
-When a source requirement contains multiple normative obligations, Annex C preserves the composite requirement on a non-leaf parent page and assigns a lowercase suffix to each derived leaf requirement.+Requirement identifiers use the form:
  
-For example:+<code> 
 +PREFIX-NNN 
 +</code>
  
-  * ''FR-040'' identifies the composite requirement represented by the parent page +where:
-  * ''FR-040a'' identifies the first derived requirement +
-  * ''FR-040b'' identifies the second derived requirement+
  
-The non-leaf parent page retains a trailing '':start'' in its namespace. Each derived leaf requirement omits a trailing '':start''. +  * ''PREFIX'' identifies the requirement family 
- +  * ''NNN'' is a sequential identifier within that family
-The parent page preserves the composite source statement and links to each derived leaf requirement. Each derived requirement identifies the parent requirement and the specific obligation preserved from the composite statement. +
- +
-Decomposition does not change the source provenance. A derived leaf requirement retains traceability to both its parent requirement and the external source material from which the requirement originated. +
- +
-===== Source and Derivation Traceability ===== +
- +
-The **Source** section identifies the external source material supporting a requirement. +
- +
-Sources include: +
- +
-  * The draft Requirements Register +
-  * Annex B references +
-  * Approved architecture content +
-  * Approved ConOps content +
-  * Approved governance decisions +
-  * Other authoritative source artifacts +
- +
-A citation identifies the most precise available source location, such as a requirement identifier, section, clause, claim, page, figure, table, diagram, package, class, datatype, attribute, association, or model element.+
  
 For example: For example:
  
-<code dokuwiki> +<code> 
-[[dido:03-dido-te:99-annexes:annex-b-references:dte-002|[DTE2]]], Section 2.1.1, Key Tasks.+ENV-001 
 +NOD-013 
 +TEX-004 
 +SEC-002
 </code> </code>
  
-The **Derived From** section identifies requirement lineage within Annex C. It identifies the non-leaf parent requirement and the particular source obligation preserved by the derived leaf requirement.+A requirement prefix SHALL NOT change solely because the requirement page or requirement category is reorganized within Annex C.
  
-For example:+A retired or superseded requirement identifier SHALL NOT be reassigned to a different requirement.
  
-<code dokuwiki> +===== Requirement Decomposition =====
-[[dido:03-dido-te:99-annexes:annex-c-requirements:02-functional-requirements:02-06-test-definition:fr-040:start|FR-040]], source obligation concerning test-step sequencing. +
-</code>+
  
-The **Source** and **Derived From** sections serve different purposes and are not mutually exclusive. A decomposed requirement normally uses both:+A source requirement may contain multiple independently verifiable obligations.
  
-  * **Source** records external provenance. +A source requirement containing multiple independently verifiable obligations may be decomposed into multiple requirements when decomposition improves atomicity, clarity, traceability, or verification.
-  * **Derived From** records requirement decomposition and lineage.+
  
-A requirement that does not result from decomposition omits the **Derived From** section.+Derived requirements preserve traceability to the source requirement, architectural concept, model element, or other authoritative basis from which they were derived.
  
-===== Conceptual-Model Derivation =====+Decomposition SHALL NOT change the approved intent of the source obligation.
  
-[[dido:03-dido-te:99-annexes:annex-b-references:dte-004|[DTE4]]] records a historical Conceptual Model. Requirements derived from `[DTE4]` identify the precise package, diagram, model element, datatype, attribute, association, enumeration, or qualified model path supporting the requirement.+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.
  
-For example:+===== Source and Derivation Traceability =====
  
-<code dokuwiki> +Each requirement identifies its authoritative source or derivation basis where applicable.
-[[dido:03-dido-te:99-annexes:annex-b-references:dte-004|[DTE4]]], conceptual datatype //yes_no_type//. +
-</code>+
  
-DIDO-TE preserves the following model progression:+A requirement may originate from:
  
-  - The Conceptual Model defines implementation-independent concepts, meanings, relationships, and semantic value spaces. +  * A source requirement 
-  - A Logical Model maps applicable conceptual elements and datatypes to implementable logical representations. +  * A normative specification or other controlled document 
-  - A Physical Model maps applicable logical representations to concrete platform-specific structures, datatypes, encodings, and constraints.+  * A policy or governed constraint 
 +  * A conceptual or logical model 
 +  * An architectural decomposition 
 +  * An approved governance determination 
 +  * Another requirement
  
-A requirement derived from a conceptual-model element preserves the implementation-independent meaning of the source element. It does not prescribe a logical or physical representation unless an approved constraint expressly requires that representation.+Source material may be normalized when necessary to produce an atomic, clear, verifiable requirement.
  
-Conceptual-to-logical and logical-to-physical mappings remain explicit and traceable. Each mapping identifies:+Normalization may correct:
  
-  * The source element +  * Terminology 
-  * The target element +  * Grammar 
-  * The value correspondence +  * Active or passive voice 
-  * Applicable constraints +  * Normative modality 
-  * Null semantics, when applicable +  * Ambiguous subjects 
-  * Any information loss or semantic change +  * Compound obligations 
-  * The rationale for the selected mapping+  * Undefined references 
 +  * Implementation-specific wording that is inappropriate at the architectural level
  
-===== Source Normalisation =====+Normalization SHALL preserve the source's approved intent.
  
-Annex C corrects spelling, spacing, capitalisation, and naming inconsistencies when incorporating historical source material into current DIDO-TE requirements.+The applicable governance process SHALL approve a material change in requirement intent.
  
-A derivation record preserves the original source expression and identifies the normalised expression when the correction affects traceability. +Editorial normalization SHALL NOT introduce a material change in intent.
- +
-For example: +
- +
-^ Source name in [DTE4] ^ Normalised name ^ +
-| ''Parameter_Diretion_Type'' | ''Parameter Direction Type'' | +
-| ''ParameterLlist Type'' | ''Parameter List Type'' | +
-| ''Parameter_Definition_Type'' | ''Parameter Definition Type'' | +
- +
-An editorial normalisation preserves the original meaning. +
- +
-A change to values, constraints, cardinality, relationships, or meaning constitutes a substantive model change. Annex C records the rationale and disposition for each substantive change.+
  
 ===== Requirement Page Structure ===== ===== Requirement Page Structure =====
  
-Each leaf requirement page uses the following sections where applicable:+Each requirement page uses the following sections where applicable:
  
   * Statement   * Statement
   * Source   * Source
-  * Derived From 
   * Rationale   * Rationale
   * Applies To   * Applies To
   * Verification   * Verification
-  * Referenced By+  * Traceability 
 +  * ConOps Relationship
   * Delivery Phase   * Delivery Phase
-  * Implementation Status 
   * Requirement Status   * Requirement Status
-  * Issues 
-  * Notes for Editors 
  
-Every leaf requirement contains a **Source** section.+A leaf requirement page contains an independently verifiable normative obligation and therefore includes a ''Statement'' section and a ''Verification'' section.
  
-A leaf requirement contains a **Derived From** section when it results from the decomposition of a non-leaf parent requirement.+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.
  
-The **Statement** section contains only the normative requirement. +Additional sections SHALL NOT be added to individual requirement pages merely to duplicate information maintained through backlinks, traceability records, or another authoritative register.
- +
-The **Verification** section identifies objective activities and results that determine whether DIDO-TE satisfies the requirement. +
- +
-The **Referenced By** section uses backlinks to identify pages that reference the requirement.+
  
 ===== Normative Language ===== ===== Normative Language =====
  
-Requirement Statements use the following normative terms:+Requirement statements use the following normative terms:
  
   * **SHALL** identifies a mandatory requirement   * **SHALL** identifies a mandatory requirement
   * **SHALL NOT** identifies a mandatory prohibition   * **SHALL NOT** identifies a mandatory prohibition
-  * **MAY** identifies a permission +  * **MAY** identifies a permitted capability or action 
-  * **SHOULD** identifies an advisory recommendation +  * **SHOULD** identifies a recommendation when advisory language remains appropriate
-  * **SHOULD NOT** identifies an advisory prohibition +
- +
-Only **SHALL** and **SHALL NOT** establish mandatory conformance obligations.+
  
-The Statement section contains only the normative statement.+Normative modal verbs are written in uppercase.
  
-Rationale, examples, implementation information, verification information, source information, derivation information, and editorial guidance remain outside the Statement section.+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 ===== ===== Requirement Quality =====
  
-Each DIDO-TE requirement conforms to the applicable CWE and SDA rules.+Requirements are reviewed for specification quality before approval.
  
-Each requirement:+Requirement review examines characteristics including:
  
-  * Has a unique and stable identifier +  * Atomicity 
-  * Expresses a single, independently interpretable obligation +  * Clear identification of the responsible subject 
-  * Identifies the responsible actor +  * Defined terminology 
-  * Identifies the required behaviour, outcome, permission, or prohibition +  * Appropriate normative modality 
-  * Uses defined terminology consistently +  * Active voice 
-  * Uses explicit normative language +  * Unambiguous scope 
-  * Avoids vague, weak, open-ended, and logically ambiguous expressions +  * Verifiability 
-  * Avoids implementation-specific mechanisms unless an approved constraint requires the mechanism +  * Traceability 
-  * Supports objective verification +  * Consistency with related requirements 
-  * Preserves traceability to source material +  * Absence of unnecessary implementation constraints 
-  * Preserves traceability to architecture, implementation, tests, Evidence, and conformance artifacts+  * Absence of unresolved conflicts or ambiguous precedence
  
-SDA analysis identifies candidate weaknesses. CWE evaluation confirms defects and records:+Specification Discipline and Authoring (SDA) identifies candidate weaknesses in requirement wording, structure, terminology, traceability, or semantics.
  
-  * The governing rule +The Common Specification Weakness Enumeration (CWE) evaluates candidate findings, confirms applicable defects, and records their classification, severity, governing rule, and applicable defect pattern. 
-  * The defect classification + 
-  * The assigned severity +Automated or AI-assisted analysis may identify, compare, trace, or propose corrections to candidate issues. 
-  * The applicable defect pattern + 
-  * The affected requirement +Automated or AI-assisted analysis SHALL NOT resolve conflicts, ambiguities, or precedence among governed requirements, policies, specifications, profiles, or other authoritative constraints. 
-  * The supporting rationale + 
-  * The required disposition+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 =====
  
-Requirement Status identifies the governance state of the requirement.+Requirement Status identifies the requirement's governance state.
  
 Possible states include: Possible states include:
Line 278: Line 235:
   * Withdrawn   * Withdrawn
  
-===== Implementation Status =====+Requirement Status describes the requirement's authority and lifecycle state. It does not describe whether a particular product or implementation satisfies the requirement.
  
-Implementation Status identifies the state of DIDO-TE relative to the requirement.+===== Realization and Implementation Status =====
  
-Possible states include:+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   * Implemented
Line 288: Line 253:
   * Demonstrated   * Demonstrated
   * Planned   * Planned
-  * Deferred 
-  * Strategic Unscheduled 
   * Unsupported   * Unsupported
   * Not Assessed   * Not Assessed
  
-Requirement Status and Implementation Status remain separate. +Requirement Status and realization-specific Implementation Status remain separate.
- +
-An approved requirement may remain planned, partially implemented, deferred, unsupported, or not assessed.+
  
 ===== Contents ===== ===== Contents =====
  
-{{indexmenu>dido:03-dido-te:99-annexes:annex-c-requirements#1|js navbar nocookie maxjs#5 id#dido_te_annex_c_requirements_nav}}+  * [[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}}
  
 ---- ----
Line 305: Line 290:
 ===== Notes for Editors ===== ===== Notes for Editors =====
  
-Annex C is the authoritative source for DIDO-TE normative requirements. +<todo>Remove the explicit creation links under Contents after all planned requirement-category pages have been created and the indexmenu discovers them.</todo>
- +
-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. +
- +
-Treat [[dido:03-dido-te:99-annexes:annex-b-references:dte-004|[DTE4]]] as a historical Conceptual Model and a source of conceptual-model provenance. Do not treat every class, datatype, relationship, or diagram in `[DTE4]` as a current normative DIDO-TE requirement. +
- +
-Identify the precise source location for every requirement. Do not cite only a reference identifier when a more precise location exists. +
- +
-Use **Source** to record external provenance. Use **Derived From** to record requirement decomposition and lineage. Do not use one section as a substitute for the other. +
- +
-Preserve original source identifiers, names, and expressions in traceability records. +
- +
-Correct spelling and naming defects in current DIDO-TE requirements. Record the original and normalised expressions when a correction affects traceability. +
- +
-Do not classify changes to values, constraints, cardinality, relationships, or meaning as editorial corrections. +
- +
-Preserve the distinction among Conceptual Models, Logical Models, and Physical Models. +
- +
-Do not place implementation-specific datatypes, encodings, products, or technologies in a conceptual-model requirement unless an approved constraint expressly requires them. +
- +
-Record conceptual-to-logical and logical-to-physical mappings explicitly and preserve required semantic distinctions through each mapping. +
- +
-Apply SDA pattern detection before performing CWE evaluation. +
- +
-Preserve traceability from each DIDO-TE requirement to: +
- +
-  * External source material +
-  * Its parent requirement, when decomposition applies +
-  * Applicable ConOps scenarios +
-  * Applicable architecture sections +
-  * Implementation artifacts +
-  * Verification activities +
-  * Verification results +
-  * Evidence +
-  * Identified issues +
- +
-Use 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 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.+Preserve stable requirement identifiers when moving or reorganizing requirement pages.
  
-Do not rename a requirement page after an external citation unless a redirect or move plan is in place.+Do not allocate canonical requirements directly to Crucible, DevSecOps, or another realization within the requirement Statement. Maintain realization relationships through Traceability.
  
 ---- ----
  • dido/03-dido-te/99-annexes/annex-c-requirements/start.1786120578.txt.gz
  • Last modified: 2026/08/07 09:36
  • by nick_dido