dido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-01-configuration-management:fr-cfg-003

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:03-functional-requirements:03-01-configuration-management:fr-cfg-003 [2026/07/16 08:34] – nick_didodido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-01-configuration-management:fr-cfg-003 [2026/07/30 05:14] (current) – nick_dido
Line 5: Line 5:
 ===== Statement ===== ===== Statement =====
  
-[[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] SHALL apply the same [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprint]] to two or more [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]] without modifying the reusable blueprint content.+[[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] SHALL apply the same [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprint]] to two or more [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]].
  
-===== Source Statement =====+===== Derived From =====
  
-> The system SHALL support reusable infrastructure blueprints.+This requirement derives from:
  
-===== Source =====+  * Crucible System Requirements Specification, Version 1.1 Draft, Functional Requirements, Configuration Management, FR-CFG-003
  
-Crucible System Requirements Specification, Version 1.1 Draft, Functional Requirements, Configuration Management, FR-CFG-003.+The Original Requirement states:
  
-===== Assessment =====+> //The system SHALL support reusable infrastructure blueprints.//[[dido:02-crusible:99-annexes:annex-b:cr-001|[C1]]]
  
-The source statement expresses the approved functional intent but does not provide all information required for deterministic verification.+FR-CFG-003:
  
-The following Specification Discipline and Authoring findings apply: +  * Replaces **The system** with the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] 
- +  * Replaces the weak phrase **support reusable** with the observable behavior **apply** 
-  * **The system** does not use the defined system name +  * Defines reuse as applying the same Infrastructure Blueprint to two or more Infrastructure Environments
-  * **Support** is a weak verb that does not identify the behavior [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] performs +
-  * **Infrastructure blueprint** does not identify the blueprint content, representation, approval state, or relationship to other configuration artifacts +
-  * **Reusable** does not identify the minimum number of applications required to demonstrate reuse +
-  * The source statement does not distinguish reuse of an approved blueprint from modification of that blueprint +
-  * The source statement does not identify whether environment-specific values may vary between applications +
-  * The source statement does not identify how each resulting environment records the blueprint identifier and revision used +
-  * The source statement does not define the acceptance criteria used to determine whether each application produced an acceptable environment +
- +
-The normalized Statement replaces the weak verb with **apply**, defines reuse as application to two or more Infrastructure Environments, and prohibits reuse from modifying the approved blueprint content. +
- +
-Environment-specific parameters, blueprint identification, revision control, validation, approval, and traceability require evaluation against the remaining Configuration Management requirements before allocation to this requirement or creation of derived requirements.+
  
 ===== Rationale ===== ===== Rationale =====
  
-An [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprint]] captures reusable infrastructure intent for a defined class of environments. +An [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprint]] provides a reusable definition of infrastructure structure, relationships, configurable properties, and constraints.
- +
-Without a reusable blueprint, an organization may recreate similar configurations for each deployment. Repeated recreation increases engineering effort, produces inconsistent configurations, and weakens [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducibility]] and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]]. +
- +
-[[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] applies an approved Infrastructure Blueprint to multiple Infrastructure Environments while preserving the approved blueprint content. +
- +
-Reuse allows each environment to share common infrastructure intent while separately recording environment-specific inputs, parameters, and resulting state. +
- +
-This approach preserves the distinction between: +
- +
-  * Reusing an approved Infrastructure Blueprint +
-  * Applying environment-specific parameters +
-  * Creating a new blueprint revision +
-  * Recording environment-specific state +
-  * Recording the result of each blueprint application+
  
-Reusable Infrastructure Blueprints support:+Applying the same Infrastructure Blueprint to multiple [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]] reduces duplicated definitions and promotes consistent infrastructure structure.
  
-  * Consistent environment creation +Environment-specific values, parameters, or controlled overrides allow each Infrastructure Environment to use the reusable Infrastructure Blueprint within its own operational context.
-  * Reduced configuration duplication +
-  * Reduced engineering effort +
-  * Controlled variation +
-  * Configuration comparison +
-  * [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducibility]] +
-  * [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] +
-  * [[dido:99_annexes:annex-b-terms-and-definitions:a:auditability|Auditability]] +
-  * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]]+
  
 ===== Applies To ===== ===== Applies To =====
