Architecture review checklist

Post date: Jan 20, 2019 9:58:02 PM

Review of an existing system architecture or review of an architecture document of a system to be developed is often asked by project teams and architects have to conduct the review. A check list can help conducting review without forgetting important aspect of the architecture. It can also give a structured approach to the review process. Here is a check-list for architecture document :

• 1. Are the major system goals clearly stated?

  2. Are architecturally significant requirements identified and documented?

  3. Are measurable non functional requirements explicitly defined?

  4. The overall organization of the system can be understood after reading the architecture document?

  5. Does document describe all relevant architectural views?

     1. Logical view (class diagram per component expresses functionality).

     2. Process view (how control threads are set up, interact, evolve, and die).

     3. Physical view (how system will be deployed. Deployment diagram

     4. Development view (how code is organized?)

  6. Does the document provide rationale behind architectural approach?

  7. Is build versus buy analysis done and decisions are drawn from it (for selection of tools, products)?

  8. Does the document provide recommended tools and technologies?

  9. Does the document provide rational behind selected tools and technologies?

  10. Does the document provide alternate solutions other than recommended one?

  11. Does document provide functional view (functional decomposition of the system?

  12. Is functional view driven by functional requirements?

  13. Are all functional requirements covered by functional view?

  14. Are modules identified and all the requirements covered by one of the identified modules?

  15. Are interface to other modules defined for all the identified modules?

  16. Is there good balance of modules (sufficient but not too many)?

  17. Does architecture defined takes care of changeability?

  18. Does architecture describes how re-usability will be achieved?

  19. Does architecture takes care of "avoid chatty interfaces for remote calls" principle?

  20. Does architecture takes care of "don't repeat yourself" principle?

  21. Does architecture takes care of separation of concern (by layering or other styles)?

  22. Does architecture provides data access layer to hide the data storage implementation from business logic?

  23. Is database model defined in sufficient detail?

  24. Are all key objects identified?

  25. Does document defines how user inputs will be handled and it is efficient?

  26. Does document define user interface design strategy?

  27. Does document consider modular user interface design approach?

  28. Does document define error handling strategy in sufficient detail?

  29. Does document provide sufficient detail about how I/O will be handled?

  30. Does document provide sizing information?

  31. Does document provide modules wise resource requirements (estimates)?

  32. Does document describe how system will recover after events of failures?

  33. Does document consider projected growth of the system and future needs and defines how system will scale?

  34. Does document describe main stakeholders of the system?

  35. Does document describe users/actors of the system?

  36. Does document consider regulatory and compliance requirements if any applicable?

  37. Does document describe interfaces to any other systems (if applicable)?

  38. Does the document describe how the system will be integrated with other systems (if required)?

  39. Is rational behind selections of tools/technology/method for integration provided in the document?

  40. Does document describe how will system handle the long running transactions to avoid performance hit ( specially in cases where transactions cross system boundary)?

  41. Does document describe (if required): how high availability will be achieved ?

  42. Does document describe how external access will be provided to the system (if applicable)?

  43. Does document describe release management strategy?

  44. Does document describe component descriptions at sufficiently & precise level?

  45. Does document describe relationships between the components?

  46. Are cross-cutting concerns described and how they will be handled?

  47. Does document describe how initialization and reset will be performed?

  48. Is security design described?

  49. Does architecture define (if applicable,) how Internationalization (I18N) will be taken care of?

  50. Does document describe user help?

  51. Does document describe test strategy?

  52. If applicable, does document describes migration strategy?

  53. If applicable, does document describe data loading strategy?

  54. Is system designed with low complexity?

  55. Is system designed with high cohesiveness ? (Every component has single responsibility)

  56. Is system designed with low coupling? (Components don't depend on internal detail of other component, abstraction is used)

  57. Is system designed with low fan-in and low fan-out?