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.
- 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
- Using standard(ized) components.
- Is the relationship to the software requirements clearly explained
- 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.
- 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?
©2002, Tom Verhoeff (TUE)
Feedback about this page is welcome