A Arte da Descrição de Problemas: Dos Requisitos Tradicionais à Engenharia de Prompts de IA

Introdução: A Evolução de uma Habilidade Crítica

Historicamente, a Descrição de Problema (DP) foi o artefato fundamental na Análise de Sistemas. Ela serviu como a única fonte de verdade para derivar casos de uso, modelos de processos de negócios (BPMN), diagramas de classes e esquemas de banco de dados. Uma DP vaga significava expansão de escopo; uma DP precisa significava uma construção bem-sucedida.

Hoje, com a IA Generativa, a Descrição de Problema não se tornou obsoleta; ela se tornou o prompt.

Os modelos de IA são essencialmente “motores de requisitos”. Eles não podem ler sua mente, mas podem executar instruções com velocidade sobre-humana se essas instruções forem estruturadas como uma descrição de problema rigorosa. Escrever uma DP para IA exige a mesma disciplina analítica que escrever uma para uma equipe de desenvolvimento, mas com camadas adicionais de contexto sobre formato de saída, restrições, e refinamento iterativo.

Este guia conecta a análise de sistemas tradicional e a engenharia de prompts de IA moderna, fornecendo um framework abrangente para escrever Descrições de Problema que geram diagramas de alta qualidade, código e insights estratégicos.

1. Conceitos-Chave de Descrições de Problema Eficazes

Seja direcionando analistas humanos ou LLMs, quatro pilares sustentam uma DP robusta:

1. Ancoragem Contextual

• Tradicional: Contexto de negócios, partes interessadas, ambiente regulatório.

• Uso de IA: Definição de persona, nível de expertise no domínio, público-alvo para a saída.

• Por que importa: Sem contexto, a IA recorre a médias genéricas. “Projete um sistema de login” resulta em um projeto estudantil; “Projete um login de portal de pacientes compatível com HIPAA para usuários idosos com baixa alfabetização digital” resulta em um padrão arquitetônico especializado.

2. Decomposição Estrutural

• Tradicional: Dividir problemas em requisitos funcionais/não funcionais, atores e entidades.

• Uso de IA:Estruturação de Cadeia de Pensamento (CoT), solicitações de raciocínio passo a passo, prompting modular.

• Por que isso importa:A IA tem dificuldade com complexidade monolítica. Decompor o Documento de Problema (PD) ajuda o modelo a manter a coerência em saídas longas.

3. Especificação de Restrições

• Tradicional:Orçamento, cronograma, pilha tecnológica, padrões de conformidade.

• Uso de IA:Formato de saída (Mermaid, PlantUML, JSON), diretrizes de estilo, padrões proibidos, limites de tokens.

• Por que isso importa:As restrições forçam criatividade e precisão. A IA sem restrições gera artefatos verbosos e, muitas vezes, inutilizáveis.

4. Critérios de Aceitação

• Tradicional:Definição de Pronto, casos de teste, KPIs.

• Uso de IA:Verificações de validação, prompts de autocorreção, verificação da estrutura esperada.

• Por que isso importa:Você deve definir como o “bom” se parece antes que a geração comece para permitir iterações eficazes.

2. Estrutura: O Modelo C.R.E.F.O. para Descrições de Problemas de IA

Adaptado da coleta tradicional de requisitos, use este modelo para tarefas de IA:

3. Casos de Uso e Exemplos

Caso A: Gerando Diagramas de Classes UML

Desafio:A IA frequentemente cria diagramas excessivamente complexos ou sintaticamente incorretos quando recebe descrições de domínio vagas.

❌ Descrição de Problema Fraca

“Crie um diagrama de classes para um sistema de comércio eletrônico.”

✅ Descrição de Problema Abrangente

CONTEXTO: Você é um especialista em Design Orientado a Domínio. Estamos construindo uma plataforma de comércio eletrônico B2B atacadista onde o precificação é baseada em contrato, não em catálogo.

REQUISITOS: Modelar o contexto delimitado central de pedidos. Focar na relação entre Contratos, Listas de Preços, Produtos e Pedidos. NÃO modelar UI ou processamento de pagamentos.

ENTIDADES E REGRAS:
- Contrato: Possui datas de vigência, pertence a uma única Conta de Cliente
- Lista de Preços: Vinculada ao Contrato, contém regras de precificação em níveis
- Linha de Pedido: Deve validar o preço contra o Contrato ativo no momento da criação
- Conta de Cliente: Pode ter múltiplos Contratos (atuais/históricos)

