| |
| dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:start [2026/08/17 14:15] – created nick_dido | dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:start [2026/08/19 18:19] (current) – nick_dido |
|---|
| [[dido:03-dido-te:99-annexes:annex-c-requirements:start|Go to Annex C: Requirements]] | [[dido:03-dido-te:99-annexes:annex-c-requirements:start|Go to Annex C: Requirements]] |
| |
| The Functional Requirements define the capabilities and behavior required to support distributed verification and testing. | This section identifies the Functional Requirements governing the capabilities and behavior required to support distributed verification and testing. |
| |
| These requirements describe what the architecture SHALL provide without prescribing a particular product, implementation, or realization technology. | Functional Requirements define what the architecture provides without prescribing a particular product, implementation, or realization technology. |
| |
| Functional Requirements are organized into subordinate requirement families. Each family groups related functional obligations and contains the individual normative requirement pages. | The requirements are organized into subordinate requirement families based on architectural subject area. A requirement family may contain non-leaf requirement groups that organize subordinate obligations, individual leaf requirements that establish independently verifiable normative obligations, or both. |
| | |
| | The requirements in these families derive from the applicable source documents identified in Annex B. Some requirements derive directly from those sources. Others normalize or decompose source concepts into individually verifiable architectural obligations. |
| |
| ===== Contents ===== | ===== Contents ===== |
| ===== Notes for Editors ===== | ===== Notes for Editors ===== |
| |
| <todo>Create the subordinate Functional Requirement category pages listed under Contents.</todo> | The explicit links under Contents remain while the subordinate Functional Requirement category pages are being created and reviewed. After all planned category pages exist, the explicit links may be removed because the ''indexmenu'' automatically discovers them. |
| | |
| | Preserve stable requirement identifiers when moving or reorganizing Functional Requirement pages. |
| |
| <todo>Move existing Functional Requirement families into the applicable subordinate namespaces while preserving stable requirement identifiers.</todo> | Do not allocate Functional Requirements directly to Crucible, DevSecOps, or another realization within the requirement Statement. Maintain realization relationships through Traceability. |
| |
| ---- | ---- |