Checklist: Architecture Notebook
This checklist provides questions to help in evaluating whether architectural decisions have been captured appropriately.
Relationships
Related Elements
Main Description

The items in this checklist represent good practices for creating and communicating a robust architecture. It may not be possible to address every item, and you may be able to address some items to only a limited extent. In these cases, be sure that there are good reasons for only partially addressing an item or not addressing an item at all.

Architectural revisions can occur every day. Use this checklist regularly to ensure that the results are robust, consistent, and understandable. Make the architecture good enough for the specific goals being addressed by using this checklist to identify areas that have been skipped, ignored, or not sufficiently addressed.

Check Items
Is the overall structure of the architecture clear?
  • Are the key abstractions adequately defined?
  • Have necessary Architectural Mechanisms been identified and described?
    • Is it clear when each mechanism should be applied?
    • Is there a clearly defined design pattern in place to support each mechanism?
    • Does each mechanism adequately address the requirements it is intended to meet?
  • Does the architecture divide the system’s responsibilities into well-defined subsystems with well-defined interfaces?
  • Does the packaging approach reduce complexity and improve understanding?
  • Is subsystem and package partitioning and layering logically consistent?
  • Are packages defined to be highly cohesive within the package, while the packages themselves are loosely coupled?
  • Are all of the subsystem components for the iteration identified?
  • Do the dependencies between subsystems and packages correspond to dependency relationships between the contained classes?
  • Do the classes in a subsystem support the services identified for the subsystem?
  • Are the number and types of components reasonable?
Have the supporting requirements been adequately addressed?
  • Does the architecture adequately address the global Functional requirements?
  • Does the architecture adequately address the Usability requirements?
  • Does the architecture adequately address the Reliability requirements?
  • Does the architecture adequately address the Performance requirements?
  • Does the architecture adequately address the Supportability requirements?
  • Does the architecture adequately address the other needs identified in the Supporting Requirements Specification?
Can the architecture be delivered by the team?
  • Does the component architecture provide a suitable basis for organizing the development teams?
  • Does each team have the skills required to implement their allocated components?
  • Are responsibilities divided well between teams?
  • Do all team members share the same understanding of the architecture as the one presented by the architect?
  • Can team members understand enough from the architecture to successfully design and code their allocated components?
Is architecture showing appropriate stability?
  • If in Inception, is a candidate architecture emerging?
  • If in Elaboration, is the architecture beginning to stabilize?
  • If in Construction, is the architecture generally stable?
  • If in Transition, is the architecture very stable?
In general, does the architecture seem sensible?
  • Is the architecture at an appropriate level of detail, given the objectives?
  • Are concepts handled in the simplest way possible?
  • Can the architecture easily evolve, so that expected changes can be easily accommodated?
  • Has the architecture been overly structured to handle unlikely change at the expense of simplicity and comprehensibility? (Hint: "Yes" to this question is not good.)
  • Are the key assumptions and decisions that the architecture is based on documented and visible to reviewers and those who will use the architecture?
  • Is the architecture description current?
  • Have the design guidelines been followed?
  • Are all technical risks either mitigated or addressed in a contingency plan?
More Information
Concepts

This program and the accompanying materials are made available under the
Eclipse Public License v1.0 which accompanies this distribution.

OpenUP Copyright.

OpenUP/DSDM Copyright.