dido:03-dido-te:99-annexes:annex-b-references:dte-005

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
dido:03-dido-te:99-annexes:annex-b-references:dte-005 [2026/08/08 02:16] – nick_didodido:03-dido-te:99-annexes:annex-b-references:dte-005 [2026/08/08 02:16] (current) – old revision restored (2026/08/08 02:09) nick_dido
Line 1: Line 1:
-====== [DTE6] Structured Information Processing Reference Architecture (SIP-RA) ======+====== [DTE5] DIDO-TE Requirements Register ======
  
 [[dido:03-dido-te:99-annexes:annex-b-references:start|Go to Annex B: References]] [[dido:03-dido-te:99-annexes:annex-b-references:start|Go to Annex B: References]]
Line 5: Line 5:
 ===== Reference ===== ===== Reference =====
  
-Dido Solutions, Inc. and Jackrabbit Consulting, Inc. //Structured Information Processing Reference Architecture (SIP-RA)//.+DIDO Solutions, Inc. //DIDO-TE Requirements Register//. Draft requirements register.
  
 ===== Bibliographic Information ===== ===== Bibliographic Information =====
  
 ^ Attribute ^ Value ^ ^ Attribute ^ Value ^
-| Reference Identifier | [DTE6] | +| Reference Identifier | [DTE5] | 
-| Title | Structured Information Processing Reference Architecture (SIP-RA) | +| Title | DIDO-TE Requirements Register | 
-| Filename | Record the authoritative filename. | +| Filename | <todo>Record the authoritative filename.</todo> | 
-| Artifact Type | Reference Architecture | +| Artifact Type | Requirements register | 
-| Version | Record the authoritative version. | +| Source Requirement Identifiers | ''REQ-0001'' through ''REQ-0091'' | 
-| Document Date | Record the authoritative document date. | +| Version | <todo>Record the authoritative version.</todo> | 
-| Preparing Organisations | Dido Solutions, Inc. and Jackrabbit Consulting, Inc. | +| Document Date | <todo>Record the authoritative document date.</todo> | 
-| File Format | Record the authoritative file format. | +| Preparing Organisation | DIDO Solutions, Inc. | 
-| Status | Record the authoritative status. | +| File Format | <todo>Record the authoritative file format.</todo> | 
-| URI | Record the canonical SIP-RA URI. |+| Status | Draft source material |
  
 ===== Scope ===== ===== Scope =====
  
-The Structured Information Processing Reference Architecture (SIP-RA) defines an implementation-independent architecture for the governed processing of structured information.+The DIDO-TE Requirements Register records source requirements, acceptance criteria, explanatory information, and supporting material for the Distributed Immutable Data Object Test Environment (DIDO-TE).
  
-SIP-RA establishes architectural concepts, terminology, models, relationships, requirements, conformance criteria, and traceability practices applicable to systems that process structured information.+The register contains source requirements identified as ''REQ-0001'' through ''REQ-0091''.
  
-DIDO-TE uses SIP-RA as an architectural foundation for the design, implementation, operation, validation, and conformance of the DIDO Test Environment.+The register serves as source material for the canonical DIDO-TE requirements maintained in [[dido:03-dido-te:99-annexes:annex-c-requirements:start|Annex C: Requirements]].
  
-===== Architectural Content =====+The source requirement identifiers preserve traceability to the register. They do not constitute canonical DIDO-TE requirement identifiers.
  
-SIP-RA addresses architectural subject areas associated with:+===== Requirement Content =====
  
-  * Structured information processing +The register addresses DIDO-TE subject areas associated with: 
-  * Reference Architecture + 
-  * Conceptual, logical, and physical models +  * Test Environment configuration 
-  * Architectural components and relationships +  * Nodes and Deployment Targets 
-  * Information-processing pipelines +  * Twin Nodes 
-  * Data and metadata +  * Virtual networks and communication 
-  * Processing lifecycle governance +  * State and time control 
-  * Traceability+  * Test definition 
 +  * Test execution 
 +  * Record and playback 
 +  * Baselines and comparison
   * Validation   * Validation
