Os elementos de design separados têm baixo acoplamento? Cada elemento de design tem alta coesão interna?

O design reflete os objetivos arquiteturais do sistema?

O sistema pode ser implementado a partir das informações no design? O detalhamento está suficiente?

O design está consistente? Alguma parte do design contradiz uma outra parte de forma que ponha o projeto em risco?

O design é capaz de acomodar mudanças futuras?

O design está apropriado para o nível de experiência dos outros membros da equipe e dos stakeholders, sem ser muito simples nem muito avançado?

O design está escrito de tal forma, e estruturado o bastantes, para que possa ser mantido com facilidade?

O design restringe a implementação somente o necessário?

O design descreve todo o comportamento do sistema para os requisitos que estão sendo tratados no momento?

Todas as partes do design podem ser rastreadas para os requisitos? Os requisitos (para a iteração corrente) posem ser rastreados para os elementos de design?

Existe um lugar, ou lugares, não ambíguos no design onde cada comportamento exista?

Os fluxos dos casos do uso, que estão sendo tratados neste momento, estão descritos no design?

Os fluxos complexos, incluindo os casos excepcionais, estão fora do Fluxo Básico?

O comportamento, descrito nos requisitos que estão sendo tratados neste momento, está distribuído para os elementos de design corretos?

O design fornece bastante informação para a criação dos testes? Por exemplo, as colaborações entre os elementos de design estão bastante claras de forma que os testes de integração possam ser criados?

As áreas redundantes do design foram removidas de forma que a implementação não contenha código redundante?

O design descreve o sistema em um nível apropriado de abstração, mostrando os objetivos? Isto normalmente significa que o sistema está descrito em níveis diferentes de abstração e perspectivas.

O design usa termos e vocabulário comuns dos domínios de negócio e técnico?

O design descreve o comportamento dos elementos inequivocamente de forma que os testes de desenvolvedor possam ser criados para verificar a implementação?

A semântica, o vocabulário e as construções de design estão apropriadas ao problema que está sendo resolvido? Isto normalmente significa que o vocabulário do cliente está sendo usado e que os elementos de design estão sendo referenciados de forma consistente.

O design está organizado de forma que os membros da equipe possam encontrar facilmente as informação que eles estão procurando?

O design está organizado de forma que ajude os membros da equipe a modifica-lo sem terem que competir pela mesma parte do design? Isto é, podem várias pessoas trabalhar no design em paralelo?

Os nomes dos elementos no design estão consistentes e fáceis de interpretar?

Cada elemento de design representa um abstração claramente definida?

 design está simples o bastante ao mesmo tempo que cumpre os objetivos do design e fornece direção suficiente para os implementadores?

O design está claro o bastante e contém bastante detalhe de forma que possa ser implementado?

A arquitetura está claramente representada no design? Os membros da equipe e os stakeholders podem identificar claramente a parte do design que é a arquitetura?

Os mecanismos arquiteturais (padrões) estão definidos claramente no design de forma que sejam reutilizáveis e compreensíveis?

Os mecanismos arquiteturais (padrões) estão sendo usados apropriadamente? Estão sendo usados em todas as circunstâncias onde são aplicáveis?

Todos os elementos dentro de um subsistema têm visibilidade privativa? Ou seja, a interface do subsistema é a única forma de acessar o comportamento dos elementos que estão dentro do subsistema?

A interface de cada subsistema está definida claramente no design?

As dependências do subsistema estão documentadas? 

A divisão em pacotes está lógica e consistente? Faz sentido para os membros da equipe e os stakeholders?

Os nomes dos pacotes descrevem exatamente seu conteúdo e o papel que executam na arquitetura? Eles seguem as convenções de criação de nomes?

As interfaces e os pacotes públicos fornecem um conjunto de serviços logicamente coesivos?

Todo o conteúdo de um pacotes esta listado? As classes dentro de um pacote estão coesivas?

As dependências entre pacotes correspondem às dependências entre as classes contidas neles?

Existem pacotes ou classes dentro de um pacote que podem ser separadas em um pacote independente ou em um sub-pacote?

Cada diagrama ajuda o analista a raciocinar sobre o design, ou comunica as principais decisões de design à equipe?

Os relacionamentos entre os diagramas estão claros quando diversos diagramas são usados para descrever um comportamento?

É fácil navegar entre os diagramas relacionados?

Cada diagrama dá foco em uma perspectiva relevante? Por exemplo, um grupo de diagramas mostra uma única classe e seus relacionamentos diretos, ao invés de usar um ou dois diagramas para mostrar todas as classes?

Cada diagrama está completo e mínimo? Mostra tudo que é relevante a esta visão e nada mais?

Os diagramas estão arrumados e fáceis de interpretar, com o mínimo de desordem?

O modelo visual está em conformidade com os padrões da UML, de forma que todos os stakeholders possam sempre compreender o modelo? Para maiores informações Veja: OMG UML Resource Page.

O modelo visual está em conformidade com os padrões de modelagem específicos do projeto ou da organização?

O nome de cada classe reflete claramente o seu papel?

Cada classe fornece o comportamento desejado?

Há pelo menos uma associação de realização definida para cada interface? A realização pode representar uma implementação do subsistema feita por terceiros.

Existem associações de dependência de cada subsistema com as interfaces que eles usam?

Cada operação, em uma interface de subsistema, está descrita em um diagrama de seqüência? Ou pelo menos mapeada diretamente a uma operação em uma classe?

Cada classe representa uma única abstração bem definida?

Os relacionamentos de generalização estão sendo usados somente para definições de herança e não de comportamento (implementação)? Ou seja o comportamento é compartilhado através do uso de relacionamentos de associação, agregação e contenção ao invés de generalização?

As classes pai são abstratas em relacionamentos de generalização? As classes “folha” são as únicas classes concretas em uma hierarquia de generalização?

Os estereótipos são usados com consistência e significado?

Existem gráficos de estado para classes com mudanças de estado complexas ou restritivas?

Os relacionamentos têm nomes descritivos de papel ou de associação (um ou outro mas não ambos), e multiplicidades corretas?

Os relacionamentos entre as classes são, sempre que possível, unidirecionais?
 

A semântica da linguagem de modelagem visual está claramente definida, documentada e acessível aos membros da equipe? A semântica deve ser significativa para os usuários do modelo.

A semântica da linguagem de modelagem pode ser sempre compreendida? A linguagem está documentada suficientemente de modo que os membros da equipe possam compreender o modelo, mesmo depois de bastante tempo das decisões de design terem ocorrido?

Os membros da equipe e os stakeholders estão treinados na linguagem de modelagem que está sendo usada?

O modelo visual está em conformidade com a semântica da linguagem de modelagem visual? Ou seja o significado dos símbolos nos diagramas está consistente em todo o modelo e todos os diagramas?