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 06:19] – 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.
  
-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 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 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.+A requirement page may be a leaf page containing an independently verifiable normative obligation or a non-leaf page organizing subordinate requirements.
  
-DIDO-TE requirements conform to the:+The requirements register distinguishes between:
  
-  * Common Specification Weakness Enumeration (CWE) +  * The governance status of a requirement 
-  * OMG Specification Discipline and Authoring (SDA) +  * The delivery phase associated with a requirement 
-  * DIDO Solutions shared [[dido:99_annexes:annex-b-terms-and-definitions:start|Terms and Definitions]]+  * 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
  
-Annex C distinguishes among:+Requirements in this register define required capabilities and constraints without prescribing a particular product, implementation, or realization technology.
  
-  * The canonical DIDO-TE requirement +Traceability maintains relationships between requirements and specific Reference Architectures, products, architectural capabilities, ConOps activities, or implementations.
-  * The source requirement +
-  * 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 ===== ===== Requirement Categories =====
  
-===== 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: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 =====
  
-A retired, withdrawn, deprecated, or superseded identifier is not reassigned 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 source requirement on a non-leaf parent page and assigns a lowercase suffix to each derived 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: For example:
  
-  * ''FR-040'' identifies the source requirement represented by the parent page +<code> 
-  * ''FR-040a'' identifies the first derived requirement +ENV-001 
-  * ''FR-040b'' identifies the second derived requirement+NOD-013 
 +TEX-004 
 +SEC-002 
 +</code>
  
-The non-leaf parent page retains a trailing '':start'' in its namespace. Each derived leaf requirement omits the trailing '':start''.+A requirement prefix SHALL NOT change solely because the requirement page or requirement category is reorganized within Annex C.
  
-A derived requirement includes a **Derived From** section that identifies:+A retired or superseded requirement identifier SHALL NOT be reassigned to a different requirement.
  
-  * The parent requirement +===== Requirement Decomposition =====
-  * The Original Requirement +
-  * The obligation preserved by the derived requirement +
-  * Other requirements derived from the same parent requirement+
  
-A requirement that does not require decomposition uses a **Source** section rather than a **Derived From** section.+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 ===== ===== 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 
  
-The **Source** and **Derived From** sections are mutually exclusive.+A leaf requirement page contains an independently verifiable normative obligation and therefore includes a ''Statement'' section and a ''Verification'' section.
  
-A requirement page uses **Source** when the requirement does not result from the decomposition of another 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.
  
-A requirement page uses **Derived From** only when the requirement results from the decomposition of a parent requirement.+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 ===== ===== 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 permitted capability or action   * **MAY** identifies a permitted capability or action
-  * **SHOULD** identifies an advisory recommendation+  * **SHOULD** identifies a recommendation when advisory language remains appropriate
  
-The Statement section contains only the normative requirement.+Normative modal verbs are written in uppercase.
  
-Rationale, examples, implementation information, verification information, source 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 behavior, 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 the mechanism constitutes an approved constraint +  * Traceability 
-  * Supports objective verification +  * Consistency with related requirements 
-  * Preserves traceability to the source material +  * Absence of unnecessary implementation constraints 
-  * Preserves traceability to architecture, implementation, test, Evidence, and conformance artifacts+  * 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 =====
  
-Requirement Status identifies the governance state of the requirement.+Requirement Status identifies the requirement's governance state.
  
 Possible states include: Possible states include:
Line 177: 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 187: 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 can 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}}
  
 ---- ----
 +
 ===== 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. +
- +
-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 requirement +
-  * Supporting source material +
-  * 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.+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.1786108773.txt.gz
  • Last modified: 2026/08/07 06:19
  • by nick_dido