-  * Conformance +  * Monitoring and Evidence 
-  * Conformance criteria +  * Catalogues and reuse 
-  * Conformance points +  * Governance and Communities of Interest 
-  * Implementation profiles +  * DIDO-TE operations
-  * Evidence +
-  * Auditability +
-  * Reproducibility +
-  * Interoperability+
   * Security   * Security
-  * Governance+  * Logging and auditing 
 +  * Reliability 
 +  * Performance 
 +  * Maintainability 
 +  * Data management 
 +  * Interoperability
  
-DIDO-TE applies the SIP-RA concepts relevant to a distributed Test Environment and specialises them where DIDO-TE requires test-specific architectural meaning.+The register may contain compound statements, acceptance criteria, explanatory material, implementation suggestions, and other supporting information. Annex C analyses and dispositions this material before establishing canonical requirements.
  
 ===== Relevance to DIDO-TE ===== ===== Relevance to DIDO-TE =====
  
-This reference provides part of the architectural foundation for DIDO-TE.+This reference provides source-requirement provenance for the DIDO-TE requirements corpus.
  
-DIDO-TE uses [DTE6] to:+Annex C uses `[DTE5]` to:
  
-  * Establish architectural concepts and terminology +  * Identify source requirements 
-  * Preserve separation among conceptual, logical, and physical models +  * Preserve source identifiers and titles 
-  * Structure information-processing responsibilities +  * Preserve original source wording 
-  * Establish traceability between requirements and architectural elements +  * Identify independently interpretable obligations 
-  * Define inspectable conformance points +  * Identify independently verifiable obligations 
-  * Establish conformance criteria +  * Record requirement decomposition 
-  * Support validation and verification +  * Record terminology normalisation 
-  * Govern the production and preservation of Evidence +  * Establish traceability between source and canonical requirements 
-  * Support reproducible Test Environments and Test Executions +  * Distinguish normative obligations from acceptance criteria and supporting material
-  * Distinguish architectural requirements from implementation decisions+
  
-DIDO-TE requirements and architecture content identify any specialisation or extension of a SIP-RA concept.+A source requirement does not become a canonical DIDO-TE requirement until the requirements process analyses, normalises, traces, reviews, and approves it.
  
 ===== Citation Use ===== ===== Citation Use =====
Line 78: Line 81:
 DIDO-TE pages cite this reference using: DIDO-TE pages cite this reference using:
  
-[[dido:03-dido-te:99-annexes:annex-b-references:dte-006|[DTE6]]]+[[dido:03-dido-te:99-annexes:annex-b-references:dte-005|[DTE5]]]
  
-A citation identifies the applicable SIP-RA section, clause, requirement, figure, table, model element, or other precise source location.+A citation identifies the applicable source requirement identifier and title.
  
 For example: For example:
  
 <code dokuwiki> <code dokuwiki>
-[[dido:03-dido-te:99-annexes:annex-b-references:dte-006|[DTE6]]], Section 6.4.6, "Implementation Conformance Model."+[[dido:03-dido-te:99-annexes:annex-b-references:dte-005|[DTE5]]], ''REQ-0010 — Domain-scoped environments''.
 </code> </code>
  
-When a DIDO-TE requirement derives from a SIP-RA requirement, the citation identifies the applicable source requirement and its location.+When a canonical requirement derives from one obligation within a compound source requirement, the citation identifies the applicable source obligation.
  
-When DIDO-TE specialises or extends a SIP-RA concept, the citation identifies the original concept and records the resulting DIDO-TE specialisation or extension.+For example:
  
-===== Source Treatment =====+<code dokuwiki> 
 +[[dido:03-dido-te:99-annexes:annex-b-references:dte-005|[DTE5]]], ''REQ-0010 — Domain-scoped environments'', source obligation concerning creation of a Domain-owned Test Environment. 
 +</code>
  
-DIDO-TE preserves the meaning of architectural concepts derived from [DTE6].+When an acceptance criterion supports a requirement or its verification criteria, the citation identifies the applicable acceptance criterion.
  
-The derivation process:+===== Source-Requirement Treatment =====
  
