posted Jan 20, 2019, 1:58 PM by Jageshwar Tripathi
[
updated Jun 13, 2020, 1:35 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 : - Are the major system goals clearly stated?
- Are architecturally significant requirements identified and documented?
- Are measurable non functional requirements explicitly defined?
- The overall organization of the system can be understood after reading the architecture document?
- Does document describe all relevant architectural views?
- Logical view (class diagram per component expresses functionality).
- Process view (how control threads are set up, interact, evolve, and die).
- Physical view (how system will be deployed. Deployment diagram
- Development view (how code is organized?)
- Does the document provide rationale behind architectural approach?
- Is build versus buy analysis done and decisions are drawn from it (for selection of tools, products)?
- Does the document provide recommended tools and technologies?
- Does the document provide rational behind selected tools and technologies?
- Does the document provide alternate solutions other than recommended one?
- Does document provide functional view (functional decomposition of the system?
- Is functional view driven by functional requirements?
- Are all functional requirements covered by functional view?
- Are modules identified and all the requirements covered by one of the identified modules?
- Are interface to other modules defined for all the identified modules?
- Is there good balance of modules (sufficient but not too many)?
- Does architecture defined takes care of changeability?
- Does architecture describes how re-usability will be achieved?
- Does architecture takes care of "avoid chatty interfaces for remote calls" principle?
- Does architecture takes care of "don't repeat yourself" principle?
- Does architecture takes care of separation of concern (by layering or other styles)?
- Does architecture provides data access layer to hide the data storage implementation from business logic?
- Is database model defined in sufficient detail?
- Are all key objects identified?
- Does document defines how user inputs will be handled and it is efficient?
- Does document define user interface design strategy?
- Does document consider modular user interface design approach?
- Does document define error handling strategy in sufficient detail?
- Does document provide sufficient detail about how I/O will be handled?
- Does document provide sizing information?
- Does document provide modules wise resource requirements (estimates)?
- Does document describe how system will recover after events of failures?
- Does document consider projected growth of the system and future needs and defines how system will scale?
- Does document describe main stakeholders of the system?
- Does document describe users/actors of the system?
- Does document consider regulatory and compliance requirements if any applicable?
- Does document describe interfaces to any other systems (if applicable)?
- Does the document describe how the system will be integrated with other systems (if required)?
- Is rational behind selections of tools/technology/method for integration provided in the document?
- Does document describe how will system handle the long running transactions to avoid performance hit ( specially in cases where transactions cross system boundary)?
- Does document describe (if required): how high availability will be achieved ?
- Does document describe how external access will be provided to the system (if applicable)?
- Does document describe release management strategy?
- Does document describe component descriptions at sufficiently & precise level?
- Does document describe relationships between the components?
- Are cross-cutting concerns described and how they will be handled?
- Does document describe how initialization and reset will be performed?
- Is security design described?
- Does architecture define (if applicable,) how Internationalization (I18N) will be taken care of?
- Does document describe user help?
- Does document describe test strategy?
- If applicable, does document describes migration strategy?
- If applicable, does document describe data loading strategy?
- Is system designed with low complexity?
- Is system designed with high cohesiveness ? (Every component has single responsibility)
- Is system designed with low coupling? (Components don't depend on internal detail of other component, abstraction is used)
- Is system designed with low fan-in and low fan-out?
|
|