| Both sides previous revision Previous revision Next revision | Previous revision |
| dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:start [2026/08/05 01:11] – nick_dido | dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:start [2026/08/19 18:20] (current) – nick_dido |
|---|
| ====== C.1 Mission Objectives ====== | ====== 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: | The DIDO-TE Mission Objectives address: |
| |
| * Governed [[dido:99_annexes:annex-b-terms-and-definitions:t:test_environment|Test Environments]] | * [[dido:99_annexes:annex-b-terms-and-definitions:g:governed|Governed]] [[dido:99_annexes:annex-b-terms-and-definitions:t:test_environment|Test Environments]] |
| * Reproducible Test Environments and [[dido:99_annexes:annex-b-terms-and-definitions:t:test_execution|Test Execution]] | * [[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 | * Automated Test Execution |
| * [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] establishment | * [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] establishment |
| * Comparative evaluation of candidate solutions | * Comparative evaluation of candidate solutions |
| * [[dido:99_annexes:annex-b-terms-and-definitions:v:validation|Validation]] | * [[dido:99_annexes:annex-b-terms-and-definitions:v:validation|Validation]] |
| * Connected, disconnected, and air-gapped operation | * [[dido:99_annexes:annex-b-terms-and-definitions:c:connected_environment|Connected Environment]] operation |
| * Traceable [[dido:99_annexes:annex-b-terms-and-definitions:t:test_result|Test Results]] | * [[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]] | * 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: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:e:executable_artifact|Executable Artifacts]] |
| | * Reusable [[dido:99_annexes:annex-b-terms-and-definitions:r:resource|Test Resources]] |
| * Integration with external systems | * 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, and interoperability [[dido:99_annexes:annex-b-terms-and-definitions:r:requirement|Requirements]] define the independently verifiable obligations that support those outcomes. | 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 ===== | ===== 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|MO-002 — Reproducible Test Environments and Tests]] | |
| * [[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|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|MO-007 — Connected, Disconnected, and Air-Gapped Operation]] | |
| * [[dido:03-dido-te:99-annexes:annex-c-requirements:01-mission-objectives:mo-008|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 Assets]] | |
| |
| {{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}} | {{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}} |
| ===== Notes for Editors ===== | ===== 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) | |
| | |
| These corrections must preserve 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 [[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, structural, terminology, definition, modality, temporal, traceability, and 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 must: | |
| | |
| * Identify an explicit responsible [[dido:99_annexes:annex-b-terms-and-definitions:a:actor|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, security, and conformance Requirements | |
| | |
| Incoming Traceability uses 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. |
| |
| 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. |
| |
| ---- | ---- |