dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001: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:02-operational-requirements:or-001:start [2026/07/21 09:57] – ↷ Page moved and renamed from dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001 to dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:start nick_didodido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:start [2026/07/22 08:49] (current) – nick_dido
Line 15: Line 15:
 ===== Assessment of Original Requirement ===== ===== Assessment of Original Requirement =====
  
-The Original Requirement preserves the approved intent that the identified categories of users participate in Crucible operation, but it does not express independently testable normative statements.+The Original Requirement preserves the approved intent that the identified categories participate in Crucible operation, but it does not express independently testable normative statements.
  
 The following Specification Discipline and Authoring findings apply: The following Specification Discipline and Authoring findings apply:
Line 21: Line 21:
   * **The system** does not use the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]   * **The system** does not use the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]
   * **Support** is a weak verb that does not identify an observable Crucible behavior   * **Support** is a weak verb that does not identify an observable Crucible behavior
-  * **Operation** is ambiguous because it does not identify the actions performed by the listed user categories +  * **Operation** does not identify the Crucible operations associated with the listed categories 
-  * **Operation by** does not distinguish whether a user category requests, initiates, configures, administers, executes, approves, reviews, monitors, observes, or responds to a Crucible activity +  * **Operation by** does not identify the relationship between each listed category and each Crucible operation
-  * The Original Requirement does not identify which Crucible operations apply to each listed user category +
-  * The Original Requirement does not identify whether every listed user category participates in the same operations +
-  * The Original Requirement does not identify the interfaces through which each listed user category interacts with Crucible +
-  * The Original Requirement does not identify the inputs provided by each listed user category +
-  * The Original Requirement does not identify the outputs received or reviewed by each listed user category +
-  * The Original Requirement does not identify an acceptance condition for operation by each listed user category +
-  * The Original Requirement combines six independently testable user categories within one normative statement +
-  * Crucible can support operation by one listed user category while failing to support operation by another +
-  * The Original Requirement does not provide separate requirement identifiers for verification and traceability of each listed user category+
  
-The word **operation** is grammatically valid as a mass noun describing the general act of operating Crucible. For requirements purposes, however, the term does not identify an observable action.+The word **operation** is grammatically valid as a mass noun describing the general act of operating Crucible. For requirements purposes, however, the word does not identify an observable Crucible behavior.
  
-Changing **operation** to **operations** would indicate that multiple actions exist, but pluralization alone would not identify those actions.+Changing **operation** to **operations** would indicate that multiple actions exist, but pluralization alone would not identify those actions or associate them with the listed categories.
  
-The Original Requirement identifies the following categories of users:+The Original Requirement identifies:
  
   * Developers   * Developers
Line 46: Line 37:
   * Compliance Officers   * Compliance Officers
  
-The Original Requirement does not classify these user categories as Operational Roles and does not require:+The decomposition treats these categories as proposed Crucible roles so that Crucible operations can be allocated and verified separately for each role.
  
-  * A particular role model +The Original Requirement does not define these roles or identify the controlling source that allocates Crucible operations to them.
-  * A role-assignment mechanism +
-  * A role-based authorization model +
-  * A particular access-control model +
-  * Allocation of permissions through roles +
-  * Multiple-role assignment +
-  * Role-assignment removal +
-  * Recording of an authorizing role +
- +
-These concepts should not be introduced as derived requirements unless the Concept of Operations, architecture, security model, or another controlling source establishes them.+
  
 The Original Requirement therefore requires: The Original Requirement therefore requires:
  
-  * Clarification of the intended meaning of **operation** +  * Replacement of **the system** with the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] 
-  * Identification of the Crucible operations applicable to each listed user category +  * Replacement of **support** with an observable Crucible behavior 
-  * Separation of the six independently testable user categories +  * Classification or definition of each listed category 
-  * Reuse of existing requirements wherever those requirements already define the applicable operations+  * Identification of the Crucible operations allocated to each proposed role 
 +  * Separation of the six independently testable roles 
 +  * Confirmation that the derived requirements collectively preserve the complete intent of OR-001
  
-The decomposition preserves ''OR-001'' as the stable parent requirement identifier. Each replacement requirement receives a lettered identifier and a separate requirement page.+The decomposition preserves ''OR-001'' as the stable parent requirement identifier. Each proposed replacement requirement receives a lettered identifier and a separate leaf requirement page.
  
-===== ConOps Relationship =====+===== Proposed Statements =====
  
-The [[dido:02-crusible:99-annexes:annex-b:cr-002|Crucible Concept of Operations [C2]]] provides operational context for interpreting the ambiguous word **operation** in the Original Requirement.+The Original Requirement is decomposed into the following proposed replacement requirements:
  
