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/06 12:23] – ↷ Links adapted because of a move operation 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: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, 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]].
+Mission Objectives describe intended outcomes rather than prescribing a particular product, implementation, or realization technology.
 The DIDO-TE Mission Objectives address:
@@ Line 25: / Line 27: @@
   * Integration with external systems
-Mission Objectives describe the outcomes DIDO-TE seeks to achieve.
+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.
-Operational, functional, security, logging and auditing, reliability, performance, maintainability, data-management, and interoperability [[dido:99_annexes:annex-b-terms-and-definitions:r:requirement|requirements]] define the independently verifiable obligations that support those 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 =====
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-001|MO-001 — Governed Distributed Test Environments]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-002:start|MO-002 — Reproducible Test Environments and Test Execution]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-003|MO-003 — Automated Test Execution]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-004:start|MO-004 — DIDO Baseline Comparison and Validation]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-005|MO-005 — Comparative Evaluation of Candidate Solutions]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-006:start|MO-006 — Application-Independent and Infrastructure-Independent Testing]]
-    * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-006:mo-006a|MO-006a — Application-Independent Testing]]
-    * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-006:mo-006b|MO-006b — Infrastructure-Independent Testing]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-007:start|MO-007 — Connected, Disconnected, and Air-Gapped Operation]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-008:start|MO-008 — Traceable Test Results and Evidence]]
-  * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-009|MO-009 — Reusable Test Resources]]
 {{indexmenu>dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives#1|js navbar nocookie maxjs#1 id#dido_te_mission_objectives_nav}}
@@ Line 49: / Line 39: @@
 ===== 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 can correct:
-  * Terminology
-  * Normative language
-  * Ambiguity
-  * Atomicity
-  * Traceability
-  * Implementation leakage
-  * Other candidate issues detected through OMG Specification Discipline and Authoring (SDA)
-  * Defects determined through the Common Specification Weakness Enumeration (CWE)
-Preserve the approved intent of the Original Requirement when making these corrections.
-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 [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|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 as the detection layer for candidate:
-  * Linguistic issues
-  * Structural issues
-  * Terminology issues
-  * Definition issues
-  * Modality issues
-  * Temporal issues
-  * Traceability issues
-  * Implementation-leakage issues
-Apply CWE as the evaluation layer for:
-  * Confirming defects
-  * Identifying the governing rule
-  * Assigning the defect classification
-  * Assigning the defect severity
-  * Selecting the applicable defect patterns
-  * Producing traceable defect records
-Each Mission Objective:
-  * Identifies an explicit responsible [[dido:99_annexes:annex-b-terms-and-definitions:a:actor|Actor]]
-  * Expresses one independently interpretable outcome
-  * Uses defined terminology consistently
-  * Uses explicit normative language
-  * Avoids vague, weak, open-ended, and logically ambiguous expressions
-  * Avoids unnecessary implementation-specific mechanisms
-  * Supports objective verification
-  * Preserves Traceability to its source material
-  * Preserves Traceability to supporting operational, functional, quality, security, and conformance requirements
-Use the Wiki Backlinks function for incoming Traceability rather than maintaining a manual 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.
-Use the section name ''Statement'' exactly as it appears 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.
 ----