Fluxos secundáriosFluxos secundários

Só devem ser analisados e descritos após a descrição dos fluxos básicos.

Fluxos alternativos situações especiais (desconto para um cliente)

Fluxos de erro situações de erro

Reuso de fluxos secundáriosReuso de fluxos secundários

Fluxos secundários, principalmente de erros, podem ser referenciados por diferentes casos de uso.

Evitar duplicação de informação.

O documento de requisitos terá uma seção para isso.

Prioridade de Casos de UsoPrioridade de Casos de Uso

Essencial para gerenciar os requisitos E para montar as iterações

Definir prioridade de todos os casos de uso A prioridade pode ser:

Essencial Importante Desejável

Agrupamento de casos de usoAgrupamento de casos de uso

Dividir os casos de uso em pacotes Ator Funcionalidades correlatas Processos

ExercíciosExercícios

Descrever os casos de uso gerados nos exercícios anteriores, com mais detalhes, incluindo fluxos secundários.

Descrição de interface do usuárioDescrição de interface do usuário Ferramenta para compreensão do caso de uso

o nível de detalhes deve ser adequado ao usuário

Facilidade para a descrição de críticas básicas tamanho e tipo dos campos máscaras

Estruturação do Estruturação do Modelo de Casos de UsoModelo de Casos de Uso

Por que estruturar o modelo?Por que estruturar o modelo?

Extrair descrições de funcionalidades genéricas e compartilhadas que podem ser usadas por mais de um caso de uso.

Extrair descrições de funcionalidades adicionais que possam estender descrições específicas

Facilitar o entendimento do modelo

Mas atenção...Mas atenção...

O modelo não deve ser estruturado muito cedo!

Relacionamentos entre casos de usoRelacionamentos entre casos de uso

Inclusão

Extensão

Generalização

InclusãoInclusão

Use inclusão quando há repetição entre casos de uso e você quer evitar esta repetição.

Efetuar pagamento

Vendedor

Realizar pedido<<includes>>

Inclusão de casos de usoInclusão de casos de uso

Um caso de uso incorpora explicitamente o comportamento de outro caso de uso.

O caso de uso incluído é na maioria das vezes usado desta maneira (Ex. Identificação de usuário no sistema)

Evitando assim repetições de descrição de fluxos.

ExtensãoExtensão

Use extensão quando quiser descrever uma variação do comportamento normal.

Solicitar catálogo

Vendedor

Realizar pedido

extends

Extensão de casos de usoExtensão de casos de uso

Usado para modelar partes opcionais do sistema fluxos alternativos e complexos que raramente

acontecem fluxos que são executados somente em certos

casos

GeneralizaçãoGeneralização Generalização de um caso de uso A para um

caso de uso B indica que uma instância do caso de uso A inclui o comportamento especificado no caso de uso B.

Gerar relatório

Imprimir documento

Retornar item

Generalização de casos de usoGeneralização de casos de uso

É possível abstrair comportamento de casos de uso.

Os casos de uso “Retornar item” e “Gerar relatório” ambos precisam imprimir um recibo.

Identificar um caso de uso abstrato para realizar a impressão.

Generalização de atoresGeneralização de atores Quando um ator A realiza todos os casos

de uso que o ator B e outros adicionais, dizemos que A estende B.

VendedorRealizar venda

Estabelecer créditoSupervisor

Generalização de atoresGeneralização de atores

Estudante

Estudante em Tempo Integral

Estudante em Tempo Parcial

Tópicos CobertosTópicos Cobertos

Introdução Conceitos Chave Descrição do Problema Glossário Modelo de caso de uso Especificações Suplementares O Fluxo de Requisitos Checklists Estrutura de Documento de Requisitos

Checklists: Modelo de Casos de UsoChecklists: Modelo de Casos de Uso O modelo de caso de usos está fácil de se entender? Estudando o modelo de caso de usos, você pode ter

uma idéia clara das funções do sistema e como elas estão relacionadas?

Todos os requisitos foram levantados? O modelo de caso de usos contém algum

comportamento supérfluo? A divisão em pacotes do modelo de caso de usos

está apropriada?

Checklists: AtoresChecklists: Atores

Todos os atores foram identificados? Cada ator está envolvido com pelo menos um caso

de uso? Cada ator desempenha um papél? Algum deveria ser

fundido com outro ou ser dividido em dois? Existem dois ou mais atores desempenhando o

mesmo papél em relação a um caso de uso? Os atores têm nomes intuitivos e descritivos? Tanto

os usuários como os patrocinadores do software têm um entendimento comum?

Checklists: Casos de UsoChecklists: Casos de Uso

Cada caso de uso está envolvido com pelo menos um ator?

Os caso de usos são independentes uns dos outros? Algum dos caso de usos têm comportamento ou

fluxo de eventos muito similares? Os caso de usos têm nomes únicos, intuitivos e

explicativos de modo que não podem ser confundidos em um estágio posterior?

Os patrocinadores e usuários entendem os nomes e descrições dos caso de usos?

Checklists: Especificação de Caso de UsoChecklists: Especificação de Caso de Uso Está claro quem deseja executar um caso de uso? A finalidade de cada caso de uso está clara? A descrição breve dá uma idéia clara do significado do caso de

uso? Está claro como e quando os fluxos de eventos de cada caso

de uso começam e terminam? A seqüência de comunicação entre um ator e um caso de uso

está de acordo com as expectativas do usuário? As interações e trocas de informação entre os atores e o

sistema estão claras? Existe algum caso de uso demasiadamente complexo? Os fluxos de eventos (básicos e alternativos) estão modelados

de forma clara?

Checklists: GlossárioChecklists: Glossário

Os termos têm uma definição clara e concisa? Cada termo do glossário foi incluído em algum lugar

nas descrições dos caso de usos? Os termos são usados consistentemente nas

descrições dos atores e dos caso de usos?

Tópicos CobertosTópicos Cobertos

Introdução Conceitos Chave Descrição do Problema Glossário Modelo de caso de uso Especificações Suplementares O Fluxo de Requisitos Checklists Estrutura do Documento de Requisitos

O Documento de Requisitos: estruturaO Documento de Requisitos: estrutura

Introdução Descrição Geral do Sistema Requisitos Funcionais (casos de uso) Requisitos Não Funcionais Descrição da Interface com o usuário

Requisitos Funcionais Requisitos Funcionais (casos de uso)(casos de uso)

Breve descrição Ator Prioridade Interfaces Associadas (opcional) Entradas e Pré-condições Saídas e Pós-condições Fluxo de eventos principal Fluxos secundários: alternativos e de exceção

(opcional)

Revisão: Workflow de RequisitosRevisão: Workflow de Requisitos Quais são os principais artefatos do workflow de

requisitos? Para quê estes artefatos são usados? O que é um modelo de caso de usos? O que é um ator? O que é um caso de uso? Qual a diferença entre um caso de uso e um cenário? O que é uma especificação suplementar e o que ela

inclui? O que é um glossário e o que ele inclui?

ReferênciasReferências Applying Use Cases: A Practical Guide

Geri Schneider e Jason P. Winters Addison-Wesley, 1998.

UML DistilledMartin FowlerAddison-Wesley, 1997.

The Unified Software Development ProcessIvar Jacobson, Grady Booch e James RumbaughAddison-Wesley, 1998.

The Unified Modeling Language: The User GuideIvar Jacobson, Grady Booch e James RumbaughAddison-Wesley, 1999.