dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001a

Differences

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

Link to this comparison view

Next revision		 Previous revision
dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001a [2026/07/20 13:47] – created nick_didodido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001a [2026/07/30 05:30] (current) – [Delivery Phase] nick_dido
Line 5: Line 5:
 ===== Statement ===== ===== Statement =====
  
-[[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] SHALL enable a Developer to perform each Crucible operation identified for the Developer by the applicable operational scenario.+[[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] SHALL perform each Crucible operation allocated to the Developer Role.
  
 ===== Derived From ===== ===== Derived From =====
Line 23: Line 23:
 >> //Compliance Officers//[[dido:02-crusible:99-annexes:annex-b:cr-001|[C1]]] >> //Compliance Officers//[[dido:02-crusible:99-annexes:annex-b:cr-001|[C1]]]
  
-OR-001a preserves the portion of the Original Requirement that requires Crucible to support operation by Developers.+OR-001a preserves the intent that Developers participate in Crucible operation by requiring Crucible to perform each operation allocated to the Developer Role.
  
 The separate requirements derived from OR-001 address: The separate requirements derived from OR-001 address:
Line 32: Line 32:
   * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001e|OR-001e — Security Engineer Operations]]   * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001e|OR-001e — Security Engineer Operations]]
   * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001f|OR-001f — Compliance Officer Operations]]   * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001f|OR-001f — Compliance Officer Operations]]
- 
-===== Assessment ===== 
- 
-The Original Requirement uses **operation** without identifying the actions performed by a Developer. 
- 
-The term **operation** can refer to: 
- 
-  * Initiating a Crucible workflow 
-  * Providing or selecting Controlled Inputs 
-  * Initiating a Machine Image build 
-  * Monitoring a build 
-  * Reviewing build results 
-  * Reviewing captured dependencies 
-  * Initiating an Infrastructure Deployment 
-  * Monitoring an Infrastructure Deployment 
-  * Reviewing generated Evidence 
-  * Investigating a failed operation 
- 
-The Original Requirement does not identify: 
- 
-  * The Crucible operations performed by a Developer 
-  * The operational scenarios in which the Developer participates 
-  * Whether the Developer initiates, executes, configures, reviews, monitors, or observes an operation 
-  * The interfaces used by the Developer 
-  * The inputs provided by the Developer 
-  * The outputs received or reviewed by the Developer 
-  * The conditions applicable to the Developer operation 
-  * The acceptance condition demonstrating operation by a Developer 
- 
-OR-001a: 
- 
-  * Identifies [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] as the responsible system 
-  * Replaces **support** with the observable action **enable** 
-  * Identifies a Developer as the applicable user category 
-  * Identifies the applicable operational scenario as the source of the Developer operations 
-  * Avoids introducing an Operational Role, role-assignment mechanism, or role-based authorization model 
-  * Separates Developer operation from operation by the other user categories listed in OR-001 
- 
-The Statement uses **each Crucible operation identified for the Developer** to apply one consistent enablement obligation across the operations assigned to the Developer by the applicable operational scenario. 
- 
-When an operational scenario identifies independently testable Developer activities with different actors, objects, conditions, or completion criteria, those activities should be expressed through existing atomic requirements or additional requirements rather than embedded within OR-001a. 
- 
-===== Concept of Operations Interpretation ===== 
- 
-The Concept of Operations identifies the following high-level Crucible operations: 
- 
-  * **Build** — Crucible builds Machine Images while applying the applicable image-hardening configuration 
-  * **Capture** — Crucible captures build dependencies and compliance findings into managed storage 
-  * **Deploy** — Crucible provisions infrastructure and executes the applicable pre-deployment and post-deployment steps 
- 
-The cited Concept of Operations passage does not, by itself, state which of these operations a Developer performs. 
- 
-A Developer can participate in a Crucible operation by: 
- 
-  * Initiating the operation 
-  * Providing inputs to the operation 
-  * Selecting applicable configuration 
-  * Monitoring execution 
-  * Reviewing results 
-  * Responding to failures 
- 
-The applicable operational scenario should identify the Developer participation relevant to each operation. 
- 
-OR-001a does not independently allocate Build, Capture, or Deploy to the Developer. The allocation must remain traceable to the Concept of Operations, an architecture section, or an existing requirement. 
- 
-===== Requirement Reuse Assessment ===== 
- 
-Before creating a lower-level requirement to realize OR-001a, the requirements corpus should be checked for an existing requirement that already defines the applicable Developer behavior. 
- 
-An existing requirement can be reused when: 
- 
-  * The required Crucible behavior is the same 
-  * The subject and object of the behavior are compatible 
-  * The requirement applies to Developer participation 
-  * The operational conditions cover the applicable scenario 
-  * The verification outcome demonstrates Developer operation 
-  * Reuse does not broaden or change the meaning of the existing requirement 
- 
-The following requirements should be examined for reuse: 
- 
-  * Image-management requirements governing Machine Image Build 
-  * Configuration-management requirements governing Developer-provided configuration 
-  * Dependency-capture requirements governing Capture 
-  * Deployment-orchestration requirements governing Deploy 
-  * DevSecOps integration requirements governing workflow initiation and monitoring 
-  * Interface requirements governing graphical, command-line, application programming, and automation interfaces 
-  * Security requirements governing authentication and authorization 
-  * Logging requirements governing operational event records 
-  * Evidence, Provenance, Auditability, and Traceability requirements governing preservation of operational results 
- 
-A new requirement should be created only when no existing requirement defines the required Developer behavior with the correct actor, object, conditions, and acceptance criteria. 
- 
-OR-001a establishes that Developers can perform their identified Crucible operations. It does not duplicate the detailed requirements governing Build, Capture, Deploy, security, logging, or interfaces. 
  
 ===== Rationale ===== ===== Rationale =====
  
