C.1 Mission Objectives

Go to DIDO-TE Requirements

The Mission Objectives identify the high-level outcomes that guide the Distributed Immutable Data Object Test Environment (DIDO-TE) requirements, Concept of Operations, architecture, implementation, operation, and Operational Lifecycle.

The DIDO-TE Mission Objectives address:

• Governed Test Environments
• Reproducible Test Environments and Test Execution
• Automated Test Execution
• Baseline establishment
• Baseline comparison
• Comparative evaluation of candidate solutions
• Validation
• Connected, disconnected, and air-gapped operation
• Traceable Test Results
• Governed Evidence
• Reusable Test Definitions
• Reusable Executable Artifacts
• 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 Requirements define the independently verifiable obligations that support those outcomes.

• MO-001 — Governed Distributed Test Environments
• MO-002 — Reproducible Test Environments and Tests
• MO-003 — Automated Test Execution
• MO-004 — DIDO Baseline Comparison and Validation
• MO-005 — Comparative Evaluation of Candidate Solutions
• MO-006 — Application-Independent and Infrastructure-Independent Testing

  • MO-006a — Application-Independent Testing
  • MO-006b — Infrastructure-Independent Testing
• MO-007 — Connected, Disconnected, and Air-Gapped Operation
• MO-008 — Traceable Test Results and Evidence
• MO-009 — Reusable Test Assets

This page is a non-leaf requirements category page and does not contain normative Requirement Statements.

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 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 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:

{{section><namespace>#Statement&noheader&nofooter&noeditbtn}}

Replace <namespace> with the namespace of the Requirement page to reference.

Use the section name Statement exactly as it appears on the Requirement page.

Leaf Requirement pages omit a trailing :start from their namespaces.

Non-leaf Requirement pages retain a trailing :start in their namespaces.

Do not rename a Requirement page after an external citation unless a redirect or move plan is in place.