| Both sides previous revision Previous revision Next revision | Previous revision |
| fxdemo:01-part:10-conceptual-traceability-model:10-1-overview [2026/06/30 17:00] – owen | fxdemo:01-part:10-conceptual-traceability-model:10-1-overview [2026/07/18 12:33] (current) – external edit 127.0.0.1 |
|---|
| [[fxdemo:01-part:start | Go to Top ]] | [[fxdemo:01-part:start | Go to Top ]] |
| |
| The Conceptual [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] Model defines how the Financial Systems Archetype preserves relationships among conceptual elements, logical elements, implementation artefacts, deployment artefacts, and [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. | The Conceptual [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] Model defines how the Financial Systems Archetype preserves relationships among conceptual elements, logical elements, implementation artifacts, deployment artifacts, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. |
| |
| [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] allows authors, reviewers, implementers, testers, operators, and auditors to understand how a concern moves through the document set. It also supports impact analysis when a concept, logical element, implementation artefact, deployment artefact, or [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] requirement changes. | [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] allows authors, reviewers, implementers, testers, operators, and auditors to understand how a concern moves through the document set. It also supports impact analysis when a concept, logical element, implementation artifact, deployment artifact, or [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] requirement changes. |
| |
| Figure 10.1-1 summarises the traceability chain used by the Financial Systems Archetype. | Figure 10.1-1 summarises the traceability chain used by the Financial Systems Archetype. |
| Conceptual Element | Conceptual Element |
| └── Logical Element / PIM | └── Logical Element / PIM |
| └── Implementation Artefact / PSM | └── Implementation Artifact / PSM |
| └── Deployment Artefact | └── Deployment Artifact |
| └── Evidence | └── Evidence |
| Figure 10.1-1: Traceability chain from conceptual element to evidence | Figure 10.1-1: Traceability chain from conceptual element to evidence |
| |
| The [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] chain does not require one-to-one mapping at every layer. One conceptual element may influence multiple logical elements. One logical element may map to multiple implementation artefacts. One [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] item may support multiple claims. The architecture requires explicit relationships, not artificial one-to-one correspondence. | The [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] chain does not require one-to-one mapping at every layer. One conceptual element may influence multiple logical elements. One logical element may map to multiple implementation artifacts. One [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] item may support multiple claims. The architecture requires explicit relationships, not artificial one-to-one correspondence. |
| | |
| | ---- |
| | |
| | <WRAP centeralign> |
| | |
| | © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. |
| | |
| | </WRAP> |
| | |