<Nome do Sistema>

<Caso de Uso>

Histórico de Revisões
Data Versão Descrição Autor
<dd/mm/aaaa> <x.x> <detalhes> <nome>
 Índice
Caso de uso <Nome do Caso de Uso 1> 3

1. Id do Caso de Uso 3

2. Atores 3

3. Sumário 3

4. Pré Condições 3

5. Fluxo de Eventos 3
5.1 Fluxo Principal 3
5.2 Fluxos Alternativos 3
5.2.1 < FA001 Primeiro Fluxo Alternativo > 3
5.2.2 < FA002 Segundo fluxo alternativo > 3
5.3 Fluxos de Exceções 3
5.3.1 < FE001 Primeiro Fluxo de Exceção > 3
5.3.2 < FE002 segundo Fluxo de Exceção > 3

6. Pós Condições 4

7. Documentação Suplementar 4
7.1 Regras de negócios 4
7.2 Requisitos não-funcionais 4
7.3 Interface Externa (telas e relatórios) 4
7.3.1 Leiaute sugerido (desenho da tela) Error! Bookmark not defined.
7.4 Critérios de aceitação do Requisito Error! Bookmark not defined.
 Descrição de Caso de Uso – <XXXXXXXX>

Caso de uso <Nome do Caso de Uso >

[Inserir no título da seção o nome do Caso de Uso, substituindo todo o texto acima]

1. Id do Caso de Uso
[UCxx Identificação única do Caso de Uso]

2. Atores
[lista dos atores utilizados no caso de uso]

3. Sumário
[Escreva uma breve descrição do papel e objetivo do caso de uso. Um único parágrafo deve ser suficiente.]

4. Pré Condições
[Uma pré condição de um requisito é o estado em que o sistema deve estar antes da execução do requisito.]

5. Fluxo de Eventos
5.1 Fluxo Principal
[O requisito descreve a troca de informações, ou seja, o que é enviado ao sistema e o que é retornado pelo
sistema. Deve ser descrito o que acontece dentro do sistema, mas não como ou por que.
Exemplo:
Esse caso de uso começa quando....
1. usuário ....
2. sistema ...
Os atores devem ser colocados como sujeito de cada passo. ]

5.2 Fluxos Alternativos

5.2.1 < FA001 Primeiro Fluxo Alternativo >
[Pense na subsessão Fluxo Alternativo como um comportamento alternativo – cada fluxo alternativo
representa comportamento alternativo normalmente relacionado a exceções que ocorram em relação ao
fluxo básico. Os fluxos alternativos podem ser tão compridos quanto necessário para descrever os eventos
associados ao comportamento alternativo. Quando um fluxo alternativo termina, o “controle” volta ao
fluxo básico exceto de explicitamente definido de outra forma.]
5.2.2 < FA002 Segundo fluxo alternativo >
[Pode haver, e freqüentemente haverá, uma certa quantidade de fluxos alternativos num requisito.
Mantenha cada fluxo alternativo separado, para aumentar a clareza. Tenha em mente que requisitos são
apenas descrições textuais, e que seu principal objetivo é documentar o comportamento do sistema de
forma clara e concisa.]

5.3 Fluxos de Exceções

[Um fluxo de exceção mostra alternativas para erros ou mensagens de exceção do caso de uso.]
5.3.1 < FE001 Primeiro Fluxo de Exceção >
[primeira exceção]
5.3.2 < FE002 segundo Fluxo de Exceção >
[primeira exceção]
6. Pós Condições
[Uma pós condição de um requisito é uma lista de estados possíveis em que o sistema pode estar
imediatamente após a execução do requisito.]

7. Documentação Suplementar
7.1 Regras de negócios
[Regras de negócios especídificas ao caso de uso. Colocar as referências das regras de negócio descritas
no documento principal]

7.2 Requisitos não-funcionais

[Requisitos não-funcionais específicos ao caso de uso. Colocar as referências das regras de negócio
descritas no documento principal]

7.3 Interface Externa (telas e relatórios)

[ Usabilidade, que envolve fatores como humanos, estética, consistência da interface do usuário, ajuda
on-line sensível ao contexto, wizards, documentação de usuário e material de treinamento..]
[Mostrar o desenho das interfaces do caso de uso.]