Line 71: Line 38:
   * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprints]]   * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprints]]
   * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]]   * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]]
-  * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_configuration|Infrastructure Configurations]] 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:d:declarative_configuration|Declarative Configuration]] 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baselines]] 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baselines]] 
-  * Blueprint reuse 
-  * Blueprint application 
-  * Approved blueprint content 
-  * Environment-specific parameters 
-  * Environment-specific state 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration_management|Configuration Management]] 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:a:auditability|Auditability]] 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducibility]] 
-  * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] 
  
 ===== Verification ===== ===== Verification =====
  
-  - Verification SHALL confirm that the tested [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprint]] has an approved content state +Verification confirms that:
-  - Verification SHALL confirm that [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] applies the same approved Infrastructure Blueprint to at least two [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]] +
-  - Verification SHALL confirm that each tested application uses equivalent approved blueprint content +
-  - Verification SHALL confirm that applying the Infrastructure Blueprint does not modify the approved blueprint content +
-  - Verification SHALL confirm that environment-specific inputs and parameters remain distinguishable from the approved blueprint content +
-  - Verification SHALL confirm that each resulting Infrastructure Environment satisfies the applicable acceptance criteria +
-  - Verification SHALL confirm that each environment record identifies the Infrastructure Blueprint used +
-  - Verification SHALL confirm that each application record preserves the applicable [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]]+
  
-Verification may include: +  - A tested Infrastructure Blueprint is selected for reuse 
- +  - [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] applies the same tested Infrastructure Blueprint to at least two Infrastructure Environments 
-  * Blueprint content inspection +  - Each application identifies the Infrastructure Environment to which the Infrastructure Blueprint applies 
-  * Blueprint approval inspection +  - Each Infrastructure Environment receives the infrastructure definition provided by the tested Infrastructure Blueprint 
-  * Repeated blueprint application tests +  - Environment-specific values, parameters, or controlled overrides do not prevent identification of the common Infrastructure Blueprint
-  * Multi-environment deployment tests +
-  * Blueprint content comparison +
-  * Environment-specific parameter inspection +
-  * Resulting environment comparison +
-  * Acceptance criteria evaluation +
-  * Application record inspection +
-  * End-to-end [[dido:99_annexes:annex-b-terms-and-definitions:c:ci_cd_pipeline|CI/CD Pipeline]] tests +
- +
-The verification record SHALL identify: +
- +
-  - The tested Infrastructure Blueprint +
-  - The approved blueprint content +
-  - The blueprint approval state +
-  - The tested Infrastructure Environments +
-  - The environment-specific inputs +
-  - The environment-specific parameters +
-  - The blueprint content comparison result +
-  - The applicable acceptance criteria +
-  - The observed environment results +
-  - The applicable [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] +
-  - The generated [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] +
- +
-===== Outgoing Traceability ===== +
- +
-This requirement refines: +
- +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-001|MO-001 — Repeatable, Compliant, and Secure Infrastructure Environments]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-002|MO-002 — Reduced Platform Deployment Timelines]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-003|MO-003 — Platform Independent Deployment]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-005|MO-005 — Reusable and Version-Controlled Infrastructure]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-006|MO-006 — Infrastructure Lifecycle Management]] +
- +
-This requirement operates within the conditions established by: +
- +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001|OR-001 — Operational Roles]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-002|OR-002 — Deployment Environments]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-003|OR-003 — Classified and Unclassified Environments]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-004|OR-004 — Concurrent Environment Management]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-005|OR-005 — Distributed Environment Management]] +
- +
-This requirement also relates to: +
- +
-  * [[dido:02-crusible:05-descriptions-composition-and-baselines:start|5. Descriptions, Composition, and Baselines]] +
-  * [[dido:02-crusible:07-infrastructure-and-deployment:start|7. Infrastructure and Deployment]] +
-  * [[dido:02-crusible:10-reproducibility-provenance-and-traceability:start|10. Reproducibility, Provenance, and Traceability]]+
  
 ===== Referenced By ===== ===== Referenced By =====
  
