Posted inUML

Guia Completa sobre a Elaboração de Casos de Uso: Conceitos-Chave, Métodos e Exemplos

Introdução

Elaboração de Casos de Uso é uma fase crítica no ciclo de vida do desenvolvimento de software, particularmente no contexto da engenharia de requisitos e da análise e design orientados a objetos. Ela pontua a lacuna entre casos de uso de alto nível e especificações detalhadas do sistema, permitindo que desenvolvedores, analistas e partes interessadas compreendamcomoum sistema se comporta em resposta a objetivos específicos do usuário.

Este guia fornece uma visão abrangente deelaboração de casos de uso, incluindo seu propósito, conceitos-chave, metodologia passo a passo, melhores práticas e exemplos do mundo real.

1. O que é Elaboração de Casos de Uso?

Elaboração de Casos de Usoé o processo de aprimorar um caso de uso de alto nível em uma descrição detalhada e acionável do comportamento do sistema. Ele transforma uma narrativa simples de interação do usuário em uma especificação precisa, testável e implementável.

✅ Objetivo: Definiro queo sistema deve fazer,comodeve fazê-lo esob quais condições, com detalhes suficientes para desenvolvimento e teste.

2. Por que a Elaboração de Casos de Uso é Importante

  • Reduz a Ambiguidade: Evita a interpretação incorreta dos requisitos.

  • Melhora a Rastreabilidade: Liga requisitos ao design, código e casos de teste.

  • Apoia o Design e a Implementação: Fornece uma base para diagramas de classes, diagramas de sequência e design de banco de dados.

  • Permite o Teste: Facilita a criação de cenários de teste e critérios de aceitação.

  • Melhora a Colaboração: Garante o entendimento compartilhado entre partes interessadas, desenvolvedores e testadores.

3. Conceitos Principais na Elaboração de Casos de Uso

3.1 Caso de Uso (CU)

Um caso de uso descreve uma sequência de ações que um sistema realiza para gerar um resultado valioso para um ator (um usuário ou sistema externo).

Exemplo: “Sacar Dinheiro” de um caixa eletrônico.

3.2 Ator

Uma entidade externa que interage com o sistema. Pode ser um usuário humano, outro sistema ou um disparador por tempo.

Exemplo: Cliente, Máquina de Caixa Eletrônico, Gateway de Pagamento.

3.3 Ator Primário e Ator Secundário

  • Ator Primário: Inicia o caso de uso.

  • Ator Secundário: Apoia o ator primário (por exemplo, um servidor bancário).

3.4 Pré-condições

Condições que devem ser verdadeiras antes que o caso de uso possa começar.

Exemplo: O usuário deve possuir um cartão válido e um PIN correto.

3.5 Pós-condições

Condições que devem ser verdadeiras após o caso de uso ser concluído.

Exemplo: O dinheiro é dispensado, o saldo da conta é atualizado.

3.6 Cenário Principal de Sucesso (Fluxo Básico)

O caminho mais comum no caso de uso que leva ao sucesso.

Exemplo: Inserir cartão → Digitar PIN → Selecionar saque → Digitar valor → Receber dinheiro.

3.7 Fluxos Alternativos (Fluxos de Exceção)

Ramificações no caso de uso que lidam com exceções, erros ou variações.

Exemplo: PIN inválido → Tentar novamente ou cancelar.

3.8 Extensões

Pontos no fluxo principal onde pode ser inserido um comportamento alternativo (por exemplo, por meio de “<>” no UML).

Exemplo: “<>: Notificar o banco sobre atividade suspeita.”

3.9 Requisitos Não Funcionais (RNFs)

Restrições sobre o comportamento do sistema (por exemplo, desempenho, segurança, usabilidade).

Exemplo: “A transação deve ser concluída em até 3 segundos.”

4. O Processo de Elaboração de Casos de Uso (Passo a Passo)

Etapa 1: Identificar o Caso de Uso

Comece com um caso de uso de alto nível (por exemplo, “Fazer Pedido”).

Use um modelo:
Nome do Caso de Uso: Fazer Pedido
Ator Principal: Cliente
Interessados: Cliente, Sistema de Gestão de Pedidos, Gateway de Pagamento

Etapa 2: Definir Pré-condições

Liste todas as condições que devem ser atendidas antes do início do caso de uso.

  • O cliente está logado.

  • O carrinho de compras contém pelo menos um item.

  • O método de pagamento está salvo.

