Um modelo de domínio não mostra artefatos ou classes de software. Note que modelo de domínio é diferente de camada de domínio, esta segunda representa uma camada de software com regras de negócio abaixo da camada de UI (UserInterface ou Apresentação).
O modelo de domínio não é um modelo de dados. Pode existir classes no modelo que não tenham atributos.

O que é Classe Conceitual
De modo informal, é uma idéia, coisa ou objeto. Mas formalmente uma classe conceitual pode ser considerada em termos do seu símbolo, da sua intensão e da sua extensão.

• Símbolo – palavra ou imagem que representa uma classe conceitual.
• Intensão – a definição de uma classe conceitual.
• Extensão - conjunto de exemplos aos quais a classe conceitual se aplica.

Exemplo:
Em um evento de transação de Emitir Nota Fiscal, podemos denomina-la como símbolo “Emitir NF”. A intensão de Emitir NF é “registrar de uma transferência de propriedade sobre um bem ou uma atividade comercial”. E a sua extensão são todas as “Notas Fiscais Emitidas” existentes no universo.

Referências

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. Bookman, 2007.

Para se aprofundar mais sobre esse assunto recomendo a leitura do livro “Writing Effective Use Case – Cockburn, Alistair”.

Dentro os diversos modelos de Caso de Uso, podemos dizer que os principais tópicos que temos que escrever são:

Fluxo principal:

• Não contém nenhuma condição ou desvio;
• Típico caminho que satisfaz os objetivos dos interessados.

Pré-condição:

• Condições que antecedem o caso de uso e devem ser informados ao leitor;
• São sempre assumidas como verdadeiras;
• Descreve um estado do sistema.

Pós-condição:

• O que deve ser verdade ao termino do caso de uso bem sucedido ou estado final do caso de uso.

Fluxo alternativo ou extensões:

• Descreve as condições e exceções que o fluxo principal podem tomar;
• Relação de 1 pra N com o fluxo principal;
• Descreve condições como algo que poder ser detectado pelo sistema ou pelo autor;
• Quando o fluxo for grande, pode ser expressado como outro caso de uso.

Diretrizes:

• Utilizar estilo essencial de redação, onde é expresso a intenção do usuário e as responsabilidades do sistema;
• Deixe de fora a interface do usuário;
• Focar nos objetivos dos atores, pois os casos de uso devem descreve-los.

Exemplo: O cliente (ator) tem a intenção de adicionar produtos ao carrinho e depois compra-los.
Caso de Uso: Adicionar ao carrinho, Comprar o produto.

• Iniciar os nomes de caso de uso sempre com um verbo;
• Operações do tipo CRUD (Create, Restore, Update, Delete), crie um único caso de uso denominado gerenciar .

Exemplo: Gerenciar usuários

• Observações: Alguns autores utilizam o verbo manter ao invés de gerenciar para operações CRUD.

É o mapeamento das propriedades que um software deve ter para atender um problema em especial.

Ele deve descrever os entendimento dos objetivos dos usuários e traduzir esses objetivos em funcionalidades do sistema.

Definições:

• Condição ou capacidade necessária para o usuário resolver um problema ou atingir um objetivo.
• Condições ou capacidade que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer um contrato, padrão, especificação, ou outro documento de formalidade.
• Representação documentada de uma condição ou capacidade.

Objetivos dos Requisitos:

• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer.
• Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema.
• Definir fronteiras do sistema (ou delimitar o sistema).
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.
• Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

Tipos de Requisitos:

Funcionais: Definem a funcionalidade do software, função que o sistema deve realizar para tender os objetivos do usuário.
Definem O QUE o sistema deve fazer, sem a preocupação de COMO fazer.

Não funcionais: Definem as qualidades do software.

Classificação dos requisitos FURPS+

É um sistema para a classificação de requisitos, que auxilia o analista a identificar a qual propósito as informações obtidas (objetivos do usuário e caracteristica do software) se destinam.

Funcionalidade (Functionality):

• Representa todo o aspecto funcional do sistema.

Usabilidade (Usability):

• Tempo de treinamento para um usuário se tornar produtivo.
• Tempo de duração desejado para determinada operação no sistema.
• Ajuda on-line, documentação do usuário e material de treinamento.

Confiabilidade (Reliability):

• Disponibilidade.
• Tempo de correção – tempo permitido para indisponibilidade quando ocorre uma falha.
• Precisão.
• Número máximo de defeitos (bugs/KLOC – mil linhas de código).
• Categorias de bugs – bugs devem ser categorizados por nível de impacto.

Performace ou Desempenho (Performance):

• Tempo de resposta para uma transação.
• Troughput (ex: transações por segundos).
• Capacidade (ex: transações concorrentes).
• Operação Parcial (Situação do sistema aceitável quando estiver prejudicado de alguma forma).
• Uso de rescursos: memória, espaço em disco, comunicação, etc.

Suportabilidade (Supportability):

• Padrão de codificação.
• Convesão de nomenclatura.
• Bibliotecas de classes.
• Utilitários de manutenção.

+ (Plus):

• Outros(Design, implementação, interface, físicos).

Prorização de Requisitos:

Essencial: sistema não entra em funcionamento.

Importante: não impedem o funcionamento do sistema.

Desejável: não impedem a entrada em funcioanemto do sistema sem a sua implementação.

Como escrever os requisitos:

O PU (Processo Unificado) define alguns modelos de documentos e processos que auxiliam o analista (e todo a equipe de desenvolvimento) a identificar e escrever requsitos.

Dentre os diversos tipos de documentos a serem escritos, podemos citar:

• Documento de Visão
• Documento de Caso de Uso
• Especificação Suplementar
• Glossário

Até mais