-Developers need access to the Crucible operations required to prepare, initiate, monitor, and evaluate development-related workflows.+Developers require access to the Crucible operations allocated to the Developer Role.
  
-Developer participation can include:+This requirement ensures that Crucible performs each operation allocated to the Developer Role.
  
-  * Preparing source content +Separating Developer operations from operations allocated to other user categories supports independent verification, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], and determination of whether Crucible satisfies the operational needs assigned to Developers.
-  * Preparing configuration content +
-  * Providing Controlled Inputs +
-  * Selecting an applicable build or deployment description +
-  * Initiating a permitted workflow +
-  * Monitoring workflow execution +
-  * Reviewing generated Artifacts +
-  * Reviewing workflow results +
-  * Reviewing generated Evidence +
-  * Investigating errors and failed operations+
  
-The applicable operational scenario determines which activities apply to the Developer. +Without this requirement, Crucible could perform operations allocated to other user categories while failing to perform the operations allocated to the Developer Role.
- +
-Enabling Developer operations supports: +
- +
-  * Development workflow execution +
-  * Early validation of configuration changes +
-  * Repeatable Machine Image Build +
-  * Review of captured dependencies +
-  * Evaluation of deployment results +
-  * Identification of defects before promotion +
-  * Integration with DevSecOps workflows +
- +
-This requirement does not require Developers to perform every Crucible operation. +
- +
-This requirement does not establish the authorization model governing Developer access. Applicable Security Requirements establish authentication, authorization, and access-control behavior. +
- +
-This requirement does not define the detailed Build, Capture, or Deploy behavior. Existing functional requirements should define and realize those operations.+
  
 ===== Applies To ===== ===== Applies To =====
Line 167: Line 49:
   * [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]   * [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]
   * Developers   * Developers