Etapa 3: Definir Pós-condições

Indique o que deve ser verdadeiro após a conclusão do caso de uso.

  • O pedido é criado no sistema.

  • O estoque é atualizado.

  • O pagamento é processado.

  • Um e-mail de confirmação é enviado.

Etapa 4: Escrever o Cenário Principal de Sucesso (Fluxo Básico)

Detalhe o caminho ideal e bem-sucedido.

  1. O cliente seleciona “Finalizar Compra” no carrinho de compras.

  2. O sistema exibe o resumo do pedido.

  3. O cliente confirma o endereço de entrega.

  4. O cliente seleciona o método de pagamento.

  5. O sistema processa o pagamento.

  6. O pagamento é confirmado.

  7. O sistema cria o pedido e gera a confirmação.

  8. A confirmação é exibida e um e-mail é enviado.

Etapa 5: Identificar fluxos alternativos (fluxos de exceção)

Liste as possíveis desvios em relação ao fluxo principal.

Fluxo Alternativo A: Estoque Insuficiente

  1. O sistema verifica o estoque.

  2. O item está esgotado.

  3. O sistema exibe a mensagem: “Item indisponível.”

  4. O cliente pode remover o item ou continuar sem ele.

Fluxo Alternativo B: Pagamento Recusado

  1. O pagamento é rejeitado.

  2. O sistema exibe o erro: “Pagamento recusado.”

  3. O cliente pode tentar novamente ou escolher outro método.

Fluxo Alternativo C: Endereço de Entrega Inválido

  1. O sistema valida o endereço.

  2. O endereço é inválido.

  3. O sistema solicita ao cliente que corrija o endereço.

Etapa 6: Definir Extensões (Relacionamentos <>)

Use extensões do estilo UML para mostrar comportamento opcional.

  • <>: Notificar o Sistema de Estoque

    • Gatilho: Quando um item está esgotado durante o checkout.

    • Propósito: Alertar o armazém para reabastecer.

  • <>: Aplicar Cupom de Desconto

    • Gatilho: O cliente insere um código de cupom válido.

    • Propósito: Reduzir o custo total.

Etapa 7: Adicionar Requisitos Não Funcionais (RNFs)

Inclua as restrições do sistema.

  • O pedido deve ser processado em até 5 segundos.

  • O pagamento deve ser criptografado usando TLS 1.3.

  • O sistema deve suportar 10.000 usuários simultâneos.

Passo 8: Revisar e Validar

Colabore com os interessados para garantir completude e precisão.

  • Pergunte: “Isso cobre todas as metas do usuário?”

  • Pergunte: “Todos os casos extremos foram considerados?”

  • Pergunte: “Um desenvolvedor consegue construir a partir disso?”

5. Ferramentas e Técnicas para Elaboração

Ferramenta/Técnica Propósito
Diagrama de Caso de Uso (UML) Visualize atores e casos de uso.
Diagrama de Sequência Mostre o fluxo de mensagens entre objetos durante o caso de uso.
Diagrama de Atividade Modelar fluxos de trabalho complexos e pontos de decisão.
Mapeamento de Histórias de Usuário Conecte casos de uso à jornada do usuário e prioridades.
Tabelas de Decisão Clarear lógica complexa (por exemplo, regras de desconto).

6. Melhores Práticas

  1. Mantenha os Casos de Uso Focados no Usuário: Foque nas metas do usuário, não nos recursos do sistema.

  2. Use Nomenclatura Consistente: Use o formato verbo-substantivo (por exemplo, “Atualizar Perfil”).

  3. Evite Jargões Técnicos: Escreva para interessados não técnicos.

  4. Use Linguagem Clara: Seja claro e conciso.

  5. Iterar: Refineça os casos de uso conforme o entendimento aumenta.

  6. Link para Outros Artefatos: Conecte casos de uso a diagramas de classes, casos de teste e histórias de usuários.

  7. Priorize: Foque primeiro nos casos de uso de alto valor ou alto risco.

7. Exemplo do Mundo Real: Banco Online – Transferir Dinheiro

Caso de Uso: Transferir Dinheiro

Ator Principal: Cliente
Ator Secundário: Servidor do Banco, Sistema de Detecção de Fraude

