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/17 10:55] – [Contents] nick_didodido:03-dido-te:99-annexes:annex-c-requirements:start [2026/08/19 18:16] (current) – nick_dido
Line 5: Line 5:
 Annex C contains the canonical requirements register for this specification. 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 leaf 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 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 requirements register distinguishes between:
  
-* The governance status of a requirement +  * The governance status of a requirement 
-* The delivery phase associated with a requirement +  * The delivery phase associated with a requirement 
-* The source and derivation of a requirement +  * The source and derivation of a requirement 
-* The architecture and operational concepts associated with a requirement +  * The architecture and operational concepts associated with a requirement 
-* The ConOps activities associated with a requirement +  * The ConOps activities associated with a requirement 
-* The verification activities used to determine whether a realization satisfies 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. Requirements in this register define required capabilities and constraints without prescribing a particular product, implementation, or realization technology.
Line 27: Line 29:
   * [[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-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: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-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-02-node-requirements:start|C.3.2 Node Requirements]]
Line 60: Line 61:
  
 A requirement that is withdrawn, deprecated, or superseded retains its identifier and governance history. 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 ===== ===== Requirement Decomposition =====
Line 65: Line 120:
 A source requirement may contain multiple independently verifiable obligations. A source requirement may contain multiple independently verifiable obligations.
  
-Decompose such a requirement into multiple requirements when decomposition improves atomicity, clarity, traceability, or verification.+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. Derived requirements preserve traceability to the source requirement, architectural concept, model element, or other authoritative basis from which they were derived.
Line 79: Line 134:
 A requirement may originate from: A requirement may originate from:
  
-* A source requirement +  * A source requirement 
-* A normative specification or other controlled document +  * A normative specification or other controlled document 
-* A policy or governed constraint +  * A policy or governed constraint 
-* A conceptual or logical model +  * A conceptual or logical model 
-* An architectural decomposition +  * An architectural decomposition 
-* An approved governance determination +  * An approved governance determination 
-* Another requirement+  * Another requirement
  
 Source material may be normalized when necessary to produce an atomic, clear, verifiable requirement. Source material may be normalized when necessary to produce an atomic, clear, verifiable requirement.
Line 91: Line 146:
 Normalization may correct: Normalization may correct:
  
-* Terminology +  * Terminology 
-* Grammar +  * Grammar 
-* Active or passive voice +  * Active or passive voice 
-* Normative modality +  * Normative modality 
-* Ambiguous subjects +  * Ambiguous subjects 
-* Compound obligations +  * Compound obligations 
-* Undefined references +  * Undefined references 
-* Implementation-specific wording that is inappropriate at the architectural level+  * Implementation-specific wording that is inappropriate at the architectural level
  
 Normalization SHALL preserve the source's approved intent. Normalization SHALL preserve the source's approved intent.
  
-When a material change in intent is required, the change SHALL be handled through the applicable governance process rather than treated as editorial normalization.+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 =====
Line 108: Line 165:
 Each requirement page uses the following sections where applicable: Each requirement page uses the following sections where applicable:
  
-* Statement +  * Statement 
-* Source +  * Source 
-* Rationale +  * Rationale 
-* Applies To +  * Applies To 
-* Verification +  * Verification 
-* Traceability +  * Traceability 
-* ConOps Relationship +  * ConOps Relationship 
-* Delivery Phase +  * Delivery Phase 
-* Requirement Status+  * 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. Additional sections SHALL NOT be added to individual requirement pages merely to duplicate information maintained through backlinks, traceability records, or another authoritative register.
Line 124: Line 185:
 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 a recommendation when advisory language remains appropriate+  * **SHOULD** identifies a recommendation when advisory language remains appropriate
  
 Normative modal verbs are written in uppercase. Normative modal verbs are written in uppercase.
Line 139: Line 200:
 Requirement review examines characteristics including: Requirement review examines characteristics including:
  
