Examine os Casos de Uso relevantes e os Requisitos Suplementares para compreender o escopo da tarefa de design e as expectativas sobre o Design. Trabalhe com os Stakeholders e o Analista para esclarecer informações ambíguas ou incompletas.

Se os requisitos não estiverem representados em algum tipo de cenário (por exemplo um requisito não-funcional pôde não ter um cenário associado a ele), um cenário terá que ser identificado para exercitar apropriadamente os requisitos sob consideração.

Se for determinado que os requisitos estejam incompletos ou incorretos, trabalhe com o analista para melhorar os requisitos e possivelmente submeta uma solicitação de mudança para os requisitos.

Identifique os elementos que colaboram entre si para fornecer o comportamento desejado. Isto pode começar com as principais abstrações identificadas na arquitetura, na análise de domínio e na análise clássica dos requisitos (filtragem de substantivo) para derivar os elementos que serão necessários para cumpri-los.

Identifique elementos em todas as perspectivas que estão sendo consideradas ao executar esta tarefa. Isto pode incluir a identificação de elementos de interface de usuário, elementos de controle, elementos de dados e elementos que se relacionam ao interfaceamento com outros sistemas ou dispositivos.

Os elementos de design existentes devem ser examinados para ver se eles podem participar na colaboração. É um erro criar todos os elementos em cada execução desta tarefa.

Esta lista de candidatos deve ser expandida para incluir participantes de propósito especial que tratam papéis particulares no fornecimento do comportamento necessário tal como processamento transacional ou aderência à alguma especificação de segurança. O Padrão Entidade-Controle-Fronteira fornece um bom começo para identificar elementos.

Percorra o cenário distribuindo as responsabilidades aos elementos participantes. Estas responsabilidades podem ser simples declarações do comportamento atribuídas aos elementos; não necessitam ser especificações detalhadas de operações com parâmetros, etc. Esta etapa serve para assegurar que um modelo de qualidade esteja sendo criado e que seja robusto o bastante para suportar os requisitos.

Identifique os relacionamentos necessários entre os elementos baseado na passagem pelo cenário examinando como os elementos iniciam o comportamento dos outros. Um elemento que solicite o comportamento de um outro elemento é representado como um relacionamento entre os elementos. Assim como com as responsabilidades, estes relacionamentos podem ser definidos apenas nesta etapa.

Verifique a arquitetura e o trabalho de design prévio para criar uma colaboração consistente. Use o Arquiteto para explicar os detalhes e as motivações da arquitetura. Procure reutilizar relações e comportamentos existentes ou aplique estruturas similares para simplificar o design de todo o sistema.

Elementos adicionais podem ser identificados a medida que comportamentos encontrados não possam ser atribuídos apropriadamente à algum dos elementos existentes.

Refine o design até um nível apropriado de detalhe para orientar a implementação e para assegurar que caiba na arquitetura. Nesta etapa o design pode levar em consideração a linguagem de implementação real e outras decisões técnicas. Reveja a identificação dos elementos e das colaborações que realizam os cenários se for necessário enquanto este refinamento leva em consideração detalhes em um nível menor de abstração. Discuta questões sobre teste, tais como os elementos de design que são difíceis de testar ou áreas críticas de desempenho, com o Testador e o Arquiteto.

Tome decisões em particular a respeito das considerações abaixo:

• Detalhes específicos dos relacionamentos entre os elementos tais como a multiplicidade e a navegabilidade
• Detalhes das operações tais como parâmetros e valores de retorno
• Existência e detalhe dos atributos de dados necessários
• Uso de herança e de interfaces para melhorar o design

Incorpore Mecanismos de Design da arquitetura. Aplique uma estrutura consistente dos elementos e da organização do comportamento como em outras áreas do design e use os padrões identificados na arquitetura.

Projete elementos grandes ou complexos ou algum comportamento interno complexo mais detalhadamente.

Isto pode apenas envolver o planejamento de um algoritmo que possa ser executado para produzir o comportamento desejado. Adicione operações, atributos e relacionamentos adicionais para suportar as expectativas de um elemento. Discuta as questões sobre teste, tais como os elementos de design que são difíceis de testar ou áreas críticas de desempenho, com o Testador e o Arquiteto.

O estado do elemento controlado sobre o curso de sua vida pode ser projetado para assegurar o comportamento apropriado em vários usos.

Comunique o design para aqueles que necessitam compreende-lo. Embora isto esteja descrito daqui até o fim da tarefa, a comunicação deve acontecer em todas as etapas. Trabalhar colaborativamente é sempre melhor do que rever o trabalho depois dele estar completo.

Aqui estão algumas formas de comunicar o design:

• Modelos formais especificados em UML.
• Diagramas informais que mostrem a estrutura estática e capturem o comportamento dinâmico.
• Código comentado que comunique informações sobre a estrutura estática complementado com descrições textuais do comportamento dinâmico através dos módulos de código.
• Modelos físicos de dados para descrever o esquema da base de dados.

Aqui estão alguns exemplos dos indivíduos que precisarão entender o design:

• Os desenvolvedores que implementarão uma solução baseados no design.
• Um arquiteto que possa rever o design para assegurar que se conforma com a arquitetura ou que possa examinar o design para oportunidades de melhoria na arquitetura.
• Outros projetistas que podem examinar o design para  aplicabilidade em outras partes do sistema.
• Desenvolvedores ou outros projetistas que estarão trabalhando em outras partes do sistema que dependerão dos elementos projetados nesta tarefa.
• Outros revisores que revisarão o design para qualidade e aderência aos padrões.

Compreenda como a arquitetura se aplica a esta parte do design, e como este trabalho de design se ajusta ao resto do sistema. Incorpore todas as interfaces aplicáveis, principais abstrações, mecanismos e padrões no trabalho de design. Discuta possíveis refinamentos na arquitetura e novas áreas de potencial reuso com o arquiteto.

Se o sistema tiver dados persistentes, o design necessitará endereçar o esquema da base de dados (ou arquivo). Para um esquema de base de dados relacional, identifique o seguinte:

• A estrutura das tabelas e visões
• Relacionamentos entre tabelas
• Triggers que reforçam a integridade referential
• Constraints das colunas
• Valores padrão para as colunas
• Stored procedures e funções

Avalie o design de objeto para acoplamento, coesão e outras medidas de qualidade de design.

Avalie o design da base de dados ou arquivo a respeito de desempenho, integridade referential e normalização.

Considere o design de vários ângulos para assegurar que seja um design de alta qualidade e comunicável. Trabalhe com outros membros técnicos da equipe; uma parte independente pode fornecer uma perspective nova. Use o Testador e o Arquiteto para  fornecerem perspectivas sobre a qualidade e aderência do design à arquitetura. Entretanto, ao identificar potenciais revisores mantenha em mente que se alguém puder adicionar valor revendo o design, então talvez ele possa adicionar ainda mais valor participando ativamente no próprio esforço de design.

Se falhas de design forem identificadas, melhore o design.