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
• Reproducible Test Execution
• Automated Test Execution
• Baseline establishment
• Baseline comparison
• Comparative evaluation of candidate solutions
• Validation
• Connected Environment operation
• Disconnected Environment operation
• Air-Gapped Environment operation
• Traceable Test Results
• Governed Evidence
• Reusable Test Definitions
• Reusable Executable Artifacts
• Reusable Test Resources
• 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 Test Execution
• 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 Resources

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)

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

{{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.