Pré-condições

  • O cliente está logado.

  • A conta de origem possui fundos suficientes.

  • O limite de transferência não foi ultrapassado.

Pós-condições

  • Os fundos são transferidos da conta de origem para a conta de destino.

  • A transação é registrada em ambas as contas.

  • Uma notificação é enviada para ambas as partes.

Cenário Principal de Sucesso

  1. O cliente seleciona “Transferir Dinheiro” no painel.

  2. O sistema exibe o formulário de transferência.

  3. O cliente insere a conta de destino e o valor.

  4. O sistema valida a conta e o valor.

  5. O cliente confirma a transferência.

  6. O sistema verifica as regras de detecção de fraude.

  7. A transação é aprovada e executada.

  8. Uma mensagem de confirmação é exibida.

Fluxos Alternativos

  • A1: Fundos Insuficientes
    → O sistema exibe: “Fundos insuficientes.”
    → O cliente pode cancelar ou ajustar o valor.

  • A2: Fraude Detectada
    → O sistema bloqueia a transferência e envia um alerta.
    → O cliente deve verificar por meio de 2FA ou entrar em contato com o suporte.

  • A3: Conta de Destino Inválida
    → O sistema exibe: “Conta não encontrada.”
    → O cliente pode reentrar ou usar a pesquisa de conta.

Extensões

  • <>: Enviar Notificação ao Destinatário

    • Gatilho: Transferência concluída.

    • Propósito: Informar o destinatário.

  • <>: Aplicar Taxa de Transferência

    • Gatilho: Valor da transferência > $1.000.

    • Propósito: Deduzir taxa de $5.

Requisitos Não-Funcionais

  • Todas as transferências devem ser registradas e auditáveis.

  • Tempo de resposta ≤ 2 segundos.

  • Dados criptografados em trânsito e em repouso.

8. Armadilhas Comuns e Como Evitá-las

Armadilha Solução
Muito vago (por exemplo, “O sistema deve processar pedidos”) Use ações específicas e mensuráveis.
Linguagem excessivamente técnica Use linguagem natural; evite termos de código ou banco de dados.
Caminhos de exceção ausentes Use fluxos alternativos para cobrir falhas.
Critérios de sucesso não claros Defina os pós-condições claramente.
Sem revisão de partes interessadas Envolve usuários, testadores e analistas de negócios.

9. Conclusão

A elaboração de casos de uso não é apenas um exercício de documentação—é um processo estratégico que garante que o sistema atenda às necessidades reais dos usuários com clareza, precisão e completude. Expandindo sistematicamente os casos de uso de alto nível em especificações detalhadas e passíveis de ação, as equipes reduzem riscos, melhoram a comunicação e estabelecem uma base sólida para a entrega bem-sucedida de software.

✅ Dica Final: Trate a elaboração de casos de uso como uma conversa iterativa—não como uma tarefa única. Aprimore-a conforme você aprender mais sobre o sistema e seus usuários.

Apêndice: Modelo para Elaboração de Casos de Uso

# Nome do Caso de Uso: [por exemplo, Atualizar Perfil]

**Ator Principal**: [por exemplo, Cliente]  
**Ator(s) Secundário(s)**: [por exemplo, Banco de Dados, Serviço de E-mail]  
**Partes Interessadas**: [por exemplo, Cliente, Equipe de Suporte]

### Pré-condições
- [Liste as condições]

### Pós-condições
- [Liste os resultados]

### Cenário Principal de Sucesso (Fluxo Básico)
1. [Passo 1]  
2. [Passo 2]  
...

### Fluxos Alternativos
- **A1: [Nome]**  
  1. [Passo]  
  2. [Passo]  
- **A2: [Nome]**  
  ...

### Extensões (<<extend>>)
- **<<extend>>: [Nome]**  
  - Disparador: [Quando]  
  - Propósito: [Por quê]

### Requisitos Não-Funcionais
- [Desempenho, Segurança, Usabilidade, etc.]

### Observações
- [Contexto adicional ou suposições]

Ao seguir este guia, as equipes podem dominar a arte da elaboração de casos de uso e construir sistemas que não são apenas funcionais, mas verdadeiramente alinhados às expectativas dos usuários.

Apêndice – Descrição do Caso de Uso para Saque de Dinheiro em um Caixa Eletrônico:

Nome do Caso de Uso

Sacar Dinheiro

