< Sigla do Projeto>

Especificação de Caso de Uso

< Código e nome do Caso de Uso>

O nome do caso de uso deve ser apresentado juntamente com o seu código. O código deverá ser composto de uma letra (representando o módulo do sistema) e três algarismos numéricos (representando a sequência dos casos de uso de cada módulo). Exemplo: A001 - Cadastrar Pessoa, cujo A representa o módulo Administração e 001 o primeiro caso de uso.

Histórico de Revisões

Data	Versão	Autor	Revisor	Observações
<dd/mm/aaaa>	<N.m>	<nome>	<nome>	<detalhes>

Índice

1.	<Nome do Caso de Uso>	4

1.1	Ementa	4

2.	Atores envolvidos	4

3.	Pré-Condições	4

3.1	< Exemplo: o usuário deve estar identificado>	4

4.	Fluxo de Eventos	4

4.1	<Descrição do fluxo 1>	4

4.2	<Descrição do fluxo 2>	5

4.3	<Descrição do fluxo 3>	5

5.	Regras de Negócio	5

6.	Integrações	7

6.1	< Requisito de Integração Um >	7

7.	Pós-Condições	7

7.1	< Pós-Condição Um >	7

8.	Requisitos Especiais	7

9.	Referências	7

10.	Observações	7

11.	Aprovação	8

Especificação de Caso de Uso

<Nome do Caso de Uso>

Ementa

<A ementa deve resumir a finalidade do caso de uso. Este resumo deve permitir a contextualização.>

Atores envolvidos

<Listar os papéis dos usuários, exemplo: Supervisor, Analista, Gerente, etc...>

Pré-Condições

<Lista de condições/estado do sistema que devem ser verdadeiras antes do caso de uso ser executado.>

< Exemplo: o usuário deve estar identificado>

Fluxo de Eventos

<Descrição do fluxo 1>

<Aqui serão descritos os cenários de utilização do sistema cobertos pelo caso de uso.

Um ator sempre inicia o caso de uso. O caso de uso deve descrever o que o ator faz e a respectiva resposta do sistema. Deve ter o formato de um diálogo entre o ator e o sistema.

O caso de uso deve descrever o que acontece dentro do sistema, mas não como nem o porquê. Se houver troca de informações, especifique-as.

As alternativas simples podem ser apresentadas dentro do texto do caso de uso. Se forem necessárias, somente algumas sentenças para descrever o que acontece quando há uma alternativa, faça-o diretamente dentro do fluxo dos eventos.>

A numeração dos passos do fluxo básico deve seguir o padrão:

Este caso de uso é iniciado quando…

O sistema exibe as opções...

O ator seleciona a opção...

O caso de uso é encerrado.

As regras de negócio devem ser apresentadas logo abaixo do passo do sistema e serão definidas em uma seção específica. Deverá ser utilizado o recurso de indicador (ex: [RN1]).

Exemplo:

Informações utilizadas no fluxo

Nome do Campo	Comportamento
Obrigatório	Somente Leitura	Observações
Região	X	Ver regra Erro! Fonte de referência não encontrada.
Município	X	Ver regra Erro! Fonte de referência não encontrada.

Os fluxos de exceção também devem ser descritos em seção específica e utilizar o indicador (ex:(E1)), para serem apresentados junto aos passos do ator.

Exemplo:

Este caso de uso é iniciado quando…

O sistema exibe as opções...

O ator seleciona a opção...

Erro! Fonte de referência não encontrada.

Os fluxos alternativos simples, como descritos anteriormente, devem ser tratados de acordo com o exemplo:

Este caso de uso é iniciado quando…

O sistema exibe as opções...

O ator pode:

selecionar a opção X. Fluxo 2;

selecionar a opção y. Fluxo 3;

selecionar a opção Z. Fluxo 4;

O sistema exibe o formulário...

<Descrição do fluxo 2>

O sistema exibe as opções...

Informações utilizadas

Na primeira seção de regras de negócio deverão ser descritas as informações utilizadas no caso de uso.

Neste tipo de seção deverão ser agrupadas as informações a serem utilizadas em um cadastro, relatório, consulta, etc. Devendo ser apresentado no formato a seguir: ...

O ator seleciona a opção

O caso de uso é encerrado.

<Descrição do fluxo 3>

O sistema exibe as opções...