-* Atomicity +  * Atomicity 
-* Clear identification of the responsible subject +  * Clear identification of the responsible subject 
-* Defined terminology +  * Defined terminology 
-* Appropriate normative modality +  * Appropriate normative modality 
-* Active voice +  * Active voice 
-* Unambiguous scope +  * Unambiguous scope 
-* Verifiability +  * Verifiability 
-* Traceability +  * Traceability 
-* Consistency with related requirements +  * Consistency with related requirements 
-* Absence of unnecessary implementation constraints +  * Absence of unnecessary implementation constraints 
-* Absence of unresolved conflicts or ambiguous precedence+  * Absence of unresolved conflicts or ambiguous precedence
  
-Specification Defect Analysis (SDA) may identify candidate weaknesses in requirement wording, structure, terminology, traceability, or semantics.+Specification Discipline and Authoring (SDA) identifies candidate weaknesses in requirement wording, structure, terminology, traceability, or semantics.
  
-Common Weakness Enumeration (CWE) analysis may classify confirmed specification defects where applicable.+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 analysis does not make authoritative governance determinations.+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. 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.
Line 165: Line 228:
 Possible states include: Possible states include:
  
-* Draft +  * Draft 
-* Proposed +  * Proposed 
-* Approved +  * Approved 
-* Deprecated +  * Deprecated 
-* Superseded +  * Superseded 
-* Withdrawn+  * Withdrawn
  
 Requirement Status describes the requirement's authority and lifecycle state. It does not describe whether a particular product or implementation satisfies the requirement. Requirement Status describes the requirement's authority and lifecycle state. It does not describe whether a particular product or implementation satisfies the requirement.
Line 178: Line 241:
 Requirements in this annex are product-neutral and may be realized by one or more architectural capabilities, Reference Architectures, products, services, or implementations. 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 is itself part of the approved requirement.+The canonical requirement does not prescribe a specific realization unless such a constraint forms part of the approved requirement.
  
-Maintain realization relationships separately through traceability.+Traceability records maintain relationships between canonical requirements and their realizations.
  
-For example, requirements in this annex may be realized wholly or partially by:+The applicable realization maintains Implementation Status. Implementation Status is not a property of the canonical requirement.
  
-* Crucible +A realization may identify its relationship to a requirement using implementation states such as:
-* A conforming DevSecOps Reference Architecture realization +
-* A distributed testing capability +
-* Another DIDO Solutions capability +
-* An external conforming implementation+
  
-The applicable realization, rather than the canonical requirement, maintains Implementation Status. +  * Implemented 
- +  * Partially Implemented 
-A realization may therefore identify its relationship to a requirement using implementation states such as: +  * Demonstrated 
- +  * Planned 
-* Implemented +  * Unsupported 
-* Partially Implemented +  * Not Assessed
-* Demonstrated +
-* Planned +
-* Unsupported +
-* Not Assessed+
  
 Requirement Status and realization-specific Implementation Status remain separate. Requirement Status and realization-specific Implementation Status remain separate.
Line 231: Line 286:
 {{indexmenu>dido:03-dido-te:99-annexes:annex-c-requirements#1|js navbar nocookie maxjs#4 id#dido_te_annex_c_requirements_nav}} {{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 =====
  
-<todo>Existing requirement-family namespaces must be moved into the requirement hierarchy defined under Requirement Categories.</todo>+<todo>Remove the explicit creation links under Contents after all planned requirement-category pages have been created and the indexmenu discovers them.</todo>
  
-<todo>Preserve existing stable requirement identifiers when moving requirement pages.</todo>+Preserve stable requirement identifiers when moving or reorganizing requirement pages.
  
-<todo>Update affected backlinks, source-section transclusions, and requirement-family navigation after each namespace migration.</todo>+Do not allocate canonical requirements directly to Crucible, DevSecOps, or another realization within the requirement Statement. Maintain realization relationships through Traceability.
  
-<todo>Do not allocate canonical requirements directly to Crucible, DevSecOps, or another realization within the requirement statement. Maintain realization relationships through traceability.</todo> +----
- +
----+
  
 <WRAP centeralign> <WRAP centeralign>
 © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
 </WRAP> </WRAP>
- 
  • dido/03-dido-te/99-annexes/annex-c-requirements/start.1786989317.txt.gz
  • Last modified: 2026/08/17 10:55
  • by nick_dido