Differences

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

--- dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-003:start [2026/07/20 09:08] – nick_dido
+++ dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-003:start [2026/07/22 10:00] (current) – [Original Requirement] nick_dido
@@ Line 5: / Line 5: @@
 ===== Original Requirement =====
-> //The system SHALL provide cloud-agnostic deployment capabilities.//[[dido:02-crusible:99-annexes:annex-b:cr-003|[C3]]]
+> //The system SHALL provide cloud-agnostic deployment capabilities.//[[dido:02-crusible:99-annexes:annex-b:cr-002|[C2]]]
 ===== Assessment of Original Requirement =====
@@ Line 14: / Line 14: @@
   * **The system** does not use the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]
-  * **Provide** is a weak verb that does not identify the behavior Crucible performs
+  * **Provide** is a weak verb that does not identify an observable behavior performed by Crucible
-  * **Cloud-agnostic** refers to the defined concept [[dido:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism|Cloud Agnosticism]], but the Original Requirement does not identify the architectural dependencies that Crucible is required to limit
+  * **Cloud-agnostic** refers to [[dido:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism|Cloud Agnosticism]], but the Original Requirement does not identify the dependencies that Crucible must limit
   * **Deployment capabilities** does not identify the deployable subject, deployment inputs, target [[dido:99_annexes:annex-b-terms-and-definitions:d:deployment_platform|Deployment Platforms]], or required deployment outcome
-  * The Original Requirement does not identify the proprietary interfaces, services, data formats, software development kits, or operational mechanisms from which Crucible limits dependence
-  * The Original Requirement does not identify the provider-independent concepts, contracts, or interfaces through which Crucible expresses common deployment capabilities
-  * The Original Requirement does not identify the boundary between provider-independent Crucible behavior and provider-specific implementation behavior
-  * The Original Requirement does not identify the minimum number of Deployment Platforms required to demonstrate cross-platform deployment
-  * The Original Requirement does not identify whether the same [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible_description|Crucible Description]] applies across the target Deployment Platforms
-  * The Original Requirement does not identify whether the same [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] applies across the target Deployment Platforms
-  * The Original Requirement does not identify the permitted scope of provider-specific variation
-  * The Original Requirement does not provide independently identifiable statements for verification and traceability
-[[dido:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism|Cloud Agnosticism]] limits dependence on the proprietary interfaces, services, data formats, software development kits, and operational mechanisms of a particular Cloud Provider. A cloud-agnostic architecture expresses common capabilities through provider-independent concepts, contracts, and interfaces while provider-specific implementations translate those capabilities into provider-specific mechanisms. :contentReference[oaicite:0]{index=0}
+[[dido:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism|Cloud Agnosticism]] limits dependence on the proprietary interfaces, services, data formats, software development kits, and operational mechanisms of a particular Cloud Provider.
-The previously normalized Statement also combined cross-platform deployment, common Crucible Description use, common Infrastructure Baseline use, and limitation of provider-specific dependencies within one compound normative statement. Those obligations can pass or fail independently.
+A cloud-agnostic architecture expresses common deployment capabilities through provider-independent concepts, contracts, and interfaces. Provider-specific implementations translate those capabilities into mechanisms supported by each target Deployment Platform.
-The Original Requirement therefore requires decomposition into independently identifiable normative requirements.
+The Original Requirement does not identify:
-The decomposition preserves ''MO-003'' as the stable parent requirement identifier. Each replacement requirement receives a lettered identifier and a separate requirement page.
+  * The Deployment Platforms across which Crucible must operate
+  * The minimum number of Deployment Platforms required to demonstrate Cloud Agnosticism
+  * The deployable subject
+  * The provider-independent deployment information
+  * The provider-specific dependencies that Crucible must limit
+  * The boundary between provider-independent Crucible behavior and provider-specific implementation behavior
+  * Whether the same [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible_description|Crucible Description]] applies across the target Deployment Platforms
+  * Whether the same [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] applies across the target Deployment Platforms
+  * The permitted scope of provider-specific variation
+The Original Requirement therefore requires:
+  * Replacement of **the system** with the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]
+  * Replacement of **provide** with observable Crucible behavior
+  * Identification of the target Deployment Platforms
+  * Identification of the provider-independent deployment information
+  * Identification of the proprietary dependencies that Crucible must limit
+  * Definition of the boundary between provider-independent behavior and provider-specific implementation
+  * Definition of the permitted provider-specific variation
+  * Separation of the independently testable cloud-agnostic deployment outcomes
+  * Confirmation that the derived requirements collectively preserve the complete intent of MO-003
+The decomposition preserves ''MO-003'' as the stable parent requirement identifier. Each proposed replacement requirement receives a lettered identifier and a separate leaf requirement page.
 ===== Proposed Statements =====