Informações utilizadas

Na primeira seção de regras de negócio, deverão ser descritas as informações utilizadas no caso de uso.

O ator seleciona a opção...

O caso de uso é encerrado.

...

Regras de Negócio

Informações utilizadas

Na primeira seção de regras de negócio, deverão ser descritas as informações utilizadas no caso de uso.

Nome do Campo	Tipo (Tamanho)	Descrição	Regras do Campo
Nome A <a descrição será utilizada como Label do campo na tela>	<Alfanumérico (100)>	Descrição detalhada do campo Dica: <Nome do campo> (A dica será apresentada num Hint da tela.)	<Regras para preenchimento do campo> <No fluxo de alteração: Somente leitura>
Nome B <a descrição será utilizada como Label do campo na tela>	<Numérico (11)>	Descrição detalhada do campo Dica: <Nome do campo> (A dica será apresentada num Hint da tela.)	<Regras para preenchimento do campo> <Formato (999.999.999-99)> <No fluxo de alteração: Somente leitura>
Nome C <a descrição será utilizada como Label do campo na tela>	<Domínio fixo>	Descrição detalhada do campo Dica: <Nome do campo> (A dica será apresentada num Hint da tela.)	<No fluxo de alteração: Somente leitura> <Regras para preenchimento do campo> <Valores de domínio: Valor 1 Valor 2 Valor N> <Lista de múltipla seleção> <Lista de única seleção>
Nome D <a descrição será utilizada como Label do campo na tela>	<Domínio dinâmico>	Descrição detalhada do campo Dica: <Nome do campo> (A dica será apresentada num Hint da tela.)	<No fluxo de alteração: Somente leitura> <Regras para preenchimento do campo> <Descrever de onde serão recuperadas as informações (outro UC)> <Lista de múltipla seleção> <Lista de única seleção>
Nome E <a descrição será utilizada como Label do campo na tela>	Data	Descrição detalhada do campo Dica: <Nome do campo> (A dica será apresentada num Hint da tela.)	<No fluxo de alteração: Somente leitura> <Regras para preenchimento do campo> <Formato (DD/MM/AAAA HH:MM)>

Regra XXXX

Regra XXXX

Integrações

<Identifique as interações que existem entre esse e outros casos de uso do sistema, bem como as que existirem entre esse caso de uso e outros sistemas. Essas integrações serão controladas como parte do produto e são parte integrante das definições arquiteturais. >

< Requisito de Integração Um >

<Informe uma descrição de como a integração irá funcionar, exemplos do que pode ser informado:

A integração é relativa a um outro caso de uso desse sistema, um outro sistema/software de outro projeto ou um hardware com propósito específico? ;

Descreva o propósito;

Em que circunstâncias/condições a integração será invocada? ;

Em que momento desse caso de uso a integração será invocada? ;

O que ativa e desativa a integração? ;

O que é usado/obtido de informações da integração? ;

Origem da entrada e destino da saída? ;

Existem informações que virão dessa integração e que são pré-condições para o funcionamento desse caso de uso? ;

Quais operações a integração precisa fornecer para esse caso de uso? ;

Esse caso de uso (base) passa o controle para a integração ou, se houver algum problema durante a execução da integração, esse caso de uso (base) obtém o controle novamente?>.

Pós-Condições

<A pós-condição de um caso de uso é uma lista de estados possíveis, que o sistema pode apresentar imediatamente depois do término do mesmo.>

< Pós-Condição Um >

Requisitos Especiais

< Detalha os requisitos não funcionais, aplicados apenas a esse caso de uso, ou referencia à Especificação Suplementar, no caso de requisitos aplicáveis ao sistema>

Referências

<Descreve todas as referências (memórias de reunião, atas, etc) à especificação do caso de uso.>

Observações

<Informações importantes não contidas nos demais itens.>

Aprovação

Estou de acordo com as informações e conteúdo deste documento, o qual, a partir deste momento, passa a ter o status de homologado e qualquer alteração será tratada como Solicitação de Mudança.

Concordo que este documento será o instrumento para validação das funcionalidades entregues pela Basis durante o processo de homologação, quer seja por pessoas que participaram do levantamento ou que foram delegadas para tal.

<Cidade>, <dia> de <mês> de <ano>.

<Nome Completo>

<Função - Setor>

<Nome Completo>

<Função - Setor>