Requirements - Documentation - D03 - Document Scope

The architecture documentation should be appropriate in scope and quality for the solution

Requirement

D03 : The architecture documentation should be appropriate in scope and quality for the solution covering (but not exclusively):

  • Architecture Vision
  • Architecture Roadmap
  • Layer Diagrams
  • Capability Model and Solution Mapping
  • Non-functional requirements
  • Conceptual Architecture
  • Logical Architecture
  • Physical Architecture (including network, infrastructure etc.)
  • Solution Design Overview (SDO)
  • Key Architecture Decisions (KADs)
  • Data Models
  • Data Flows
  • API Specifications
  • Volume and Performance Models
  • Architecture Decision Records
  • Assumptions, Risks, Issues and Dependencies

Requirement description

This requirement is concerned with ensuring that sufficient architecture documentation exists to understand, govern, operate, support and evolve the solution.

The scope and depth of documentation should be proportionate to the size, complexity, risk and criticality of the service. Not every solution will require the same level of detail, but assessors should expect evidence that key architecture views, decisions, requirements and dependencies have been documented where relevant.

Documentation should support delivery teams, operational teams, governance groups and future architects who need to understand how and why the solution has been designed.

In simple terms:
The architecture should be documented well enough for people to understand the solution, maintain it, govern it and change it safely.

Scoring rubric table – D03 Architecture Documentation Completeness and Quality

Score What it looks like Typical evidence Key gaps / risks
0 No meaningful architecture documentation exists or documentation is insufficient to understand the solution. No architecture artefacts.
Missing diagrams.
No documented decisions.
No design documentation. 		Significant service risk. Knowledge is dependent on individuals and the solution cannot be effectively governed, operated or evolved.
1 Limited architecture documentation exists but it is fragmented, incomplete or largely undocumented. Basic diagrams.
Partial design notes.
Informal documentation.
Limited architecture rationale. 		High-risk gaps. Critical aspects of the design may be undocumented and difficult to validate or support.
2 Some key architecture artefacts exist and provide partial coverage of the solution, but significant gaps remain. Some architectural views.
Partial solution documentation.
Incomplete non-functional requirements.
Limited ADRs or design records. 		Significant notable gaps. Important architecture areas, dependencies or operational considerations may not be documented.
3 Much of the expected architecture documentation exists and provides an acceptable understanding of the solution. Solution Design Overview.
Architecture diagrams.
Roadmaps.
Key Architecture Decisions.
Documented requirements.
Dependencies and risks captured. 		Notable gaps remain. Some architecture views may be incomplete, outdated or lack sufficient detail for governance or operational purposes.
4 Most relevant architecture artefacts are available, maintained and of good quality. Documentation supports governance, delivery and operational activities. Comprehensive architecture document set.
Logical and physical architectures.
Data flows and models.
API specifications.
Non-functional requirements.
Architecture Decision Records.
Maintained roadmap and supporting artefacts. 		Minor gaps only. Missing artefacts are low risk and do not materially affect understanding of the solution.
5 Comprehensive and exemplar architecture documentation. Documentation is maintained, trusted and actively used throughout the solution lifecycle. Complete architecture repository.
Strong traceability across artefacts.
Current and maintained architecture views.
Comprehensive decision records.
Operational and governance usage evidence.
Documentation supporting delivery, support, assurance and future evolution activities. 		Minimal or no significant gaps. Documentation provides a clear, authoritative view of the solution and supports continuous improvement.

What assessors should look for

  1. Coverage – Does the documentation cover the important architecture domains relevant to the solution?
  2. Quality – Are diagrams, models and specifications understandable, accurate and usable?
  3. Decision visibility – Are key architecture decisions and rationale documented?
  4. Operational value – Can delivery, support and governance teams use the documentation to understand and manage the solution?
  5. Non-functional considerations – Are performance, resilience, security, scalability and operational requirements documented where relevant?
  6. Maintenance – Is the documentation current and aligned to the implemented solution?

What separates a 3 from a 4 or 5

A score of 3 generally indicates that most key architecture documentation exists and provides a reasonable understanding of the solution, but there are important gaps, inconsistencies or areas that are no longer fully current.

A score of 4 requires a broadly complete architecture document set that covers the major solution views, decisions, requirements and dependencies. Documentation should be maintained and actively support governance and delivery activities.

A score of 5 requires architecture documentation to be comprehensive, well-maintained and demonstrably used across delivery, operations, governance and future architecture planning. Artefacts should be connected, traceable and dependable enough to be considered an authoritative source of information.

Suggested evidence examples (not SAF-mandated artefacts)

  • Architecture Vision documents
  • Architecture Roadmaps
  • Capability models and solution mappings
  • Conceptual, logical and physical architecture diagrams
  • Solution Design Overview (SDO) documents
  • Architecture Decision Records (ADRs)
  • Key Architecture Decision logs
  • Data models and data flow diagrams
  • API specifications and interface catalogues
  • Volume and performance models
  • Non-functional requirements specifications
  • Risk, dependency and assumption registers
  • Architecture governance submissions and reviews

Updated: 04 September 2026 (SAF Version 1.1)