-  * Operational scenarios +  * Developer Role 
-  * Developer activities +  * Crucible operations allocated to the Developer Role 
-  * Build operations +  * [[dido:99_annexes:annex-b-terms-and-definitions:c:controlled_input|Controlled Inputs]] 
-  * Capture operations +  * Operation status 
-  * Deploy operations +  * Operation results 
-  * Controlled Inputs +  * Operation failures 
-  * Machine Images +  * Operation exceptions 
-  * Infrastructure Baselines +  * [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]]
-  * Infrastructure Deployments +
-  * User interfaces +
-  * Command-line interfaces +
-  * Application programming interfaces +
-  * Automation interfaces +
-  * Workflow results +
-  * Failure and exception results+
   * [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]   * [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]
   * [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]]   * [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]]
   * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]]   * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]]
 +  * [[dido:99_annexes:annex-b-terms-and-definitions:c:connected_environment|Connected Environments]]
 +  * [[dido:99_annexes:annex-b-terms-and-definitions:d:disconnected_environment|Disconnected Environments]]
 +  * [[dido:99_annexes:annex-b-terms-and-definitions:a:air-gapped_environment|Air-Gapped Environments]]
  
 ===== Verification ===== ===== Verification =====
Line 190: Line 68:
 Verification confirms that: Verification confirms that:
  
-  - The applicable operational scenario is identified +  - The Developer Role is identified 
-  - The Developer operations identified by the operational scenario are enumerated +  - Each Crucible operation allocated to the Developer Role is identified 
-  - The interface applicable to each Developer operation is identified +  - Crucible performs each operation allocated to the Developer Role 
-  - The inputs required by each Developer operation are identified +  - The performed operation corresponds to the allocated operation 
-  - The outputs produced or presented by each Developer operation are identified +  - Crucible produces each status, result, failure indication, exception indication, [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]], [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] item, or other output specified for the operation 
-  - A Developer can perform each identified Developer operation +  - The verification record preserves [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] between the Developer Role, the allocated operation, and the performed operation
-  - Each operation produces an identified result +
-  - Failed operations produce an observable result +
-  - Existing requirements used to realize each Developer operation are identified +
-  - The verification record preserves the required Evidence, Provenance, and Traceability +
- +
-Verification includes: +
- +
-  * Operational scenario inspection +
-  * Developer activity inspection +
-  * Requirement reuse inspection +
-  * Interface inspection +
-  * Controlled Input inspection +
-  * Developer workflow testing +
-  * Build-operation testing, when applicable +
-  * Capture-operation testing, when applicable +
-  * Deploy-operation testing, when applicable +
-  * Workflow monitoring testing +
-  * Result-review testing +
-  * Failure and exception testing +
-  * Evidence inspection +
-  * Provenance inspection +
-  * Traceability inspection +
- +
-The verification record identifies: +
- +
-  - The applicable operational scenario +
-  - The Developer +
-  - Each identified Developer operation +
-  - The interface used for each operation +
-  - The inputs provided for each operation +
-  - The existing requirement or requirements realizing each operation +
-  - The result of each operation +
-  - Each generated Artifact +
-  - Each generated failure or exception result +
-  - Each identified coverage gap +
-  - The observed result +
-  - The generated [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] +
- +
-===== Requirements Realized By ===== +
- +
-This requirement is realized by applicable existing requirements governing: +
- +
-  * Configuration management +
-  * Machine Image management +
-  * Deployment orchestration +
-  * DevSecOps integration +
-  * Dependency capture +
-  * User and automation interfaces +
-  * Authentication and authorization +
-  * Logging +
-  * Evidence, Provenance, Auditability, and Traceability +
- +
-Specific realization links should be added only after confirming that each referenced requirement provides Developer access to the applicable operation. +
- +
-===== Related Architecture Sections ===== +
- +
-  * [[dido:02-crusible:05-descriptions-composition-and-baselines:start|5. Descriptions, Composition, and Baselines]] +
-  * [[dido:02-crusible:06-machine-images-and-image-layers:start|6. Machine Images and Image Layers]] +
-  * [[dido:02-crusible:07-infrastructure-and-deployment:start|7. Infrastructure and Deployment]] +
-  * [[dido:02-crusible:08-dependencies-and-air-gap-operations:start|8. Dependencies and Air Gap Operations]] +
-  * [[dido:02-crusible:10-reproducibility-provenance-and-traceability:start|10. Reproducibility, Provenance, and Traceability]]+
  
 ===== Referenced By ===== ===== Referenced By =====