-  * Identifies the precise SIP-RA source location +Annex C preserves the original identifier, title, and wording of each source requirement cited from `[DTE5]`.
-  * Preserves the original architectural meaning +
-  * Identifies the applicable DIDO-TE context +
-  * Records any terminology normalisation +
-  * Records any DIDO-TE specialisation or extension +
-  * Provides a rationale for each specialisation or extension +
-  * Maintains traceability between the source concept and the resulting DIDO-TE content +
-  * Distinguishes source requirements from derived DIDO-TE requirements +
-  * Distinguishes architectural constraints from implementation decisions+
  
-A DIDO-TE specialisation narrows or contextualises a SIP-RA concept for the DIDO Test Environment. It does not alter the historical SIP-RA source.+The requirements process:
  
-===== Conformance Content =====+  - Applies Specification Discipline and Authoring (SDA) analysis to identify candidate weaknesses 
 +  - Applies Common Specification Weakness Enumeration (CWE) evaluation to confirm and classify defects 
 +  - Separates compound source statements into independently interpretable and independently verifiable obligations 
 +  - Normalises spelling, capitalisation, spacing, and terminology without changing the source meaning 
 +  - Distinguishes normative obligations from acceptance criteria, rationale, explanation, examples, and implementation guidance 
 +  - Records the lineage between each canonical requirement and its source obligation 
 +  - Assigns a canonical DIDO-TE identifier following review and approval
  
-SIP-RA supplies architectural concepts associated with conformance, including:+The canonical requirement retains traceability to its source requirement even when analysis produces several independently verifiable leaf requirements.
  
-  * [[dido:99_annexes:annex-b-terms-and-definitions:c:conformance_model|Conformance Model]] +===== Identifier Treatment =====
-  * [[dido:99_annexes:annex-b-terms-and-definitions:c:conformance_criterion|Conformance Criterion]] +
-  * Architectural conformance +
-  * Conformance points +
-  * Implementation conformance +
-  * Requirements traceability+
  
-DIDO-TE applies these concepts to identify inspectable architectural elements, required behaviours, interfaces, records, Evidence, and verification results.+The identifiers ''REQ-0001'' through ''REQ-0091'' identify requirements within `[DTE5]`.
  
-A DIDO-TE conformance statement identifies the applicable SIP-RA source when SIP-RA establishes the governing architectural concept or requirement.+These identifiers remain source-reference identifiers. 
 + 
 +Annex C assigns canonical identifiers according to the applicable requirement class, including: 
 + 
 +  * ''MO'' for Mission Objectives 
 +  * ''OR'' for Operational Requirements 
 +  * ''FR'' for Functional Requirements 
 +  * ''SEC'' for Security Requirements 
 +  * ''LOG'' for Logging and Auditing Requirements 
 +  * ''REL'' for Reliability Requirements 
 +  * ''PER'' for Performance Requirements 
 +  * ''MNT'' for Maintainability Requirements 
 +  * ''DAT'' for Data Management Requirements 
 +  * ''INT'' for Interoperability Requirements 
 + 
 +Annex C does not replace the source identifier. Its traceability record preserves both identifiers.
  
 ===== Relationship to Other References ===== ===== Relationship to Other References =====
  
-[DTE6] supplies architectural concepts that complement the DIDO-TE-specific source material recorded in other references.+[DTE5] provides source requirements associated with concepts, proposals, and model content recorded in other DIDO-TE references.
  
 See: See:
Line 135: Line 148:
   * [[dido:03-dido-te:99-annexes:annex-b-references:dte-003|[DTE3] Draft BAA White Paper]]   * [[dido:03-dido-te:99-annexes:annex-b-references:dte-003|[DTE3] Draft BAA White Paper]]
   * [[dido:03-dido-te:99-annexes:annex-b-references:dte-004|[DTE4] DIDO Reference Data Model]]   * [[dido:03-dido-te:99-annexes:annex-b-references:dte-004|[DTE4] DIDO Reference Data Model]]
-  * [[dido:03-dido-te:99-annexes:annex-b-references:dte-005|[DTE5] DIDO-TE Requirements Register]] 
  
