Differences

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

--- dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:start [2026/08/04 02:41] – created nick_dido
+++ dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:start [2026/08/19 18:20] (current) – nick_dido
@@ Line 1: / Line 1: @@
 ====== C.1 Mission Objectives ======
-[[dido:03-dido-te:99-annexes:annex-c-requirements:start|Go to DIDO-TE Requirements]]
+[[dido:03-dido-te:99-annexes:annex-c-requirements:start|Go to Annex C: Requirements]]
-The [[dido:99_annexes:annex-b-terms-and-definitions:m:mission_objective|Mission Objectives]] identify the high-level outcomes that guide the DIDO-TE requirements, Concept of Operations, architecture, implementation, operation, and [[dido:99_annexes:annex-b-terms-and-definitions:o:operational_lifecycle|Operational Lifecycle]].
+The [[dido:99_annexes:annex-b-terms-and-definitions:m:mission_objective|Mission Objectives]] identify the high-level outcomes that guide the [[dido:99_annexes:annex-b-terms-and-definitions:d:dido-te|Distributed Immutable Data Object Test Environment (DIDO-TE)]] requirements, [[dido:99_annexes:annex-b-terms-and-definitions:c:concept_of_operations|Concept of Operations]], architecture, realization, operation, and [[dido:99_annexes:annex-b-terms-and-definitions:o:operational_lifecycle|Operational Lifecycle]].
-The DIDO-TE Mission Objectives address governed and reproducible test environments, automated test execution, baseline generation, comparison, validation, Evidence generation, secure operation, reuse, and integration with external systems.
+Mission Objectives describe intended outcomes rather than prescribing a particular product, implementation, or realization technology.
-Mission Objectives describe the outcomes DIDO-TE seeks to achieve. Functional, security, logging and auditing, reliability, performance, maintainability, data management, and interoperability requirements define the independently verifiable obligations that support those outcomes.
+The DIDO-TE Mission Objectives address:
+  * [[dido:99_annexes:annex-b-terms-and-definitions:g:governed|Governed]] [[dido:99_annexes:annex-b-terms-and-definitions:t:test_environment|Test Environments]]
+  * [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducible]] Test Environments
+  * Reproducible [[dido:99_annexes:annex-b-terms-and-definitions:t:test_execution|Test Execution]]
+  * Automated Test Execution
+  * [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] establishment
+  * Baseline comparison
+  * Comparative evaluation of candidate solutions
+  * [[dido:99_annexes:annex-b-terms-and-definitions:v:validation|Validation]]
+  * [[dido:99_annexes:annex-b-terms-and-definitions:c:connected_environment|Connected Environment]] operation
+  * [[dido:99_annexes:annex-b-terms-and-definitions:d:disconnected_environment|Disconnected Environment]] operation
+  * [[dido:99_annexes:annex-b-terms-and-definitions:a:air-gapped_environment|Air-Gapped Environment]] operation
+  * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceable]] [[dido:99_annexes:annex-b-terms-and-definitions:t:test_result|Test Results]]
+  * Governed [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]
+  * Reusable [[dido:99_annexes:annex-b-terms-and-definitions:t:test_definition|Test Definitions]]
+  * Reusable [[dido:99_annexes:annex-b-terms-and-definitions:e:executable_artifact|Executable Artifacts]]
+  * Reusable [[dido:99_annexes:annex-b-terms-and-definitions:r:resource|Test Resources]]
+  * Integration with external systems
+Operational, functional, security, logging and auditing, reliability, performance, maintainability, data-management, interoperability, and conformance [[dido:99_annexes:annex-b-terms-and-definitions:r:requirement|Requirements]] define the independently verifiable obligations that support these outcomes.
+The Mission Objectives derive from the applicable source documents identified in Annex B. A Mission Objective may derive directly from a source obligation or result from decomposition of a broader source objective.
 ===== Contents =====
@@ Line 14: / Line 36: @@
 ----
 ===== Notes for Editors =====
-This page is a non-leaf requirements category page and does not contain normative requirement Statements.
+This page is a non-leaf requirement-category page and does not establish a separate conformance obligation.
-Assign each Mission Objective a stable identifier using the form ''MO-nnn''.
-Retain an assigned Mission Objective identifier throughout the requirement lifecycle.
-Do not reuse an identifier assigned to a retired, withdrawn, deprecated, or superseded Mission Objective.
-Preserve the wording and identifier of each Original Requirement in its source information.
-A canonical DIDO-TE Mission Objective may correct terminology, normative language, ambiguity, atomicity, or other CWE and SDA deficiencies without changing the approved intent of the Original Requirement.
-When an Original Requirement contains multiple independently interpretable or independently verifiable obligations:
-  * Preserve the Original Requirement on a non-leaf parent page
-  * Assign the parent requirement an identifier such as ''MO-002''
-  * Assign each derived leaf requirement a lowercase suffix such as ''MO-002a'' and ''MO-002b''
-  * Include a **Derived From** section on each derived requirement page
-  * Identify every requirement derived from the same parent requirement
-  * Preserve traceability to the Original Requirement
-A requirement that does not result from decomposition uses a **Source** section rather than a **Derived From** section.
-Apply SDA pattern detection before performing CWE evaluation.
-Each Mission Objective should:
-  * Identify an explicit responsible actor
-  * Express one independently interpretable outcome
-  * Use defined terminology consistently
-  * Use explicit normative language
-  * Avoid vague, weak, open-ended, and logically ambiguous expressions
-  * Avoid unnecessary implementation-specific mechanisms
-  * Support objective verification
-  * Preserve traceability to its source material
-  * Preserve traceability to supporting operational, functional, quality, and conformance requirements
-Incoming traceability should use the Wiki Backlinks function rather than a manually maintained list.
-To reference a requirement Statement from another Wiki page, insert:
-<code dokuwiki>
-{{section><namespace>#Statement&noheader&nofooter&noeditbtn}}
-</code>
-Replace ''<namespace>'' with the namespace of the requirement page to reference.
+Mission Objectives use the ''MO'' requirement prefix.
-The section name following ''#'' SHALL match the section heading verbatim on the requirement page.
+Each Mission Objective retains its assigned identifier throughout its lifecycle. Do not reuse an identifier assigned to a retired, withdrawn, deprecated, or superseded Mission Objective.
-Leaf requirement pages omit a trailing '':start'' from their namespaces.
+A Mission Objective may be represented by an individual leaf requirement or by a non-leaf requirement group when decomposition into independently verifiable subordinate objectives is required.
-Non-leaf requirement pages retain a trailing '':start'' in their namespaces.
+Apply the requirement identification, decomposition, source and derivation, normative-language, quality, status, and page-structure rules defined by Annex C.
-Do not rename a requirement page after an external citation unless a redirect or move plan is in place.
+Preserve Traceability from each Mission Objective to its source material and to the supporting operational, functional, quality, security, and conformance requirements.
 ----