-The Concept of Operations identifies the following high-level Crucible operations under **Build, Capture, Deploy**:+{{indexmenu>dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001#1|js navbar nocookie maxjs#1 id#crucible_or_001_requirements_nav}}
  
-  * **Build** — Crucible builds Machine Images while applying the applicable image-hardening configuration +===== Requirement Status =====
-  * **Capture** — Crucible captures dependencies and compliance findings into managed storage +
-  * **Deploy** — Crucible provisions infrastructure and executes the applicable pre-deployment and post-deployment steps+
  
-The Concept of Operations also addresses:+<todo>Review and approve the classification of Developer, DevSecOps Engineer, Platform Engineer, System Administrator, Security Engineer, and Compliance Officer as Crucible roles.</todo>
  
-  * Phase 1 command-line operation +<todo>Determine whether OR-001a through OR-001f collectively supersede OR-001.</todo>
-  * CI/CD pipeline integration +
-  * Image-layer baseline composition +
-  * Infrastructure baseline composition +
-  * Machine Image construction +
-  * Dependency capture +
-  * Compliance-finding capture +
-  * Infrastructure deployment +
-  * Connected-to-disconnected transfer +
-  * Offline package-repository population +
-  * Compliance Evidence generation +
-  * Phase 2 web management +
-  * Strategic native execution+
  
-The Concept of Operations therefore supports interpreting **operation** as participation in one or more identifiable Crucible operations rather than as an undefined general capability.+<todo>If OR-001a through OR-001f are accepted as the complete replacement for OR-001, mark OR-001 as superseded and preserve this page as the parent Traceability record.</todo>
  
-The cited ConOps description assigns execution of Build, Capture, and Deploy to Crucible. It does not identify how each listed user category participates in those operations.+---- 
 +===== Issues =====
  
-For example, **operation by** a listed user category could mean that Crucible:+The following unresolved issues affect the decomposition of OR-001:
  
-  * Accepts a request to perform an operation from the user +<todo>Confirm that Developer, DevSecOps Engineer, Platform Engineer, System Administrator, Security Engineer, and Compliance Officer identify Crucible roles rather than job titles, organizational functions, user categories, or another kind of actor.</todo>
-  * Accepts [[dido:99_annexes:annex-b-terms-and-definitions:c:controlled_input|Controlled Inputs]] from the user +
-  * Initiates an operation in response to a user request +
-  * Presents operation status to the user +
-  * Presents the result of a completed operation to the user +
-  * Presents captured dependencies to the user +
-  * Presents compliance findings to the user +
-  * Presents generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] or [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] to the user +
-  * Accepts a decision, approval, disposition, or other response from the user+
  
-These examples are derived interpretations. Neither the Original Requirement[[dido:02-crusible:99-annexes:annex-b:cr-001|[C1]]] nor the cited Concept of Operations[[dido:02-crusible:99-annexes:annex-b:cr-002|[C2]]] expressly assigns these interactions to a particular listed user category.+<todo>Define each proposed Crucible role or reference an authoritative definition.</todo>
  
-The requirement owner should clarify:+<todo>Identify the controlling source that allocates Crucible operations to each proposed role.</todo>
  
-  * Whether **operation** means participation in Build, Capture, and Deploy +<todo>Determine whether OR-001a through OR-001f provide complete coverage of the approved intent of OR-001.</todo>
-  * Whether additional Crucible operations identified elsewhere in the Concept of Operations apply +
-  * Which Crucible operations apply to each listed user category +
-  * Whether each user category requests, initiates, configures, administers, executes, approves, reviews, monitors, observes, or responds to each applicable operation +
-  * Which interfaces support each user interaction +
-  * Which inputs each user category provides +
-  * Which outputs each user category receives or reviews +
-  * Which existing requirements already define each interaction +
-  * Whether any uncovered interaction requires a new normative requirement+
  
-Until this clarification occurs, the child requirements derived from OR-001 assume that **Crucible operations** include Build, Capture, and Deploy as described by the Concept of Operations.+---- 
 +===== Notes for Editors =====
  
-This assumption:+This page should retain the stable parent requirement identifier ''OR-001''.
  
-  * Does not establish that every operation applies to every listed user category +This page is a non-leaf requirement page and retains a trailing '':start'' in its namespace.
-  * Does not establish how a listed user category participates in an operation +
-  * Does not allocate permissions or authorizations +
-  * Does not replace the need to identify the applicable existing requirements +
-  * Remains subject to confirmation by the requirement owner+
  
-The Concept of Operations contextualizes the System Requirements Specification but does not override an approved requirement. Where the Concept of Operations and the System Requirements Specification conflict, the System Requirements Specification controls.+The child requirements are leaf requirement pages and omit a trailing '':start'' from their namespaces.
  
-===== Proposed Statements =====+This page preserves:
  
-The Original Requirement requires separate treatment of the following independently testable user categories:+  * The Original Requirement 
 +  * The assessment of the Original Requirement 
 +  * The reason for decomposition 
 +  * Traceability to the proposed replacement requirements 
 +  * The unresolved cross-cutting issues affecting the decomposition 
 +  * The supersession decision
  
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001a|OR-001a — Developer Operations]] +The child requirements introduce proposed role names only to provide a precise allocation target for Crucible operations. The proposed role names do not establish:
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001b|OR-001b — DevSecOps Engineer Operations]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001c|OR-001c — Platform Engineer Operations]] +
-  * [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001:or-001d|OR-001d — System Administrator 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]]+
  
-Each child requirement:+  * A role-assignment mechanism 
 +  * A role-based authorization model 
 +  * An access-control model 
 +  * Permission allocation 
 +  * Multiple-role assignment 
 +  * Role-assignment removal 
 +  * Recording of an authorizing role
  
-  * Assumes that Crucible operations include Build, Capture, and Deploy as described by [[dido:02-crusible:99-annexes:annex-b:cr-002:start|[C2]]] +The Original Requirement should not be marked as superseded until the requirement owner:
-  * Identifies that the assumption remains subject to confirmation +
-  * Does not assume that every operation applies to the applicable user category +
-  * Identifies candidate interactions requiring clarification +
-  * Reuses existing requirements wherever those requirements already define the applicable operation or interaction +
-  * Creates additional atomic requirements only when the reuse assessment identifies a coverage gap+
  
-{{indexmenu>dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:or-001#1|js navbar nocookie maxjs#1 id#crucible_or_001_requirements_nav}}+  * Approves the classification of the listed categories as Crucible roles 
 +  * Approves the six child requirements 
 +  * Confirms that the child requirements collectively preserve the complete approved intent of OR-001 
 +  * 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.
  
 ---- ----
  • dido/02-crusible/99-annexes/annex-c-requirements/02-operational-requirements/or-001/start.1784653070.txt.gz
  • Last modified: 2026/07/21 09:57
  • by nick_dido