Por não existir um padrão de como escrever um caso de uso e incentivado pelo PU (Processo Unificado) que possibilita utilizarmos somente o que for necessário. O Caso de Uso acabou tendo diversos formatos do que deve constar em seu conteúdo.

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.

Pessoal, o blog está de nova cara. Mudei de template, pois a formatação dos textos no template anterior estava muito poluída e deixando a leitura cansativa.
Espero que gostem…

Enjoy

Mundo global, acesso facíl a qualquer lugar do mundo, e consequentemente um aumento na competição de mercado…

Agora os concorrentes não são somente nossos vizinhos.

Esse artigo Produzo software no Brasil, na Rússia, na Índia ou na China? faz uma excelente comparação com os países do BRIC, boa reflexão..

Até mais

O que são Requisitos?

É 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