Do separate design elements have low coupling? Does each design element have high internal cohesion?

Does the design reflect the architectural objectives of the system?

Can the system be implemented from the information in the design? Has sufficient detail been included?

Is the design consistent? Does any part of the design contradict another part of it in such a way that puts the project at risk?

Is the design able to accommodate future changes?

Is the design appropriate to the experience level of other team members and stakeholders, neither too simple nor too advanced?

Is the design written in such a way, and is it structured well enough, so it can be maintained easily?

Does the design constrain the implementation only as much as is necessary?

Does the design describe all the behavior of the system for the requirements that are currently being addressed?

Can all parts of the design be traced back to the requirements? Can the requirements (for the current iteration) be traced to design elements?

Is there an unambiguous place or places in the design where each behavior exists?

Are the use case flows that are currently being addressed described in the design?

Are complex flows outside the Basic Flow addressed, including exceptional cases?

Has the behavior described in the requirements that are currently being addressed been distributed to the correct design elements?

Does the design provide enough information for test design? For example, are the collaborations between design elements clear enough to create integration tests?

Have redundant areas of the design been removed so the Implementation does not contain redundant code?

Does the design describe the system at the appropriate level of abstraction, given the objectives? This usually means the system is described at a number of different levels of abstraction and perspectives.

Does the design use common vocabulary and terms from the business and technical domains?

Does the design describe the behavior of the elements unambiguously to the extent that developer tests can be created toverify the implementation?

Are the design's constructs, vocabulary, and semantics appropriate to the problem being solved? This usually means the customer's vocabulary is used, and elements of the design are referenced in a consistent manner.

Is the design organized in a way that team members can easily find the information they're looking for?

Is the design organized in a way that helps team members modify it without contending for the same part of the design? That is, can mulitple people work on the design in parallel?

Are the names of elements within the design consistent and easy to interpret?

Does each design element represent a clearly defined abstraction?

Is the design as simple as it can be while fulfilling the objectives of the design and giving sufficient direction to implementers?

Is the design clear enough and contain enough detail so it can be implemented?

Is the architecture clearly called out in the design ? Can team members and stakeholders clearly identify the portion of the design that is the architecture?

Are architectural mechanisms (patterns) clearly defined in the design so they're reusable and understandable?

Are architectural mechanisms used appropriately? Are they applied in all applicable circumstances?

Do all elements within a subsystem have private visibility? In other words, is the subsystem interface the only way to access the behavior of elements inside the subsystem?

Is the interface for each subsystem clearly defined in the design?

Are the subsystem dependencies documented? 

Is the package partitioning logical and consistent? Does it make sense to team members and stakeholders?

Do package names accurately describe the contents of the package and the role they play in the architecture? Do they follow naming conventions?

Do public packages and interfaces provide a logically cohesive set of services?

Are all the contents of a package listed? Are the classes within a package cohesive?

Do package dependencies correspond to the dependencies of the contained classes?

Are there packages or classes within a package that can be separated into and independent or sub-package?

Does each diagram help the designer reason about the design, or communicate key design decisions to the team?

Are the relationships between diagrams clear when several diagrams are used to describe behavior?

Is it easy to navigate between related diagrams?

Does each diagram focus 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?

Is each diagram complete and minimal? Does it show everything relevant to that view and nothing more?

Are the diagrams tidy and easy to interpret, with a minimum of clutter?

Does the visual model conform to UML standards so all stakeholders can understand the model over time? See the OMG UML Resource Page for more information.

Does the visual model conform to project or organization specific modeling standards?

Does the name of each class clearly reflect the role it plays?

Does each class offer the required behavior?

Is there at least one realization association defined for each interface? The realization may represent a 3rd party implementation of the subsystem.

Are there dependency associations from each subsystem to the interfaces it uses?

Is each operation in a subsystem interface described in a sequence diagram? Or at least mapped directly to an operation in a class?

Does each class represent a single well defined abstraction?

Are generalization relationships used only to inherit definitions, not behavior (implementation)? In other words, is behavior shared through the use of association, aggregation and containment relationships instead of generalization?

Are parent classes in generalization relationships abstract? Are the "leaf" classes in a generalization hierarchy the only concrete classes?

Are stereotypes used consistently and meaningfully?

Do statecharts exist for classes with complex or restrictive state changes?

Do relationships have descriptive role or association names (one or the other but not both), and correct multiplicities?

Are relationships between classes unidirectional whenever possible?
 

Are the semantics of the visual modeling language clearly defined, documented, and accessible to team members? The semantics should be meaninful to the users of the model.

Can the semantics of the modeling language be understood over time? Is the language documented well enough so that team members can understand the model long after design decisions have taken place?

Are team members and stakeholders trained in the modeling language being used?

Does the visual model conform to the semantics of the visual modeling language? In other words, are the meanings of the symbols in the diagrams consistent across the model and diagrams?