-[DTE1] records patented subject matter. [DTE2] and [DTE3] describe proposed applications of DIDO-TE. [DTE4] supplies a historical Conceptual Model. [DTE5] records source requirements. [DTE6] supplies the broader architectural framework within which DIDO-TE requirements and architecture content are organised.+[DTE1] records patented subject matter. [DTE2] and [DTE3] describe proposed applications of DIDO-TE. [DTE4] supplies a historical Conceptual Model. [DTE5] records the source requirements considered during development of the canonical DIDO-TE requirements corpus.
  
-Cite the reference that directly supports the applicable statement, architectural concept, or requirement derivation.+Cite the reference that directly supports the applicable statement or requirement derivation.
  
 ===== Status ===== ===== Status =====
  
-Record the authoritative publication status, version, and date of [DTE6] in the Bibliographic Information table.+[DTE5] records draft source material.
  
-A later SIP-RA revision does not automatically supersede the revision cited by existing DIDO-TE requirements, architecture content, Evidence, or published documents.+The register does not, by itself, establish the current normative DIDO-TE requirements corpus. [[dido:03-dido-te:99-annexes:annex-c-requirements:start|Annex C: Requirements]] contains the canonical requirements following analysis, normalisation, traceability, review, and approval.
  
-Record the relationship between revisions before changing the authoritative source used by DIDO-TE.+The source identifiers, original wording, version, date, and provenance remain part of the source record.
  
 ---- ----
Line 153: Line 165:
 ===== Notes for Editors ===== ===== Notes for Editors =====
  
-Preserve `[DTE6]` and this page namespace as stable citation identifiers.+Preserve `[DTE5]` and this page namespace as stable citation identifiers. 
 + 
 +Preserve the authoritative source file as the canonical source artefact. 
 + 
 +Record the authoritative filename, version, date, file format, and publication status when that metadata becomes available.
  
-Preserve the authoritative SIP-RA source file as the canonical source artifact.+Preserve the identifiers ''REQ-0001'' through ''REQ-0091'' in derivation and traceability records.
  
-Record the authoritative filename, version, date, file format, publication status, and canonical URI when this metadata becomes available.+Do not assign a source ''REQ-####'' identifier to a canonical DIDO-TE requirement.
  
-Identify the precise SIP-RA section, clause, requirement, figure, table, model element, or other source location when deriving DIDO-TE content from [DTE6].+Identify the precise source requirement, source obligation, and applicable acceptance criterion when deriving a canonical requirement from `[DTE5]`.
  
-Do not cite [DTE6] without a precise source location when a more precise citation is available.+Apply SDA analysis before CWE evaluation.
  
-Preserve the original SIP-RA meaning in the source record. Record DIDO-TE terminology and specializations separately.+Do not derive requirements solely from a source title, category heading, summary, or inferred architectural intent.
  
-Do not classify a change to architectural meaning, scope, responsibility, relationship, constraint, conformance criterion, or conformance point as an editorial correction.+Preserve the original source statement in the provenance record. Record the normalised requirement separately.
  
-Document each DIDO-TE specialization or extension with its source, resulting expression, and rationale.+Do not classify a change to scope, actor, behaviour, value, constraint, cardinality, relationship, or meaning as an editorial correction.
  
-Do not introduce implementation-specific products, technologies, datatypes, encodings, or deployment decisions into a conceptual requirement derived from SIP-RA.+Do not treat acceptance criteria, explanatory material, examples, implementation suggestions, or supporting information as independent normative requirements without analysis, traceability, review, and approval.
  
-Preserve the distinction among conceptual, logical, and physical models.+Separate compound source requirements into independently interpretable and independently verifiable obligations.
  
-Record the revision, provenance, and supersession relationship before replacing [DTE6] with another SIP-RA revision.+Record the revision, provenance, and supersession relationship before replacing `[DTE5]` with another requirements register.
  
-Preserve [DTE6] when existing requirements, architecture content, Evidence, reports, or externally published documents cite it.+Preserve `[DTE5]` when existing requirements, Evidence, reports, or externally published documents cite it.
  
 ---- ----
  • dido/03-dido-te/99-annexes/annex-b-references/dte-005.1786180579.txt.gz
  • Last modified: 2026/08/08 02:16
  • by nick_dido