Design Review Checklist

  1. Are the following attributes well-defined for each design entity?
  2. Identification (unique name)
  3. Type (describing what kind of design entity it is)
  4. Purpose (describing why it was introduced, in terms of the requirements)
  5. Function (summarizing what the component does)
  6. Dependencies (possibly `none'; describing the requires or uses relationship)
  7. Interface (provided by the design entity)
  8. Processing (including autonomous activities)
  9. Data (information `hidden' inside)
  10. Is the relationship to the requirements clearly motivated? Is it clear why the proposed architecture realizes the requirements?
  11. Is the software architecture as simple as possible (but no simpler)?
  12. No more than 7 loosely-coupled coherent high-level components.
  13. Lower-level components possibly clustered into high-level components (hierarchy).
  14. Using standard(ized) components.
  15. Is deviation from intuitively obvious solution motivated?
  1. Is the architecture complete?
  2. Are all requirements covered?
  3. Trace some critical requirements through the architecture (e.g. via use cases).
  4. Are the component descriptions sufficiently precise?
  5. Do they allow independent construction?
  6. Are interfaces and external functionality of the high-level components described in sufficient detail?
  7. Interface details:
  8. Routine kind, name, parameters and their types, return type, pre- and post-condition, usage protocol with respect to other routines.
  9. File name, format, permissions.
  10. Socket number and protocol.
  11. Shared variables, synchronization primitives (locks).
  12. Have features of the target programming language been used where appropriate?
  13. Have implementation details been avoided? (No details of internal classes.)
  14. Are the relationships between the components explicitly documented?
  15. Preferably use a diagram
  16. Is the proposed solution achievable?
  17. Can the components be implemented or bought, and then integrated together.
  18. Possibly introduce a second layer of decomposition to get a better grip on achievability.
  19. Are all relevantarchitectural views documented?
  20. Logical (Structural) view (class diagram per component expresses functionality).
  21. Process view (how control threads are set up, interact, evolve, and die).
  22. Physical view (deployment diagram relates components to equipment).
  23. Development view (how code is organized in files).
  24. Are cross-cutting issues clearly and generally resolved?
  25. Exception handling.
  26. Initialization and reset.
  27. Memory management.
  28. Security.
  29. Internationalization.
  30. Built-in help.
  31. Built-in test facilities.
  32. Is all formalized material and diagrammatic material accompanied by sufficient explanatory text in natural language?
  33. Are design decisions documented explicitly and motivated?
  34. Restrictions on developer freedom with respect to the requirements.
  35. Has an evaluation of the software architecture been documented?
  36. Have alternative architectures been considered?
  37. Have non-functional requirements also been considered?
  38. Negative indicators:
  39. High complexity: a component has a complex interface or functionality.
  40. Low cohesion: a component contains unrelated functionality.
  41. High coupling: two or more components have many (mutual) connections.
  42. High fan-in: a component is needed by many other components.
  43. High fan-out: a component depends on many other components.
  44. Is the flexibility of the architecture demonstrated?
  45. How can it cope with likely changes in the requirements?
  46. Have the most relevant change scenarios been documented?