1. 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.

2. 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.

3. Is the architecture complete?
• Are all software requirements covered?
• Trace critical software requirements through the architecture (e.g. via use cases).

4. 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.

5. Are the relationships between the components explicitly documented?
• Possibly use a diagram (and do explain the meaning of graphical elements)

6. 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

7. Are all relevant 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).

8. Are cross-cutting issues clearly and generally resolved?
• Exception handling.
• Initialization and reset.
• Memory management.
• Security.
• Internationalization.
• Built-in help.
• Built-in test facilities.

9. Is all formalized material and diagrammatic material accompanied by sufficient explanatory text in natural language?

10. Are design decisions documented explicitly and motivated?
• Restrictions on developer freedom w.r.t. the software requirements.

11. 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.

12. Is the flexibility of the architecture demonstrated?
• How can it cope with likely changes in the requirements?
• Document the most relevant change scenarios.

13. Are exploratory prototypes described for those areas where the project team lacks experience? (In appendices.)