Checklist: Component Design
This checklist helps to verify that the Component Design is described in a consistent manner and is complete.
Relationships
Related Elements
Check Items
Design is understandable
  • The design organized in a way that team members can easily find the information they're looking for.
  • Each diagram help the designer reason about the design, or communicate key design decisions to the team.
  • The design as simple as it can be while fulfilling the objectives of the design and giving sufficient direction to implementers or those who must maintain the system.
  • The design neither too simple nor too advanced, the design sophistication should be appropriate to the experience level of other team members and technical stakeholders. This applies to both the design conceptually and the representation of the design.
  • Each diagram complete and minimal, it shows everything relevant to that view and nothing more.
  • The diagrams tidy and easy to interpret, with a minimum of clutter.
  • The relationships between diagrams are clear when several diagrams are used to describe behavior.
  • It is easy to understand related diagrams

Design is consistent
  • The design follows established design standards and applies other idioms consistently.
  • The visual model conform to project or organization specific modeling standards.
  • The names of the design elements are consistent and easy to interpret.
  • No part of the design contradicts another part of it in such a way as to put the project at risk.
  • The visual model is internally consistent.  For instance, if an object diagram shows a relationship between objects, does a corresponding relationship exist between the appropriate classes?
  • The notation used to describe the design is used consistently and unambiguously.
Design is maintainable
  • The design is structured well enough to be maintained.
  • The design is set up to appropriately to accommodate expected changes.  (Note that the design should not be overdone to handle any possible change, just reasonably expected changes.)
  • If this is an up-front design, redundant areas of the design been removed so the implementation does not contain redundant code.
Design is well structured and organized
  • The package partitioning is logical and consistent so that it makes sense to other team members and stakeholders.
  • The package names accurately describe the contents of the package and the role they play in the architecture and follow naming established conventions.
  • Public packages and interfaces provide a logically cohesive set of services.
  • All the contents of each package listed and the classes within a package are cohesive.
  • Package dependencies correspond to the dependencies of the contained classes.
  • Packages or classes within a package have been separated into an independent package or sub-packages as appropriate.
  • Each diagram focuses on a relevant perspective.  For instance, does a set of diagrams show a single class and its direct relationships, rather than using one or two diagrams to show all classes?
Design confirms to the applicable architecture and design constraints
  • The design conforms to the architecture as specified with each component realization tracing back to its associated component specification documented in the architecture.
  • It clear how the design elements relate back to the requirements and it is clear what portions of the implementation support each design element.
  • The design reflect the architectural objectives of the system.
  • Design mechanisms used appropriately and are they applied in all applicable circumstances.
  • Stereotypes are used consistently and meaningfully.
Design supports a coarse-grained perspective of the system
  • Each component is designed such that one can work within one part without having to understand the internals of others.
  • The design is organized in a way that helps team members modify it without contending for the same part of the design, so that multiple people can work on the design in parallel.
Each component realization describe the internals of the component at the appropriate level of abstraction
Design is complete based on current scope and stage of development
  • There is a component realization for each component specification in the architecture.
  • Each component realization explains how the design realizes its component specification - sufficiently describing the internal structure of the component and how sequences of interactions realize the component's external behavior.
For up-front design, sufficient detail has been included to direct the implementation

Does the design constrain the implementation only as much as is necessary? Does the design allow freedom for the implementer to implement it appropriately?

Is the design feasible? Is it a design that can be reasonably implemented by the team using the technologies selected within the timeframe of the project?

For up-front design, enough information is provided to support developer testing

Does the design provide enough information for developer test design? Is the expected behavior and constraints on the methods clear?

Are the collaborations between design elements clear enough to create integration tests?