Ator Principal

Cliente (titular da conta bancária)

Atores Secundários

  • Máquina de Caixa Eletrônico

  • Servidor Bancário (Sistema Bancário Central)

  • Gateway de Pagamento (para processamento de transações)

  • Sistema de Detecção de Fraude

  • Impressora (para geração de comprovante)

Partes Interessadas e Interesses

  • Cliente: Deseja sacar dinheiro de forma segura e eficiente.

  • Banco: Garante a integridade da transação, prevenção de fraudes e atualizações precisas da conta.

  • Operador do Caixa Eletrônico: Mantém a disponibilidade da máquina e o estoque de dinheiro.

  • Equipe de Segurança: Monitora comportamentos suspeitos e previne fraudes.

Pré-condições

  1. O cliente possui um cartão bancário válido inserido na máquina.

  2. O cliente se autenticou com sucesso (digitou o PIN correto).

  3. A conta do cliente está ativa e não bloqueada.

  4. A máquina possui dinheiro suficiente no cofre.

  5. A conta do cliente possui saldo disponível suficiente.

  6. O limite diário de saque não foi ultrapassado.

Pós-condições

  1. O valor solicitado em dinheiro é entregue ao cliente.

  2. O saldo da conta do cliente é reduzido pela quantia sacada.

  3. Um registro de transação é criado no sistema do banco.

  4. Um comprovante é impresso (se solicitado).

  5. A máquina registra a transação para auditoria e reconciliação.

Cenário Principal de Sucesso (Fluxo Básico)

Passo Ação do Sistema Resposta do Ator
1 Máquina solicita: “Por favor, digite seu PIN.” Cliente digita o PIN.
2 A máquina valida o PIN com o servidor do banco. O sistema confirma que o PIN está correto.
3 A máquina exibe o menu principal: “Sacar Dinheiro, Ver Saldo, Transferir, Sair.” Cliente seleciona “Sacar Dinheiro.”
4 Máquina solicita: “Digite o valor a sacar.” O cliente insere o valor (por exemplo, $100).
5 O caixa eletrônico valida:

  • O valor está dentro do limite diário.

  • A conta possui fundos suficientes.

  • O caixa eletrônico tem dinheiro suficiente. | O sistema confirma a validade. |
    | 6 | O caixa eletrônico solicita autorização ao servidor do banco. | O servidor do banco aprova a transação. |
    | 7 | O caixa eletrônico dispensa dinheiro do cofre. | O cliente recebe o dinheiro. |
    | 8 | O caixa eletrônico exibe: “Deseja um comprovante?” | O cliente seleciona “Sim” ou “Não”. |
    | 9 | Se “Sim”: o caixa eletrônico imprime o comprovante com:

  • Data/hora

  • Valor sacado

  • Saldo restante

  • ID da transação | O cliente coleta o comprovante. |
    | 10 | O caixa eletrônico exibe: “Obrigado. Por favor, retire seu cartão.” | O cliente retira o cartão. |
    | 11 | O caixa eletrônico retorna ao estado ocioso. | O sistema é reiniciado. |

✅ Resultado de sucesso: O cliente recebe o dinheiro e (opcionalmente) um comprovante. A conta é atualizada.

Fluxos alternativos (cenários de exceção)

A1: PIN inválido inserido (3 tentativas)

  • Gatilho: O cliente insere PIN incorreto três vezes.

  • Ação do sistema: O caixa eletrônico bloqueia o cartão e exibe: “Cartão bloqueado. Entre em contato com seu banco.”

  • Ação do ator: O cliente sai e entra em contato com o banco.

  • Pós-condição: O cartão é temporariamente bloqueado; a transação é registrada.

⚠️ Observação: Esta é uma medida de segurança para impedir o acesso não autorizado.

A2: Fundos Insuficientes

  • Gatilho: O cliente insere um valor superior ao saldo disponível.

  • Ação do Sistema: O ATM exibe: “Fundos insuficientes. Saldo atual: $X.”

  • Ação do Ator: O cliente seleciona “Cancelar” ou insere um valor menor.

  • Pós-condição: Nenhum dinheiro dispensado; nenhum alteração na conta.

