dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-002:start

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-002:start [2026/07/20 08:12] – removed - external edit (Unknown date) 127.0.0.1dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-002:start [2026/07/22 09:57] (current) – nick_dido
Line 1: Line 1:
 +====== MO-002 — Reduced Platform Deployment Timelines ======
  
 +[[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:start|Go to Mission Objectives]]
 +
 +===== Original Requirement =====
 +
 +> //Crucible SHALL reduce platform deployment timelines from months to days or hours through automation.//[[dido:02-crusible:99-annexes:annex-b:cr-002|[C2]]]
 +
 +===== Assessment of Original Requirement =====
 +
 +The Original Requirement preserves the approved mission objective but does not express independently testable normative statements.
 +
 +The following Specification Discipline and Authoring findings apply:
 +
 +  * **Reduce** requires comparison with an identified and approved baseline
 +  * **Platform deployment timelines** does not identify the measured [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_deployment|Platform Deployment]] activity
 +  * **From months** does not identify a specific baseline duration
 +  * **To days or hours** does not establish a single measurable duration threshold
 +  * **Through automation** prescribes an implementation approach rather than stating the required outcome
 +
 +The Original Requirement combines:
 +
 +  * A maximum permitted [[dido:99_annexes:annex-b-terms-and-definitions:d:deployment_duration|Deployment Duration]]
 +  * A reduction relative to a deployment-duration baseline
 +  * Automation as an implementation approach
 +
 +The maximum permitted duration and the reduction relative to a baseline can be evaluated independently.
 +
 +The Original Requirement does not identify:
 +
 +  * The Platform Deployment activity being measured
 +  * The start condition
 +  * The completion condition
 +  * The deployment-duration baseline
 +  * The target Deployment Duration
 +  * The required amount of reduction
 +  * The measurement conditions
 +  * The treatment of failed, interrupted, incomplete, or repeated deployments
 +
 +The Original Requirement therefore requires:
 +
 +  * Identification of the measured Platform Deployment activity
 +  * Identification of the start and completion conditions
 +  * Establishment of a measurable target Deployment Duration
 +  * Establishment of an approved deployment-duration baseline
 +  * Establishment of the required reduction relative to that baseline
 +  * Separation of the absolute duration objective from the relative reduction objective
 +  * Determination of whether automation represents a required implementation constraint or only explanatory source language
 +  * Confirmation that the derived requirements collectively preserve the complete intent of MO-002
 +
 +The decomposition preserves ''MO-002'' 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 decomposed into the following proposed replacement requirements:
 +
 +{{indexmenu>dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-002#1|js navbar nocookie maxjs#1 id#crucible_mo_002_requirements_nav}}
 +
 +===== Requirement Status =====
 +
 +<todo>Review and approve the proposed decomposition of MO-002 into an absolute Platform Deployment Duration requirement and a relative Platform Deployment timeline-reduction requirement.</todo>
 +
 +<todo>Determine whether automation is a required implementation constraint, an architectural decision, or explanatory source language that should not appear in the derived requirements.</todo>
 +
 +<todo>Determine whether MO-002a and MO-002b collectively supersede MO-002.</todo>
 +
 +<todo>If MO-002a and MO-002b are accepted as the complete replacement for MO-002, mark MO-002 as superseded and preserve this page as the parent Traceability record.</todo>
 +
 +----
 +===== Issues =====
 +
 +The following unresolved issues affect the decomposition of MO-002:
 +
 +<todo>Identify the Platform Deployment activity measured by MO-002.</todo>
 +
 +<todo>Define the start condition and completion condition used to calculate Platform Deployment Duration.</todo>
 +
 +<todo>Define the maximum permitted Platform Deployment Duration represented by days or hours.</todo>
 +
 +<todo>Identify the approved deployment-duration baseline represented by months.</todo>
 +
 +<todo>Define the required reduction relative to the approved deployment-duration baseline.</todo>
 +
 +<todo>Define how failed, interrupted, incomplete, or repeated Platform Deployments affect duration measurement.</todo>
 +
 +<todo>Determine whether MO-002a and MO-002b provide complete coverage of the approved intent of MO-002.</todo>
 +
 +----
 +===== Notes for Editors =====
 +
 +This page should retain the stable parent requirement identifier ''MO-002''.
 +
 +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-002 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 separate:
 +
 +  * The maximum permitted Platform Deployment Duration
 +  * The required reduction relative to an approved deployment-duration baseline
 +
 +The phrase **through automation** should not be converted into a normative implementation constraint unless the requirement owner confirms that automation forms part of the approved requirement intent.
 +
 +The Original Requirement should not be marked as superseded until the requirement owner:
 +
 +  * Approves the proposed decomposition
 +  * Approves the child requirements
 +  * Confirms the treatment of **through automation**
 +  * Confirms that the child requirements collectively preserve the complete approved intent of MO-002
 +  * 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.
 +
 +----
 +
 +<WRAP centeralign>
 +© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
 +</WRAP>