Review Checklist for Architectural Design Document

This checklist is NOT intended as a starting point to write a document. It does NOT necessarily cover all aspects relevant for this type of document.
This checklist is intended only as an aid in checking a completed document.

Also see

General Review Checklist for All Documents

Is the software architecture as simple as possible (but no simpler)?
- No more than 7 loosely-coupled coherent high-level components.
- Possibly cluster lower-level components into high-level components (hierarchy).
- Using standard(ized) components.
Is the relationship to the software requirements clearly explained and motivated?
- Why does the proposed architecture realize the software requirements?
- Prove critical properties of the software architecture.
Is the architecture complete?
- Are all software requirements covered?
- Trace critical software requirements through the architecture (e.g. via use cases).
Are the component descriptions sufficiently precise?
- Must allow independent construction.
- Are interfaces and external functionality of the high-level components described in detail.
- Avoid implementation details; do not describe each class in detail.
- Interface details:
  - Routine kind, name, parameters and their types, return type, pre- and postcondition, usage protocol w.r.t. other routines.
  - File name, format, permissions.
  - Socket number and protocol.
  - Shared variables, synchronization primitives (locks).
- Where appropriate use features of target programming language.
Are the relationships between the components explicitly documented?
- Possibly use a diagram (and do explain the meaning of graphical elements)
Is the proposed solution realizable?
- Can the components be implemented or bought, and then integrated together.
- Possibly introduce a second layer of decomposition to get a better grip on realizability
Are all revelevant architectural views documented?
- Logical view (class diagram per component expresses functionality).
- Process view (how control threads are set up, interact, evolve, and die).
- Physical view (deployment diagram relates components to equipment).
- Development view (how code is organized in files; could also be documented in SCMP appendix).
Are cross-cutting issues clearly and generally resolved?
- Exception handling.
- Initialization and reset.
- Memory management.
- Security.
- Internationalization.
- Built-in help.
- Built-in test facilities.
Is all formalized material and diagrammatic material accompanied by sufficient explanatory text in natural language?
Are design decisions documented explicitly and motivated?
- Restrictions on developer freedom w.r.t. the software requirements.
Have alternative architectures been sketched and has their evaluation been documented?
- Have non-functional software requirements also been considered
- Negative indicators:
  - High complexity: a component has a complex interface or functionality.
  - Low cohesion: a component contains unrelated functionality.
  - High coupling: two components have many (mutual) connections.
  - High fan-in: a component is needed by many other components.
  - High fan-out: a component depends on many other components.
Is the flexibility of the architecture demonstrated?
- How can it cope with likely changes in the requirements?
- Document the most relevant change scenarios.
Are exploratory prototypes described for those areas where the project team lacks experience? (In appendices.)