Um diagrama de caso de uso é uma ferramenta fundamental de modelagem em engenharia de requisitos usado para visualizar as interações entre atores (usuários ou sistemas externos) e o sistema (ou suas funcionalidades). Ajuda os interessados a compreender o que o sistema deve fazer do ponto de vista funcional e atua como uma ponte de comunicação entre equipes técnicas e usuários do negócio.
Apesar de sua simplicidade, o diagrama de caso de uso é frequentemente mal aplicado devido à identificação inadequada de atores, casos de uso vagos ou relações incorretas. Este guia tem como objetivo esclarecer os conceitos-chave, fornecer um método passo a passo, e destacar armadilhas comuns para evitar.
| Conceito | Explicação |
|---|---|
| Ator | Um usuário humano, organização ou sistema externo que interage com o sistema. Atua como um “usuário” no contexto do sistema. Exemplos: aluno, professor, administrador, gateway de pagamento. |
| Caso de Uso | Uma descrição de um objetivo ou função específica que o sistema realiza para um ator. Define o que o que o sistema faz, não como. Exemplos: “Registrar-se em um curso”, “Enviar notas”, “Gerar relatório”. |
| Fronteira do Sistema | A fronteira que separa o sistema de atores e sistemas externos. Tudo dentro da fronteira faz parte do sistema. |
| Associação | Uma linha que conecta um ator a um caso de uso, indicando que o ator pode executar esse caso de uso. |
| Generalização | Uma relação em que um ator herda comportamento de outro (por exemplo, “Aluno” é um tipo de “Usuário”). |
| Dependência | Uma relação que indica que um caso de uso depende de outro (e |
| por exemplo, “Gerar Relatório” depende de “Obter Dados do Aluno”). | |
| Incluir | Um caso de uso que é necessário para que outro seja executado (por exemplo, “Enviar Notas” inclui “Validar ID do Aluno”). |
| Estender | Um caso de uso que condicionalmente adiciona funcionalidade (por exemplo, “Enviar Notificação” estende “Enviar Notas” quando as notas estiverem abaixo do limite). |
⚠️ Observação Importante: Casos de uso não são sobre recursos — eles são sobre objetivos funcionais que satisfazem as necessidades do usuário.
Pergunte a si mesmo estas perguntas fundamentais para identificar todos os atores relevantes:
| Pergunta | Por que Isso Importa |
|---|---|
| Quem utiliza os principais casos de uso? | Identifica os usuários principais (por exemplo, alunos, professores). |
| Quem precisa de suporte para o trabalho diário? | Identifica papéis de suporte (por exemplo, equipe de RH, suporte de TI). |
| Quem é responsável pela administração do sistema? | Identifica papéis de administração (por exemplo, gerente do sistema, administrador de banco de dados). |
| Quais dispositivos externos/sistemas de software o sistema interage? | Identifica sistemas externos (por exemplo, e-mail, gateway de pagamento, ERP). |
| Quem tem interesse nos resultados do sistema? | Identifica partes interessadas (por exemplo, pais, membros do conselho). |
📌 Dica: Comece com os usuários mais críticos e expanda para fora. Use cenários do mundo real ou entrevistas para validar a identificação dos atores.
💡 Exemplo: Em um sistema de gestão de alunos universitários, os atores podem incluir:
Aluno
Membro do corpo docente
Assessor acadêmico
Funcionário administrativo
Gateway de pagamento
Sistema ERP
Uma vez identificados os atores, faça as seguintes perguntas sobre cada um:
| Pergunta | Propósito |
|---|---|
| Quais são as principais tarefas que um ator deve realizar? | Identifica objetivos funcionais (por exemplo, registrar, matricular, visualizar notas). |
| O ator deseja consultar ou modificar dados no sistema? | Indica operações de leitura/escrita (por exemplo, visualizar registros, editar perfil). |
| O ator deseja informar o sistema sobre mudanças em outros sistemas? | Sugere gatilhos baseados em eventos (por exemplo, notificar o sistema quando um curso for adicionado). |
| O ator deveria ser informado sobre eventos imprevistos? | Indica casos de uso de notificação (por exemplo, “Alerta: Sobrecarga de Curso Detectada”). |
📌 Use linguagem simples e orientada a objetivos. Evite termos técnicos.
✅ Caso de uso bom: “Inscrição em um Curso”
❌ Caso de uso ruim: “Enviar formulário de inscrição com validação” → torna-se muito técnico.
Os casos de uso podem ser modelados em diferentes níveis:
| Nível | Descrição |
|---|---|
| Casos de uso de nível superior | Objetivos funcionais amplos que refletem metas de negócios (por exemplo, “Gerenciar registros de alunos”). |
| Casos de uso refinados | Ações detalhadas derivadas dos objetivos de nível superior. |
🔁 Abordagem de desenvolvimento iterativo:
Comece com objetivos de negócios de alto nível.
Divida-os em sub-objetivos.
Refine cada caso de uso até que seja específico e passível de ação.
📌 Exemplo de divisão:
Nível superior: “Apoiar a administração de alunos”
Refinamento:
O aluno pode se registrar
O aluno pode se inscrever em cursos
O sistema armazena notas
O sistema envia confirmação de inscrição
Isso garante que o sistema atendaobjetivos comerciaisenquanto permaneceprático e testável.
Agora, coloque atores e casos de uso no diagrama e conecte-os adequadamente.
[Ator] --> [Caso de Uso]
↑
[Incluir] [Estender]
↓
[Dependência]
Coloque os atores fora da fronteira do sistema (normalmente à esquerda/direita/acima).
Coloque os casos de uso dentro da fronteira do sistema (centro ou abaixo).
Use linhas sólidas para associações.
Use linhas tracejadas para dependências.
Use setas de inclusão (→) para incluir relacionamentos.
Use setas de extensão (→) para estender relacionamentos.
Evite casos de uso sobrepostos; mantenha o diagrama limpo e legível.
📌 Exemplo Visual (Baseado em Texto):
+------------------+
| Aluno | --> Inscrever-se em Curso
+------------------+
|
v
+------------------+
| Sistema | --> Armazenar Inscrições em Cursos
| (Fronteira) |
+------------------+
^
|
+------------------+
| Gateway de Pagamento| --> Processar Pagamento de Taxa
+------------------+
🚨 Erro Comum: Desenhar atores dentro da fronteira do sistema — isso implica que eles fazem parte do sistema, o que não é verdade.

