Modelagem de Requisitos e Revisão de Código com IA
Este documento foi criado por um Estudante de Análise e Desenvolvimento de Sistemas com objetivo de trazer uma camada de análise de produto para o time de engenharia. Ele cobre dois artefatos de modelagem UML que ajudam a entender o comportamento esperado do sistema, e explica como um fluxo de revisão de código assistido por IA pode complementar o trabalho nas análises.
Um caso de uso descreve como um ator (usuário, sistema externo, organização) interage com o sistema para atingir um objetivo. Ele não descreve como o sistema funciona internamente — descreve o que o sistema faz do ponto de vista de quem usa.
Isso é relevante para os testes porque os casos de uso são a origem dos critérios de aceite. Se o caso de uso não está bem escrito, os critérios de aceite ficam com lacunas, e os testes cobrem o que foi implementado — não necessariamente o que deveria ser implementado.
Estrutura
| Campo | Descrição | Impacto direto nos testes |
|---|---|---|
| Ator principal | Quem inicia o fluxo | Define o perfil de usuário dos testes |
| Pré-condições | O que precisa ser verdadeiro antes de iniciar | Equivale ao arrange / setup do teste |
| Fluxo principal | O caminho feliz, passo a passo | Test case do cenário de sucesso |
| Fluxos alternativos | Desvios, falhas, exceções | Cada um é um cenário negativo ou edge case |
| Pós-condições | Estado garantido após execução bem-sucedida | Equivale ao assert / verificação final |
Exemplo — Processar Venda (PDV)
Fluxo principal:
- Cliente chega ao PDV com itens
- Caixa registra cada item no sistema
- Sistema exibe descrição, preço e total parcial
- Cliente informa dados de pagamento
- Sistema valida e registra pagamento
- Sistema atualiza o estoque
- Cliente recebe recibo
Fluxos alternativos (onde os bugs costumam aparecer):
- Autorização de crédito recusada → reembolso em dinheiro
- Identificador do item não encontrado → notificar caixa, entrada manual
- Falha de comunicação com sistema externo de contabilidade → recuperação de estado
Cada fluxo alternativo é um caso de teste que precisa existir. Se o ticket não descreve o que acontece quando a autorização é recusada, isso precisa ser questionado antes do desenvolvimento — não depois.
Relacionamentos entre Casos de Uso
<<include>> — obrigatoriedade. Quando A inclui B, toda execução de A executa B também.
Saque ──<<include>>──► Registrar Movimento
Depósito ──<<include>>──► Registrar Movimento
Ao testar Saque, você também está testando Registrar Movimento. Se esse comportamento incluído mudar, todos os casos de uso que o incluem podem ser afetados.
<<extend>> — condicionalidade. B só ocorre se uma condição específica for satisfeita em A.
Encerrar Conta ◄──<<extend>>── Efetuar Saque
Encerrar Conta ◄──<<extend>>── Efetuar Depósito
Extensões são os cenários esquecidos. São fluxos que só acontecem "às vezes" — e por isso raramente entram no teste de fumaça, mas aparecem em produção.
Generalização — herança de comportamento. O caso de uso especializado herda tudo do genérico.
Abertura de Conta
├── Abertura de Conta Especial
└── Abertura de Conta Poupança
Ao testar uma especialização, valide também os comportamentos herdados do genérico. Uma regressão no caso base afeta todos os especializados.
O diagrama de atividades representa visualmente o fluxo de um processo — incluindo decisões, paralelismo e a responsabilidade de cada ator. É usado para complementar casos de uso complexos ou para modelar o comportamento de um algoritmo.
Elementos principais
| Elemento | O que representa |
|---|---|
| Círculo preto sólido | Estado inicial — ponto de entrada |
| Círculo com borda dupla | Estado final — ponto de saída |
| Retângulo arredondado | Ação (passo do fluxo) |
| Losango | Ponto de decisão — condicional (if / else) |
| Barra preta horizontal (fork) | Início de atividades paralelas |
| Barra preta horizontal (join) | Sincronização — aguarda todos os fluxos paralelos |
| Swim lane (raia) | Delimita a responsabilidade de cada ator no processo |
Swim lanes — onde os bugs de integração aparecem
As swim lanes dividem o diagrama por responsável. As transições entre colunas são os pontos de handoff — onde uma atividade passa de um ator para outro.
Segurado │ Seguradora │ Oficina
──────────────────┼─────────────────────────┼──────────────────
Acionar Seguro ──►│ Recolher Automóvel ─────►│ Avaliar Danos
│ │ ↓ decisão
│ Depositar Valor ◄─────── │ [perda total]
│ (fim) │ ↓ [else]
Pagar Franquia ◄──│ Cobrar Franquia │ Consertar Automóvel
│ (fim) │
Cada transição entre swim lanes é um ponto de integração — os primeiros lugares a cobrir com testes de contrato e cenários de falha.
Lendo um diagrama de atividades como plano de testes
Estado inicial → Pré-condição / setup
Ação → Passo de execução a verificar
Ponto de decisão → Um caso de teste para cada ramo (true e false)
Fork → Verificar se os fluxos paralelos são independentes
Join → Verificar o que acontece se um dos fluxos falha
Estado final → Assert / verificação do estado esperado
Exemplo — Inscrição em disciplina
| # | Cenário | Resultado esperado |
|---|---|---|
| 1 | Limite de inscrições atingido | Usuário é informado, processo encerra |
| 2 | Dentro do limite, sem oferta disponível | Aluno vai para lista de espera |
| 3 | Dentro do limite, com oferta — fluxo completo | Inscrição e pagamento confirmados |
| 4 | Inscrição realizada, pagamento falha | Estado consistente — inscrição deve ser revertida ou mantida? |
| 5 | Pagamento processado, inscrição falha | Comportamento precisa estar definido no caso de uso |
Os cenários 4 e 5 raramente estão nos critérios de aceite e precisam ser levantados ativamente durante o refinamento.
Quando um branch é atualizado, copio os arquivos modificados e envio para o Claude com um pedido de análise. O modelo lê o código e aponta possíveis erros, comportamentos inesperados e oportunidades de melhoria.
Antes do teste: a IA identifica problemas que podem nem chegar à fase de testes — lógica incorreta, condições de borda não tratadas, inconsistências com o comportamento descrito no caso de uso.
Durante a análise de falha: quando um bug é encontrado, compartilhar o trecho de código com a IA ajuda a entender a causa raiz antes de abrir o ticket — o que melhora a qualidade do reporte.
Template de prompt
Contexto:
- Este código faz parte do caso de uso [nome]
- O fluxo esperado é [descrição resumida]
- O ator principal é [quem usa]
Arquivos alterados neste branch:
[colar o código]
Pedido:
- Identifique possíveis erros ou comportamentos inesperados
- Aponte cenários de borda não tratados
- Sugira melhorias considerando o fluxo descrito acima
Quanto mais o pedido referencia o comportamento esperado, mais precisa é a análise — o modelo consegue comparar o que o código faz com o que deveria fazer.
O que a IA consegue identificar bem
- Condições não tratadas (
null, array vazio, valor negativo) - Lógica que diverge do fluxo descrito
- Fluxos alternativos implementados de forma incompleta
- Inconsistências entre o que o código faz e o nome da função ou variável
O que ainda precisa do olhar humano
- Comportamento em contexto de dados reais
- Regras de negócio implícitas não documentadas
- Fluxos que dependem de estado externo (sessão, banco, fila)
- Validação de UX e acessibilidade
| Momento | Ação | Artefato |
|---|---|---|
| Refinamento do ticket | Questionar pré/pós-condições ausentes | Caso de Uso |
| Critérios de aceite | Transformar fluxos alternativos em critérios explícitos | Caso de Uso |
| Planejamento de cobertura | Mapear todos os ramos de decisão | Diagrama de Atividades |
| Análise de integração | Identificar pontos de handoff entre atores | Swim Lane |
| Revisão de branch | Compartilhar código + contexto com IA | Fluxo IA |
| Reporte de bug | Incluir causa raiz identificada com apoio da IA | Fluxo IA |
- Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 3 ed. Elsevier, 2015.
- Dennis, A.; Wixom, B.; Roth, R. Análise e Projeto de Sistemas. 5 ed. LTC, 2014.
- Rumbaugh, J.; Blaha, M. Modelagem e Projetos Baseados em Objetos com UML 2. Elsevier, 2006.