-The Original Requirement is replaced by the following independently identifiable normative requirements:
+The Original Requirement is decomposed into the following proposed replacement requirements:
 {{indexmenu>dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-003#1|js navbar nocookie maxjs#1 id#crucible_mo_003_requirements_nav}}
+===== Requirement Status =====
+<todo>Review and approve the proposed decomposition of MO-003 into independently testable cloud-agnostic deployment requirements.</todo>
+<todo>Determine whether MO-003a through MO-003d collectively supersede MO-003.</todo>
+<todo>If MO-003a through MO-003d are accepted as the complete replacement for MO-003, mark MO-003 as superseded and preserve this page as the parent Traceability record.</todo>
+----
+===== Issues =====
+The following unresolved issues affect the decomposition of MO-003:
+<todo>Identify the target Deployment Platforms and the minimum number of platforms required to demonstrate Cloud Agnosticism.</todo>
+<todo>Identify the deployable subject and the deployment outcome required on each target Deployment Platform.</todo>
+<todo>Define the provider-independent deployment information that Crucible uses across target Deployment Platforms.</todo>
+<todo>Determine whether the same Crucible Description must apply across all target Deployment Platforms.</todo>
+<todo>Determine whether the same Infrastructure Baseline must apply across all target Deployment Platforms.</todo>
+<todo>Identify the proprietary interfaces, services, data formats, software development kits, and operational mechanisms from which Crucible must limit dependence.</todo>
+<todo>Define the permitted scope of provider-specific implementation behavior and variation.</todo>
+<todo>Determine whether MO-003a through MO-003d provide complete coverage of the approved intent of MO-003.</todo>
+----
+===== Notes for Editors =====
+This page should retain the stable parent requirement identifier ''MO-003''.
+This page is a non-leaf requirement page and retains a trailing '':start'' in its namespace.
+The child requirements are leaf requirement pages and omit a trailing '':start'' from their namespaces.
+The explicit child-page links should remain while the proposed decomposition is being developed. After the child pages have been created and finalized, the explicit links may be removed because the ''indexmenu'' displays the child requirement pages contained within the MO-003 namespace.
+This page preserves:
+  * The Original Requirement
+  * The assessment of the Original Requirement
+  * The reason for decomposition
+  * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] to the proposed replacement requirements
+  * The unresolved cross-cutting issues affecting the decomposition
+  * The supersession decision
+The derived requirements should distinguish provider-independent Crucible behavior from provider-specific implementation behavior.
+Cloud Agnosticism does not prohibit every provider-specific mechanism. Provider-specific implementations may translate provider-independent deployment information into mechanisms supported by a target Deployment Platform, provided that those mechanisms do not become required elements of the provider-independent Crucible model.
+The Original Requirement should not be marked as superseded until the requirement owner:
+  * Approves the proposed decomposition
+  * Approves the child requirements
+  * Identifies the target Deployment Platforms
+  * Defines the permitted provider-specific variation
+  * Confirms that the child requirements collectively preserve the complete approved intent of MO-003
+  * Confirms that no additional child requirements are required
+After supersession, this page should remain as the parent Traceability record and should continue to preserve the Original Requirement and its assessment.
+Material changes to the decomposition should update the child requirements, Requirement Status, Issues, and Traceability records.
 ----