Este diagrama foi gerado pelo chatbot AI do Visual Paradigm:

| Armadilha | Por que está errado | Como corrigir |
|---|---|---|
| 🚫 Sobrecomplicar atores | Criar muitos atores (por exemplo, “João Silva”, “Sarah Smith”) em vez de agrupar papéis | Agrupe papéis semelhantes (por exemplo, “Aluno”, “Docente”) |
| 🚫 Usar casos de uso vagos | Frases como “gerenciar dados”, “fazer algo” | Substitua por frases específicas e orientadas a objetivos (por exemplo, “Enviar inscrição em curso”) |
| 🚫 Dependências ausentes | Não mostrar como um caso de uso depende de outro | Adicione incluir ou estender relacionamentos quando necessário |
| 🚫 Uso incorreto de ‘estender’ | Usando estender para fluxos de trabalho normais |
Use incluir para etapas obrigatórias; use estender apenas para os opcionais e condicionais |
| 🚫 Ignorando sistemas externos | Não incluindo gateways de pagamento, e-mail, etc. | Identifique todos os sistemas externos e mostre suas interações |
| 🚫 Usando apenas um ator | Supondo que apenas um usuário use o sistema | Identifique todos os interessados e suas necessidades |
| 🚫 Usando jargão técnico | por exemplo, “Atualizar banco de dados”, “chamar API” | Mantenha-se em comportamentos funcionais — “Enviar um pedido” é melhor |
| Prática | Explicação |
|---|---|
| ✅ Comece com objetivos de negócios | Modele de cima para baixo — alinhe-se aos objetivos estratégicos. |
| ✅ Envolve os interessados cedo | Interviewe usuários finais ou especialistas de domínio para validar os casos de uso. |
| ✅ Mantenha os casos de uso independentes | Cada caso de uso deve representar um único objetivo claro. |
| ✅ Use cenários do mundo real | Baseie os casos de uso em atividades reais dos usuários (por exemplo, um aluno se matriculando em uma aula). |
| ✅ Validar com a equipe | Revisar o diagrama com desenvolvedores, testadores e analistas de negócios. |
| ✅ Atualizar de forma iterativa | À medida que os requisitos evoluem, aprimore o diagrama em ciclos menores. |
| ✅ Documentar os casos de uso em detalhe | Inclua pré-condições, pós-condições e critérios de sucesso/falha em um documento separado. |
[30] Engenharia de Requisitos – Texto fundamental sobre modelagem de casos de uso.
[27] Identificação de Casos de Uso em Requisitos de Software – Métodos práticos para derivar casos de uso a partir de atores.
[16, 40] – Literatura abrangente sobre engenharia de requisitos e design de sistemas.
Padrões IEEE/ISO: ISO/IEC 29148 – Diretrizes para especificação de casos de uso.
Livros recomendados:
Requisitos de Software: Obtendo o certo da primeira vez por Ian Sproul
O Processo de Desenvolvimento de Software Unificado (RUP) – Introduz a modelagem de casos de uso em UML
Membro
Bibliotecário
Administrador
Sistema de Catálogo Online
Gateway de Pagamento
Membro:
Pegar um livro
Devolver um livro
Pesquisar livros
Visualizar status de associação
Bibliotecário:
Retirar livros
Devolver livros
Atualizar registros de livros
Gerar lista de atrasos
Administrador:
Adicionar novos livros
Gerenciar contas de usuários
Gerar relatório anual
Sistema de Catálogo Online:
Pesquisar livros
Notificar o membro sobre novos chegados
Gateway de Pagamento:
Processar multas
Processar taxas de renovação
Membro → Pegar → Incluir → Devolver
Bibliotecário → Retirar → Prorrogar → Enviar lembrete (se atrasado)
Administrador → Adicionar Livro → Incluir → Atualizar Catálogo
Este diagrama mostra claramente quem faz o quê, o que eles podem fazer e como os sistemas interagem.
✅ Identifiquei todos os atores relevantes?
✅ Os casos de uso são descritivos e orientados a objetivos?
✅ Todos os atores estão conectados a pelo menos um caso de uso?
✅ As dependências (incluir/estender) estão corretamente modeladas?
✅ Há algum ator ou caso de uso faltando?
✅ O diagrama é fácil de ler e entender?
✅ Eu revisei com os interessados?
Criar um diagrama de casos de uso é mais do que desenhar linhas e caixas — é um processo estratégico que exige profundo entendimento das necessidades dos usuários, clareza na linguagem, e atenção aos detalhes.
Embora o diagrama pareça simples, uso incorreto de atores e casos de uso leva a um mau design do sistema, requisitos perdidos e usuários frustrados. Ao seguir os passos deste guia — identificar atores por meio de perguntas do mundo real, derivar casos de uso das necessidades dos atores e evitar armadilhas comuns — você pode criar diagramas de casos de uso precisos, acionáveis e alinhados aos interessados.
✅ Lembre-se: Um bom diagrama de casos de uso conta uma história — a história de como os usuários interagem com o sistema para alcançar seus objetivos.