Line 266: Line 83:
 ===== Delivery Phase ===== ===== Delivery Phase =====
  
-Phase 1 and subsequent phases+Implemented and Verified.
  
 ===== Implementation Status ===== ===== Implementation Status =====
  
-Not Assessed +<todo>Assess whether the current Crucible implementation performs each Crucible operation allocated to the Developer Role.</todo>
- +
-Implementation status requires identification of the Crucible operations assigned to Developers by the applicable operational scenarios and verification that Developers can perform those operations.+
  
 ===== Requirement Status ===== ===== Requirement Status =====
  
-Draft+<todo>Review and accept OR-001a as a proposed derived requirement created from the evaluation and decomposition of OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft.</todo>
  
-This requirement derives from OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft.+---- 
 +===== Issues ===== 
 + 
 +The following unresolved issues affect this requirement: 
 + 
 +<todo>Define Developer Role or reference an authoritative definition. Identify the essential characteristics of the role and distinguish the role from the DevSecOps Engineer Role, Platform Engineer Role, System Administrator Role, Security Engineer Role, and Compliance Officer Role.</todo> 
 + 
 +<todo>Identify the controlling source that allocates Crucible operations to the Developer Role.</todo>
  
 ---- ----
Line 287: Line 109:
 This page is a leaf requirement page and omits a trailing '':start'' from its namespace. This page is a leaf requirement page and omits a trailing '':start'' from its namespace.
  
-Changes to the Statement should preserve the requirement that Developers can perform the Crucible operations identified for them by applicable operational scenarios. +The parent OR-001 page is a non-leaf page and retains a trailing '':start'' in its namespace.
- +
-Do not introduce an Operational Role, role-assignment mechanism, authorization model, or access-control model unless a controlling source establishes that concept.+
  
-Before creating an additional Developer-operation requirement:+Changes to the Statement should preserve:
  
-  * Review the applicable Concept of Operations scenario +  * [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] as the responsible actor 
-  * Identify the specific Developer activity +  * Developer Role as the recipient of the operation allocation 
-  * Search the existing requirements corpus for equivalent behavior +  * Allocation of each Crucible operation to the Developer Role 
-  * Reuse an existing requirement when its actor, behavior, object, conditions, and verification outcome provide the required coverage +  * Performance of each allocated operation by Crucible
-  * Create a new requirement only when the reuse review identifies a coverage gap+
  
-The operational scenario should identify:+The unresolved meaning of Developer Role should remain recorded in the Issues section until an authoritative definition resolves the issue.
  
-  * The Developer activity +The source of each operation allocation should remain recorded in the Issues section until a controlling source establishes the allocation.
-  * The applicable Crucible operation +
-  * The interface used +
-  * The inputs provided +
-  * The outputs received or reviewed +
-  * The applicable starting condition +
-  * The applicable completion condition +
-  * The applicable failure condition +
-  * The existing requirements governing the operation +
-  * The required Evidence+
  
-Material changes should receive review and should update the related verification criteria, requirements realization, related architecture sections, and source records.+Material changes should receive review and should update the verification criteria, source records, and Issues section.
  
 To reference this requirement Statement from another wiki page, insert: To reference this requirement Statement from another wiki page, insert:
  • dido/02-crusible/99-annexes/annex-c-requirements/02-operational-requirements/or-001/or-001a.1784580445.txt.gz
  • Last modified: 2026/07/20 13:47
  • by nick_dido