This is an old revision of the document!
C.2 Operational Requirements
The Operational Requirements define the actors, deployment environments, operational classifications, concurrency needs, and management scope within which Crucible operates.
These requirements establish the operational conditions that constrain and guide the functional, security, reliability, performance, maintainability, data management, and interoperability requirements.
Contents
Requirement Summary
| Requirement | Source Statement |
|---|---|
| OR-001 | The system SHALL support operation by Developers, DevSecOps Engineers, Platform Engineers, System Administrators, Security Engineers, and Compliance Officers |
| OR-002 | The system SHALL support deployment into AWS, Azure, Google Cloud Platform, VMware, OpenShift, Kubernetes, Bare Metal Infrastructure, and Air-Gapped Environments |
| OR-003 | The system SHALL support classified and unclassified deployment environments |
| OR-004 | The system SHALL support deployment and management of multiple environments simultaneously |
| OR-005 | The system SHALL support centralized management of distributed environments |
Assessment Approach
Each Operational Requirement page:
-
Preserves the source statement
-
Evaluates the source statement using the Specification Discipline and Authoring framework
-
Confirms and classifies defects using the Common Specification Weakness Enumeration
-
Provides a normalized requirement statement
-
Identifies applicable actors, environments, activities, and constraints
-
Defines ordered verification statements
-
Identifies outgoing traceability
-
Uses wiki backlinks for incoming traceability
-
Identifies additional concepts that require entries in the shared Terms and Definitions corpus
Shared Terms and Definitions
The Operational Requirements use or introduce concepts that should link to the shared Terms and Definitions corpus, including:
Notes for Editors
The individual requirement pages should retain the stable identifiers `OR-001` through `OR-005`.
The source statements should preserve the wording from the controlling System Requirements Specification.
Normalized statements should replace weak verbs such as support with direct, testable behavior.
Incoming traceability should use the wiki Backlinks function rather than a manually maintained list.
Individual requirement links should omit a trailing `:start` when the requirement record is a leaf page.
Do not rename requirement pages after external citation unless a redirect or move plan is in place.
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.