-The wiki Backlinks function provides the current list of pages that reference ''FR-CFG-003''.+The following pages reference this requirement:
  
-Incoming traceability should be derived dynamically from backlinks rather than maintained as a duplicate manual list. +{{backlinks>.#dido:02-crusible}}
- +
-Backlinks identify incoming references but do not define the semantics of each relationship. Referencing pages should identify whether the relationship represents realization, refinement, verification, dependency, or another defined traceability relationship. +
- +
-===== ConOps Relationship ===== +
- +
-The Crucible Concept of Operations describes the composition and reuse of versioned infrastructure content within a [[dido:99_annexes:annex-b-terms-and-definitions:c:ci_cd_pipeline|CI/CD Pipeline]] workspace. +
- +
-The Phase 1 workflow may use a reusable Infrastructure Blueprint to: +
- +
-  * Identify common infrastructure intent +
-  * Select applicable [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baselines]] +
-  * Supply common deployment configuration +
-  * Apply environment-specific parameters +
-  * Perform [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]] +
-  * Record the blueprint associated with each environment +
-  * Preserve deployment results and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] +
- +
-This workflow permits multiple environments to use the same approved blueprint while keeping environment-specific inputs and resulting state separate from the blueprint content. +
- +
-===== Delivery Phase ===== +
- +
-Phase 1 and subsequent phases+
  
 ===== Implementation Status ===== ===== Implementation Status =====
  
-Not Assessed +Implemented and Verified
- +
-Implementation status requires verification that [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] applies the same approved Infrastructure Blueprint to two or more Infrastructure Environments without modifying the approved blueprint content.+
  
 ===== Requirement Status ===== ===== Requirement Status =====
  
-Draft+<todo>Review and approve FR-CFG-003 as a leaf requirement.</todo>
  
-The source System Requirements Specification identifies Version 1.1 as a draft.+---- 
 +===== Issues ===== 
 + 
 +<todo>Determine whether reusable Infrastructure Blueprints permit controlled overrides and identify the rules governing those overrides.</todo>
  
 ---- ----
 ===== Notes for Editors ===== ===== Notes for Editors =====
  
-This requirement page should retain the stable requirement identifier ''FR-CFG-003''.+This requirement page retains the stable requirement identifier ''FR-CFG-003''.
  
-Changes to the Statement SHALL preserve the approved intent of the source requirement.+This page is a leaf requirement page and omits a trailing '':start'' from its namespace.
  
-Material changes should receive review and should update the related outbound traceability, verification criteria, blueprint records, acceptance criteria, and source records.+The Statement preserves the approved source intent by requiring reuse of the same Infrastructure Blueprint across two or more Infrastructure Environments.
  
-The Source Statement should preserve the original wording from the controlling System Requirements Specification. +Do not add blueprint approval, validation, deployment, acceptance, revision-history, or traceability obligations to the Statement unless the controlling requirement changes through an approved requirements process.
- +
-The Configuration Management completeness review should evaluate whether blueprint identification, revision control, validation, approval, environment-specific parameterization, and environment traceability are allocated to ''FR-CFG-004'' or ''FR-CFG-005'' or require derived requirements. +
- +
-Incoming traceability should use the wiki Backlinks function rather than a manually maintained list.+
  
 To reference this requirement Statement from another wiki page, insert: To reference this requirement Statement from another wiki page, insert:
Line 208: Line 84:
 {{section>dido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-01-configuration-management:fr-cfg-003#Statement&noheader&nofooter&noeditbtn}} {{section>dido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-01-configuration-management:fr-cfg-003#Statement&noheader&nofooter&noeditbtn}}
 </code> </code>
- 
-Do not rename this page after an external citation unless a redirect or move plan is in place. 
  
 ---- ----
  • dido/02-crusible/99-annexes/annex-c-requirements/03-functional-requirements/03-01-configuration-management/fr-cfg-003.1784216068.txt.gz
  • Last modified: 2026/07/16 08:34
  • by nick_dido