Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| dido:99_annexes:annex-d-requirements:part-00:p0-req-10-003 [2026/07/11 12:57] – removed - external edit (Unknown date) 127.0.0.1 | dido:99_annexes:annex-d-requirements:part-00:p0-req-10-003 [2026/07/18 12:33] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== P0-REQ-10-003 ====== | ||
| + | |||
| + | [[dido: | ||
| + | |||
| + | ===== Statement ===== | ||
| + | |||
| + | The document set SHALL preserve traceability from conceptual elements to logical elements, implementation artifacts, deployment artifacts, and evidence. | ||
| + | |||
| + | ===== Source ===== | ||
| + | |||
| + | Part 0, Section 10: Document Set Requirements. | ||
| + | |||
| + | ===== Rationale ===== | ||
| + | |||
| + | The Financial Systems Archetype document set is intended to support a governed architectural chain from meaning to realization. Conceptual elements define the architectural intent. Logical elements refine that intent into structured models. Implementation artifacts realize the logical elements using selected technologies. Deployment artifacts describe operational placement and execution. Evidence provides the basis for verifying that the deployed result remains consistent with the architecture. | ||
| + | |||
| + | Without traceability across these levels, later implementation or deployment decisions could become disconnected from the conceptual architecture. This would make it difficult to determine whether an implementation still satisfies the intended financial-system meaning, whether evidence supports the correct architectural claim, or whether changes in one part of the document set affect related parts. | ||
| + | |||
| + | ===== Applies To ===== | ||
| + | |||
| + | This requirement applies to the organization, | ||
| + | |||
| + | It applies specifically to traceability among: | ||
| + | |||
| + | * conceptual elements; | ||
| + | * logical elements; | ||
| + | * implementation artifacts; | ||
| + | * deployment artifacts; and | ||
| + | * evidence and verification material. | ||
| + | |||
| + | ===== Verification ===== | ||
| + | |||
| + | Verification SHALL confirm that architectural elements can be traced across the document set from conceptual definition through logical refinement, implementation mapping, deployment realization, | ||
| + | |||
| + | Verification activities should include review checks confirming that: | ||
| + | |||
| + | * conceptual elements have corresponding logical refinements where appropriate; | ||
| + | * logical elements can be traced back to the conceptual elements they refine; | ||
| + | * implementation artifacts identify the logical elements they realize; | ||
| + | * deployment artifacts identify the implementation artifacts they deploy or configure; | ||
| + | * evidence items identify the architectural or implementation claims they support; and | ||
| + | * trace links are maintained when document parts are revised, split, moved, or extended. | ||
| + | |||
| + | ===== Traceability ===== | ||
| + | |||
| + | This requirement supports the document set’s ability to demonstrate continuity from architectural intent to implemented and evidenced system behavior. | ||
| + | |||
| + | Related requirement identifiers: | ||
| + | |||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | |||
| + | Related source section: | ||
| + | |||
| + | * [[fxdemo: | ||
| + | |||
| + | ===== Status ===== | ||
| + | |||
| + | Draft | ||