A3: Caixa do ATM Insuficiente

  • Gatilho: O cliente insere um valor válido, mas o cofre do ATM está vazio ou abaixo do mínimo.

  • Ação do Sistema: O ATM exibe: “Dinheiro indisponível. Por favor, tente novamente mais tarde.”

  • Ação do Ator: O cliente cancela ou retorna mais tarde.

  • Pós-condição: Transação não processada; nenhuma alteração na conta.

A4: Valor de Saque Excede o Limite Diário

  • Gatilho: O cliente tenta sacar mais do que o limite diário (por exemplo, $1.000).

  • Ação do Sistema: O ATM exibe: “Excede o limite diário de saque. Tente um valor menor.”

  • Ação do Ator: O cliente reduz o valor ou cancela.

  • Pós-condição: Transação não processada.

A5: Transação Recusada pelo Servidor do Banco

  • Gatilho: O servidor do banco rejeita a transação (por exemplo, devido a alerta de fraude, congelamento de conta).

  • Ação do Sistema: O caixa eletrônico exibe: “Transação recusada. Entre em contato com seu banco.”

  • Ação do Ator: O cliente cancela e entra em contato com o banco.

  • Pós-condição: Nenhum dinheiro dispensado; nenhuma alteração na conta.

Extensões (<> Relacionamentos)

Extensão Gatilho Propósito
<>: Notificar o Sistema de Detecção de Fraude Quando um saque é realizado em um país estrangeiro ou excede o comportamento típico Marcar atividade suspeita para revisão
<>: Enviar alerta por SMS ao cliente Após o saque bem-sucedido Notificar o cliente sobre a transação (segurança aprimorada)
<>: Aplicar taxa de saque Para titulares de conta não primários ou certos tipos de conta Cobrar taxa por serviços específicos
<>: Imprimir histórico de transações Se o cliente selecionar “Imprimir Histórico” no menu Fornecer um resumo impresso das transações recentes

Requisitos Não-Funcionais (NFRs)

Categoria Requisito
Desempenho A transação deve ser processada em até 3 segundos.
Segurança Toda comunicação é criptografada (TLS 1.3). O PIN nunca é armazenado ou transmitido em texto claro.
Confiabilidade O caixa eletrônico não deve dispensar dinheiro a menos que o servidor do banco confirme a autorização.
Usabilidade A interface deve ser acessível (por exemplo, botões grandes, orientação por voz para pessoas com deficiência visual).
Disponibilidade O caixa eletrônico deve estar operacional 99,9% do tempo.
Auditoria e Conformidade Todas as transações devem ser registradas e rastreáveis por 7 anos (de acordo com as regulamentações bancárias).

Observações

  • O caixa eletrônico deve ser regularmente mantido para garantir a disponibilidade de dinheiro e a confiabilidade do hardware.

  • Se o cartão não for retirado dentro de 30 segundos após a transação, ele será retido automaticamente (funcionalidade anti-furto).

  • O sistema suporta múltiplas moedas e cálculos de taxa de câmbio (se aplicável).

Diagrama de Caso de Uso (Resumo UML)

[Cliente] --(Sacar Dinheiro)--> [Caixa Eletrônico]
[Caixa Eletrônico] --(Autenticar PIN)--> [Servidor do Banco]
[Caixa Eletrônico] --(Verificar Fundos)--> [Servidor do Banco]
[Caixa Eletrônico] --(Dispensar Dinheiro)--> [Cofre de Dinheiro]
[Caixa Eletrônico] --(Imprimir Comprovante)--> [Impressora]
[Caixa Eletrônico] --(Notificar Sistema de Fraude)--> [Sistema de Detecção de Fraude]

(Observação: Em um diagrama UML completo, relações de caso de uso como <> e <> seriam mostradas.)

✅ Resumo

Este caso de uso elaborado para “Sacar Dinheiro” fornece uma especificação clara, estruturada e testável que:

  • Captura os objetivos do usuário e o comportamento do sistema.

  • Lida com exceções do mundo real.

  • Suporta segurança, conformidade e usabilidade.

  • Serve como base para o design, testes e implementação.

É adequado para uso em sprints ágeis, documentos de design de sistema ou especificações formais de requisitos.

📘 Próximos Passos:

  • Converta isso em um diagrama de sequência para mostrar as interações entre objetos.

  • Criar casos de teste baseado em cada fluxo (principal e alternativo).

  • Link para diagramas de classes (por exemplo, Conta, Transação, Caixa Eletrônico, Detector de Fraude).