<Nome do Projeto>

Especificação de Caso de Uso: <Nome do Caso de Uso> Versão <número da versão>

<Nome do Projeto>
Especificação de Caso de Uso: <Nome do Caso de
Uso>

Versão <número da versão>

Os textos que aparecem em azul e entre colchetes são explicações para ajudar no preenchimento de
cada seção e devem ser apagados no documento final.

Histórico de Revisão

Data Versão Descrição Autor

[Na coluna Autor, deve-se especificar o nome dos autores e sua equipe, responsáveis pelas alterações.
Na coluna descrição, deve-se especificar exatamente o que foi mudado. Não devem ser colocadas informações
vagas como, por exemplo, "Alterações realizadas depois da reunião x".]

Página 5 de 6
 <Nome do Projeto>
Especificação de Caso de Uso: <Nome do Caso de Uso> Versão <número da versão>

Sumário
1. Descrição 4

2. Pré-condições 4

3. Fluxo de Eventos 4
3.1 Fluxo Básico 4
3.2 Subfluxos 4
3.2.1 (S01) – <Nome do Subfluxo> 4
3.3 Fluxos Alternativos 5
3.3.1 (A01) – <Nome do Fluxo Alternativo> 5
3.4 Exceções 5
3.4.1 (E01) – <Nome do Fluxo de Exceção> 5

4. Pós-condições 5

5. Requisitos Especiais 5
5.1 (RE01) - <Nome do Requisito Especial> 5

6. Regras de negócio específicas 6

6.1 (RN01) - <Nome da Regra de Negócio > 6

7. Detalhamento das Interfaces com Usuários 6

7.1 (I01) - <Nome da Interface com Usuário> 6
7.1.1 Imagem 6
7.1.2 Campos 6
7.1.3 Comandos 6

8. Demais Interfaces 7
8.1 Interfaces de Software 7
8.2 Interfaces de Hardware 7

9. Observações 7

Página 5 de 6
 <Nome do Projeto>
Especificação de Caso de Uso: <Nome do Caso de Uso> Versão <número da versão>

Especificação de Caso de Uso: <Nome do Caso de

Uso>

1. Descrição
[A descrição deve resumir o papel e finalidade do caso de uso. Um único parágrafo deve bastar para
esta descrição.]

2. Pré-condições
[A pré-condição de um caso de uso é o estado que o sistema deve apresentar antes do caso de uso ser
executado.]

3. Fluxo de Eventos
1. Fluxo Básico
[Este caso de uso começa quando o ator faz algo. Um ator sempre inicia o caso de uso. O caso de uso
deve descrever o que o ator faz e o que o sistema faz como resposta. 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 ou porque. Se há troca
de informação, seja específico sobre o que é passado para o sistema e vice-versa. Por exemplo, não é
muito esclarecedor dizer que o ator digita a informação do cliente; é melhor dizer que o ator informa
o nome e o endereço do cliente.
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. Se os fluxos alternativos forem mais complexos, use uma
seção separada para descrevê-los.
Uma imagem é, às vezes, melhor que mil palavras. Se melhorar a clareza, use à vontade gráficos de
interface de usuário, fluxo de processo, ou outras figuras no caso de uso. Se um diagrama de fluxo for
útil para apresentar um processo de decisão complexo, use-o. Similarmente para um comportamento
dependente de estado, um diagrama de transição de estados freqüentemente esclarece o
comportamento do sistema melhor do que páginas e páginas de texto. Use a melhor forma para
representar seu problema, mas cuidado para não usar terminologia, notação ou figura que sua
audiência não possa compreender. Lembre-se que sua finalidade é esclarecer, não confundir.]
1.
1.
2.

2. Subfluxos
1. (S01) – <Nome do Subfluxo>
[O fluxo básico pode ser quebrado em subseções, para aumentar a clareza. Os subfluxos descrevem
geralmente detalhes de iterações ou de condições executadas com maior freqüência. Os subfluxos são
referenciados dentro dos passos do fluxo principal, de outros subfluxos ou de fluxos alternativos.
Quando um subfluxo termina, os eventos do fluxo original são recomeçados, ou seja, o fluxo retorna
ao ponto em que estava quando o subfluxo havia sido chamado, a menos que indicado de outra
maneira.]
1.
1.
2.
3.

Página 5 de 6
 <Nome do Projeto>
Especificação de Caso de Uso: <Nome do Caso de Uso> Versão <número da versão>

3. Fluxos Alternativos
1. (A01) – <Nome do Fluxo Alternativo>
[Alternativas opcionais executadas com menor freqüência são descritas em uma seção separada como
fluxo alternativo. Os fluxos alternativos não são referenciados dentro de outros fluxos; suas próprias
pré-condições definem quando eles são ativados. Diferente do subfluxo, quando o fluxo alternativo
termina,nem sempre os eventos do fluxo original são retomados no mesmo ponto em que estava
quando o fluxo alternativo havia sido ativado. Sendo assim é necessário indicar o ponto de retomada
do fluxo.
Pode haver, e normalmente haverá, um certo número de fluxos alternativos em um caso de uso.
Mantenha cada um separado para melhorar a clareza. O uso de fluxos alternativos melhora a
legibilidade do caso de uso e previne que os casos de uso sejam decompostos em hierarquias.]
1. Pré-condições
[Para cada fluxo alternativo é preciso levantar as suas pré-condições, ou seja, as condições que se
supõem estejam satisfeitas ao iniciar a execução do fluxo. As pré-condições indicam em que condições
este fluxo alternativo é chamado, ou seja, o que é preciso acontecer para ele ser chamado.]
2. Passos
1.
2.
3.