FORMATO: Sintaxe Mermaid classDiagram. Incluir modificadores de visibilidade (+/-/#). Mostrar multiplicidade em TODAS as associações. Usar notas para regras de negócio complexas.

RESTRIÇÕES: Máximo de 12 classes. Aplicar princípios SOLID. Nenhuma herança mais profunda que 2 níveis. Preferir composição sobre herança.

VALIDAÇÃO: Após gerar, liste 3 possíveis fraquezas de design neste modelo.

Caso B: Modelagem de Processos de Negócio (BPMN)

Desafio: A IA confunde a notação BPMN e ignora os caminhos de exceção.

✅ Descrição Completa do Problema

CONTEXTO: Processamento de reivindicações de seguros de saúde. Público-alvo: Auditores de conformidade 
e desenvolvedores júnior. Tom: Formal e preciso.

TAREFA: Criar um diagrama de processo compatível com BPMN 2.0 para "Solicitação de Autorização Prévia".

ESCOPO DO PROCESSO:
INÍCIO: Médico submete solicitação de autorização via integração com EHR
FIM: Decisão comunicada de volta ao EHR + notificação enviada ao membro

PONTOS CHAVE DE DECISÃO:
1. O procedimento está coberto pelo plano do membro? (Se não → negação automática + caminho de recurso)
2. A documentação clínica está completa? (Se não → pendente para revisão por enfermeiro)
3. Requer revisão do diretor médico? (Limiar: >$50K ou experimental)

GERENCIAMENTO DE EXCEÇÕES: Modelar eventos de timeout para cada etapa de revisão (SLA de 48h). 
Modelar caminho de escalonamento se o SLA for violado.

FORMATO: Fluxograma Mermaid com estilo semelhante ao BPMN. Usar subgrafos para as faixas "Revisão Clínica" e "Validação Administrativa".

REQUISITO DE SAÍDA: Fornecer o código do diagrama E uma tabela em markdown mapeando 
cada nó de decisão para a seção específica do documento de política que o rege.

Caso C: Derivação de Histórias de Usuário e Critérios de Aceitação

Desafio: A IA gera histórias genéricas que carecem de testabilidade.

✅ Descrição Completa do Problema

CONTEXTO: Equipe ágil migrando sistema legado de folha de pagamento COBOL para arquitetura nativa na nuvem. 
A equipe utiliza Gherkin/Cucumber BDD.

ENTRADA: [Coletre um trecho da especificação do sistema legado ou transcrição de entrevista]

TAREFA: Extrair histórias de usuário para o módulo "Cálculo de Retenção de Impostos".

REQUISITOS POR HISTÓRIA:
- Seguir critérios INVEST
- Formato do título: Como [função], eu quero [capacidade], para que [valor de negócio]
- Critérios de Aceitação: Mínimo de 5 cenários Gherkin por história
- Incluir casos de borda: Funcionários em múltiplos estados, ajustes retroativos de pagamento, 
  limites de penhora, isenções por tratados fiscais

RESTRIÇÕES: Cada história deve ser concluída em ≤3 dias. Marcar qualquer história 
que pareça muito grande com a tag "[NECESSITA DIVISÃO]".

FORMATO: Markdown estruturado com frontmatter YAML contendo:
  - story_id
  - prioridade (MoSCoW)
  - pontos estimados
  - dependências

Caso D: Registros de Decisão de Arquitetura de Sistema (ADR)

Desafio: Fazer a IA raciocinar sobre compensações em vez de apenas listar opções.

✅ Descrição Completa do Problema

CONTEXTO: Estamos escolhendo uma plataforma de streaming de eventos para telemetria de IoT 
(10 milhões de dispositivos, pico de 50 mil mensagens/segundo). A equipe tem forte experiência com Kafka, mas 
a gerência deseja menor sobrecarga operacional.

TAREFA: Escrever um ADR comparando Apache Kafka vs. AWS Kinesis vs. Pulsar.

ESTRUTURA (Seguir o modelo de ADR de Michael Nygard):
1. Título e Status
2. Contexto (inclua nossas restrições específicas abaixo)
3. Impulsionadores de Decisão (ponderados)
4. Opções Consideradas (matriz de prós/contras)
5. Decisão + Justificativa
6. Consequências (positivas E negativas)

IMPULSIONADORES DE DECISÃO (Ponderados):
- Complexidade operacional (35%) - equipe pequena (3 engenheiros)
- Custo em escala (25%)
- Garantias de ordenação de mensagens (20%)
- Risco de lock-in com fornecedor (15%)
- Comunidade/ecossistema (5%)

RESTRIÇÃO: Seja brutalmente honesto sobre os pontos negativos. Não recomende com base 
apenas na popularidade. Se nenhum for adequado, diga isso e sugira alternativas.

TOM: Técnico, baseado em evidências, sem linguagem de marketing.

4. Dicas e Truques

🎯 Técnicas de Precisão

1. Defina sua Ontologia Primeiro: Antes de solicitar qualquer diagrama, peça à IA para criar um glossário ou modelo de domínio. Alinhe a terminologia antes de gerar artefatos.“Primeiro, defina as entidades principais e suas relações em tópicos. Aguarde minha aprovação antes de gerar o diagrama.”

2. Restrições Negativas são Poderosas: Dizer à IA o que NÃO fazer é frequentemente mais eficaz do que o que fazer.“Não inclua operações CRUD neste diagrama de sequência. Não use herança. Não assuma comunicação síncrona.”

3. Forneça Exemplos Negativos: Mostre como uma saída ruim se parece.“Aqui está um exemplo de um diagrama excessivamente complexo que rejeitamos na semana passada [cole]. Evite este padrão porque…”

4. Use Formatos de Entrada Estruturados: Forneça requisitos como YAML, JSON ou listas numeradas em vez de prosa. A IA analisa dados estruturados de forma mais confiável.

5. Protocolo de Refinamento Iterativo: Nunca aceite a saída de primeira passagem para diagramas complexos. Incorpore o refinamento na sua Descrição do Problema (PD): “Após gerar, critique sua própria saída com base nestes 5 critérios de qualidade. Em seguida, regenere abordando todos os problemas identificados.”

⚠️ Armadilhas Comuns a Evitar

5. Lista de Verificação de Diretrizes

Antes de submeter qualquer Descrição do Problema à IA, verifique:

• Função/Papal definido com nível de expertise apropriado

• Contexto de negócios fornecido (não apenas especificações técnicas)

• Limites do escopo explicitamente declarados (dentro/fora do escopo)

• Entidades/termos principaisdefinidos ou referenciados

• Formato de saídaespecificado com detalhes de sintaxe/versão

• Restriçõeslistadas (técnicas, de negócios, estilísticas)

• Critérios de qualidadedefinidos para autoavaliação

• Casos de borda/exceçõesabordados

• Estratégia de decomposiçãoplanejada para saídas complexas

• Protocolo de iteraçãoestabelecido

6. A Meta-Habilidade: Descrição do Problema como Ferramenta de Pensamento

A percepção mais importante: Escrever uma Descrição do Problema para IA é, primordialmente, um exercício de esclarecimento do seu próprio pensamento.

Se você tem dificuldade em escrever uma PD clara, não tem um problema de prompt; tem um problema de requisitos. A IA apenas expõe a ambiguidade que, de qualquer forma, causaria problemas a jusante.

Use este fluxo de trabalho:

1. Rascunhe sua PD

2. Pergunte à IA: “Quais perguntas você precisaria que fossem respondidas para executar esta tarefa perfeitamente?”

3. Responda a essas perguntas, refinando sua PD

4. Apenas então solicite o produto final real

Isso transforma a IA em um parceiro de elicitação de requisitos, não apenas um motor de geração. A qualidade da sua Descrição do Problema permanece, como sempre foi, o único maior preditor de sucesso — seja seu colaborador humano ou artificial.

REQUISITO DE FORMATO: Gere o diagrama de classes na sintaxe PlantUML 
compatível com a importação do Visual Paradigm. Inclua todas as anotações de estereótipo 
(<<entity>>, <<service>>, <<repository>>). Use apenas notações de relacionamento suportadas pelo VP. NÃO use extensões personalizadas ou decoradores não padrão.

class OrderService {
  +processOrder(order: Order): void
}
class Order {
  +orderDate: Date
}
OrderService --> Order : uses

<<service>> class OrderService {
  +processOrder(order: Order): void
}
<<entity>> class Order {
  +orderDate: Date
}
<<repository>> class OrderRepository {
  +findById(id: UUID): Optional<Order>
}
OrderService --> OrderRepository : depende de
OrderService ..> Order : usa [1..* cria]

Este guia sintetiza as melhores práticas da análise tradicional de sistemas (IEEE 830, BABOK, especificações UML) e da pesquisa moderna em engenharia de prompts de IA. Adapte os frameworks ao contexto da sua organização e refine continuamente com base em ciclos de feedback sobre a qualidade da saída.