• 架构描述是否完整、有意义、清晰？
• 架构是否在一个适当的水平细节上给出了目标？
• 被处理的概念是否使用了尽可能简单的方式？
• 架构是否清晰的表达了解决方案，以及那些约束了架构的相关决策的动机和目的？
• 架构的关键假设和决策是否被文档化，并可被评审人员和那些使用架构的人员阅读？
• 架构描述是否是最新的？
• 是否存在需要遵循的设计指导方针？

• 是否清晰的描述了架构目标？
• 是否识别并记录了架构约束？
• 是否识别并清晰的描述了架构关键需求？
• 架构是否同架构的目标、约束和需求一直？

• 何时应用架构机制是否清晰？
• 是否有清晰的设计模式支持每个机制？
• 每个机制是否充分处理了其所希望满足的需求？

• 是否清晰并一致的应用了划分方法？
• 划分方法是否降低了复杂性并改善了理解？
• 被定义的分区是否本身高内聚，而分区之间则是松散耦合？

• 是否充分定义了Key Abstractions？
• 是否充分定义了设计元素（如组件）？
• • 组件是否具有良好定义的接口？
  • 是否将系统职责分配给了组件？
  • 组件的数量和类型是否合理？

参见指南：Representing Interfaces to External Systems

是否识别了所有可重用资产 —— 包括重用来自其它系统的可重用资产，以及可被其它系统重用的资产。更多信息，参见指南：Software Reuse。 

• 架构是否易于演进，从而能够方便的适应期望的变化？
• 是否所有的技术风险都在应急计划中进行了缓解和处理？
• 架构是否过于结构化，牺牲了简单性和可理解性来处理不太可能发生的变化？（提示：如果答案是“Yes”，那么是不好的）
  
  

• 架构是否为组织开发团队提供了合适的基础？
• 每个团队是否有实现分配给他们的组件所需要的技能？
• 团队之间是否划分好了职责？
• 所有团队成员是否共享了对架构的相同理解？
• 团队成员是否充分的理解了架构，从而可以成功设计、编码分配给他们的组件？

• 是否将可部署的软件组件映射到物理结点？