4. Exceções
1. (E01) – <Nome do Fluxo de Exceção>
[Existem fluxos alternativos que representam na verdade situações de exceção do caso de uso. Nesse
caso, é interessante documentar separadamente para identificá-las de forma mais clara e rápida.]
1. Pré-condições
[As pré-condições de um fluxo de Exceção é o estado do sistema que permitiu identificar a exceção.]
2. Passos
1.
2.
3.

4. Pós-condições
[A pós-condição de um caso uso é uma lista de estados possíveis que o sistema pode apresentar
imediatamente após o término do caso de uso.]
5. Requisitos Especiais
[O requisito especial é tipicamente um requisito não funcional específico do caso de uso ou que o
influencie. Deve ser descrito aqui quando não puder ser especificado facilmente ou naturalmente no
texto do fluxo de eventos do caso de uso. Os exemplos de requisitos especiais incluem requisitos
legais, padrões da aplicação, atributos da qualidade do sistema a ser construído como usabilidade,
confiabilidade, desempenho.
Requisitos relativos a ambiente e arquitetura como sistemas operacionais, ambientes, exigências
relativas a compatibilidade, restrições de desenho, devem ser também descritos.]
1. (RE01) - <Nome do Requisito Especial>

6. Regras de negócio específicas

[Registrar aqui as regras de negócio que são levantadas no detalhamento do caso de uso, evitando
assim registrá-las ao longo dos fluxos, visando aumentar a legibilidade e clareza. Além disso, regras
complexas devem ser subdividas em mais de uma. Toda regra de negócio deve ser referenciada ao

Página 5 de 6
 <Nome do Projeto>
Especificação de Caso de Uso: <Nome do Caso de Uso> Versão <número da versão>

longo dos fluxos do caso de uso.]

1. (RN01) - <Nome da Regra de Negócio >

7. Detalhamento das Interfaces com Usuários

[Inserir nesta seção os esboços das interfaces vinculadas ao caso de uso em questão. O esboço das
interfaces auxilia na validação dos casos de uso com os usuários, pois estes conseguem visualizar
melhor o sistema ao verem algo mais concreto.]
1. (I01) - <Nome da Interface com Usuário>
1. Imagem
[Inserir a imagem do esboço da interface.]
2. Campos
[Preencher a tabela com os campos presentes na interface e sua descrição. Por exemplo:
● Nome: Login, Senha, Endereço, etc
● Descrição: Descrição completa do endereço do usuário incluindo rua, número, cidade,
cep e pais, etc.
● Valores Válidos: Maior que zero,Entre 5 e 10, etc. .
● Tipo: Moeda, Inteiro, Texto, Data, etc.
● Restrições: Valor default 001, Obrigatório / Alterável; Calculado pelo sistema / Não
Alterável, Formato até 50 caracteres, até 5 dígitos, 10 dígitos e duas casas decimais,
DD/MM/AAAA, etc.]
No. Nome Descrição Valores Tipo Restrições
Válidos

3. Comandos
[Preencher a tabela com os comandos presentes na interface e sua descrição. Por exemplo:
● Nome: Ok, Pesquisar, Consultar, Excluir, etc.
● Ação: Localiza e exibe os dados de um usuário já cadastrado, Exclui um usuário do
sistema, etc.
● Restrições: Sempre habilitado, Habilitado se algum registro estiver selecionado, etc.]
No. Nome Ação Restrições

8. Demais Interfaces
[Esta seção define as interfaces que devem ser suportadas pela aplicação.]
1. Interfaces de Software
[Descreve interfaces de software para outros componentes de negócio do sistema. Podem ser
componentes comprados, componentes reusados e/ou componentes desenvolvidos para subsistemas
fora do escopo mas, que interagem com o sistema. Não incluir aqui interfaces com componentes de
infra-estrutura. Esses devem ser referenciados no Documento de Arquitetura.]
No. Nome Ator Descrição

Página 5 de 6
 <Nome do Projeto>
Especificação de Caso de Uso: <Nome do Caso de Uso> Versão <número da versão>

2. Interfaces de Hardware
[Descreve quaisquer interfaces de hardware que são suportadas pelo software, incluindo estrutura
lógica endereço físico, comportamento esperado, etc.]
No. Nome Hardware Descrição

9. Observações
[Seção de preenchimento livre, onde podem ser colocadas informações importantes não registradas
nas outras seções. Pode-se registrar, por exemplo:
● lembretes e informações que serão necessárias, mas que ainda não estão sendo utilizadas, para
que não sejam perdidas informações já levantadas,
● pessoas ou documentos que serviram de fonte para a especificação do caso de uso,
● etc.]

Página 5 de 6