Requisitos textuais para Modelagem de Dados: leitura, extração e organização

O que são requisitos textuais na modelagem de dados

Requisitos textuais são descrições em linguagem natural (briefings, e-mails, atas, histórias de usuário, regulamentos, contratos, manuais, mensagens de suporte) que contêm pistas sobre o que precisa ser armazenado, consultado e controlado. O objetivo aqui é transformar texto em insumos estruturados para modelagem: termos do negócio, entidades candidatas, relacionamentos, atributos, regras e exemplos de dados.

Um método prático evita dois erros comuns: (1) “modelar por intuição” sem rastreabilidade ao texto; (2) “copiar o texto” para o modelo sem resolver ambiguidades. O foco é ler com intenção, extrair evidências e registrar decisões.

Preparação: como organizar o material antes de extrair

1) Reunir fontes e marcar a origem

• Liste as fontes: documento, seção, data, autor, versão.
• Numere trechos (ex.: RQ-01, RQ-02) para rastrear cada item extraído.
• Separe texto “normativo” (deve, não pode, obrigatório) de texto “descritivo” (exemplos, contexto).

2) Definir um glossário inicial (mesmo incompleto)

Antes de extrair entidades, crie um glossário rascunho com termos que aparecem repetidamente. O glossário não precisa estar perfeito; ele serve para detectar sinônimos e homônimos.

• Sinônimos: “cliente” vs “consumidor”.
• Homônimos: “conta” (bancária) vs “conta” (usuário do sistema).

Leitura orientada: como extrair entidades, relacionamentos, atributos e regras

Técnica 1 — Leitura orientada a substantivos (potenciais entidades)

Substantivos e sintagmas nominais costumam indicar coisas sobre as quais o negócio quer manter informação. Nem todo substantivo vira entidade; alguns viram atributo, enumeração, papel (role) ou apenas texto livre.

Checklist de triagem para um substantivo virar entidade candidata:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Tem identidade própria? (precisa ser distinguido de outros)
• Tem ciclo de vida? (cria, atualiza, encerra)
• Tem múltiplos atributos relevantes?
• É referenciado por outros itens? (ligações, histórico, auditoria)
• Existe em volume (muitos registros)?

Exemplo de trecho:

“O cliente realiza pedidos. Cada pedido possui itens e é pago por cartão ou boleto.”

• Substantivos: cliente, pedidos, itens, cartão, boleto.
• Entidades candidatas: Cliente, Pedido, ItemPedido, Pagamento (Cartão/Boleto podem ser forma de pagamento, não necessariamente entidades).

Armadilhas comuns:

• Substantivo abstrato que é atributo: “status”, “prioridade”, “categoria”. Muitas vezes são domínios/enumerações.
• Substantivo que é evento: “cancelamento”, “aprovação”, “envio”. Pode virar entidade de evento (log) ou apenas um estado/regra.
• Substantivo que é documento: “nota fiscal”, “contrato”, “comprovante”. Frequentemente vira entidade, pois tem número, data, emissor e regras.

Técnica 2 — Leitura orientada a verbos (relacionamentos e eventos)

Verbos indicam ações e ligações entre entidades. Eles ajudam a descobrir cardinalidades, dependências e eventos do domínio.

Como extrair:

• Identifique sujeito + verbo + objeto: quem faz o quê com quem.
• Marque verbos de posse/associação: “possui”, “contém”, “pertence”.
• Marque verbos de processo: “aprova”, “cancela”, “envia”, “agenda”.

Exemplo de trecho:

“Um pedido pode ser cancelado pelo cliente antes do envio.”

• Relação/ação: Cliente cancela Pedido.
• Regra temporal/condicional: antes do envio.
• Possível evento: CancelamentoPedido (se precisar de histórico, motivo, data, usuário).

Dica prática: quando o verbo exigir atributos próprios (data, motivo, responsável), trate como evento/entidade associativa. Ex.: “aprovação” com aprovador, data e justificativa.

Técnica 3 — Leitura orientada a adjetivos e qualificadores (atributos e domínios)

Adjetivos, complementos e qualificadores costumam indicar atributos, tipos e restrições de domínio.

O que procurar:

• Qualificadores de identificação: “código”, “número”, “identificador”, “chave”.
• Qualificadores de classificação: “tipo”, “categoria”, “modalidade”.
• Qualificadores de estado: “ativo”, “bloqueado”, “pendente”.
• Qualificadores de valor: “mínimo”, “máximo”, “limite”, “faixa”.

Exemplo de trecho:

“O cliente possui e-mail único e CPF obrigatório. Pedidos têm status: aberto, pago, enviado, cancelado.”

• Atributos: Cliente.email (único), Cliente.cpf (obrigatório).
• Domínio/enumeração: Pedido.status ∈ {aberto, pago, enviado, cancelado}.

Técnica 4 — Leitura orientada a restrições (regras de negócio)

Regras aparecem como obrigações, proibições, condições, limites e exceções. Elas determinam integridade e comportamento esperado dos dados.

Marcadores linguísticos típicos: “deve”, “não pode”, “somente”, “exceto”, “se… então…”, “no máximo”, “pelo menos”, “antes de”, “após”, “obrigatório”, “opcional”.

Exemplo de trecho:

“Um cliente pode ter no máximo 3 endereços ativos. Endereço de cobrança é obrigatório quando o pagamento for boleto.”

• Regra de cardinalidade condicional: max 3 endereços ativos por cliente.
• Regra condicional: se forma_pagamento = boleto então endereço_cobranca obrigatório.

Como registrar regra de forma testável:

• Escreva em formato “Dado/Quando/Então” ou “Se/Então”.
• Inclua termos do domínio (sem ambiguidade).
• Liste exemplos válidos e inválidos.

Passo a passo prático: do texto bruto ao pacote de insumos

Passo 1 — Quebrar o texto em sentenças numeradas

Copie o texto para um documento de trabalho e numere cada sentença ou parágrafo curto. Isso permite rastrear a origem de cada entidade, atributo e regra.

Exemplo:

• RQ-01 “O cliente realiza pedidos.”
• RQ-02 “Cada pedido possui itens e é pago por cartão ou boleto.”
• RQ-03 “Um pedido pode ser cancelado pelo cliente antes do envio.”

Passo 2 — Destacar termos e classificar (N/V/Adj/Regra)

Para cada trecho, destaque e rotule:

• N (substantivos): candidatos a entidade/atributo/documento/ator.
• V (verbos): candidatos a relacionamento/evento.
• Adj (qualificadores): candidatos a atributos/domínios.
• R (restrições): regras de negócio.

Exemplo aplicado ao RQ-02:

• N: pedido, itens, cartão, boleto
• V: possui, é pago
• Adj: (implícito) “por cartão ou boleto” → domínio de forma de pagamento
• R: pagamento deve ser cartão ou boleto (se for exaustivo)

Passo 3 — Consolidar um glossário e resolver sinônimos

Crie uma tabela de termos e normalize nomes. Se “pedido” e “ordem” aparecem, escolha um termo preferencial e registre o sinônimo.

Passo 4 — Identificar atores, documentos e eventos

Além de entidades “cadastro”, textos trazem elementos que influenciam o modelo:

• Atores: papéis que executam ações (cliente, atendente, administrador, sistema externo).
• Documentos: itens com número/versão/validade (nota fiscal, contrato, comprovante).
• Eventos: ocorrências no tempo que podem exigir histórico (cancelamento, aprovação, envio, reembolso).

Regra prática: se o negócio precisa consultar “quando aconteceu”, “quem fez” e “por quê”, trate como evento com atributos próprios.

Passo 5 — Transformar verbos em relacionamentos e checar cardinalidades

Para cada verbo relevante, escreva uma frase estruturada e tente inferir cardinalidade. Quando o texto não disser, registre como ambiguidade.

• Cliente realiza Pedido → um cliente pode realizar muitos pedidos? um pedido pertence a um cliente? (provável 1:N, mas confirme)
• Pedido possui ItemPedido → um pedido tem 1..N itens? item existe sem pedido? (dependência)

Exemplo de registro:

• Relacionamento: Pedido contém ItemPedido
• Cardinalidade: Pedido 1..N ItemPedido (pendente confirmar se pode ser 0)
• Dependência: ItemPedido não existe sem Pedido (forte candidato)
• Fonte: RQ-02

Passo 6 — Extrair atributos e restrições de qualidade de dados

Para cada entidade candidata, liste atributos mencionados e restrições: obrigatório, único, formato, faixa, padrão, sensibilidade.

Exemplo:

• Cliente: cpf (obrigatório, formato), email (único), nome
• Pedido: status (domínio), data_criacao

Quando o texto não especifica: registre pergunta pendente (ex.: “CPF pode ser nulo para estrangeiro?”).

Passo 7 — Registrar ambiguidades, perguntas e decisões

Ambiguidade é normal. O método exige registrar explicitamente o que está indefinido e o que foi assumido.

Tipos comuns de ambiguidade:

• Termos vagos: “usuário”, “conta”, “registro”.
• Escopo: “pedido” inclui serviços? inclui assinatura?
• Exaustividade: “pago por cartão ou boleto” exclui PIX?
• Temporalidade: “antes do envio” — envio é um status? uma data? um evento?

Como registrar:

Template de levantamento (copie e preencha)

1) Fontes e contexto

• Projeto/Área:
• Fontes analisadas: (nome, versão, link, data)
• Trechos numerados: (RQ-01…RQ-n)
• Escopo do texto: (o que cobre / o que não cobre)

2) Termos do negócio (glossário)

3) Entidades candidatas

4) Atores (papéis) e responsabilidades

5) Eventos do domínio (ocorrências no tempo)

6) Documentos e registros formais

7) Regras de negócio (testáveis)

8) Exemplos de dados (amostras realistas)

Use exemplos para validar entendimento e expor campos faltantes.

{ "cpf": "123.456.789-00", "email": "ana@exemplo.com", "nome": "Ana Souza" }

{ "numero": "P-2026-0001", "status": "aberto", "data_criacao": "2026-01-10" }

9) Casos de borda (edge cases) e exceções

Liste situações que quebram suposições e afetam regras/relacionamentos.

10) Pendências e decisões

Mini-demostração completa (texto → extração → organização)

Texto de exemplo

RQ-01 “O cliente realiza pedidos e pode salvar mais de um endereço.” RQ-02 “Cada pedido possui itens com quantidade e preço unitário.” RQ-03 “O pagamento do pedido pode ser por cartão ou boleto. Para boleto, o endereço de cobrança é obrigatório.” RQ-04 “Um pedido pode ser cancelado pelo cliente antes do envio, informando um motivo.”

Extração rápida

• Entidades candidatas: Cliente, Pedido, ItemPedido, Endereco, Pagamento (ou atributos em Pedido), CancelamentoPedido (evento)
• Relacionamentos (verbos): Cliente realiza Pedido; Cliente salva Endereco; Pedido possui ItemPedido; Pedido é pago por Pagamento; Cliente cancela Pedido
• Atributos: ItemPedido.quantidade, ItemPedido.preco_unitario; Pagamento.forma (cartão/boleto); CancelamentoPedido.motivo; Endereco.tipo (entrega/cobrança?)
• Regras: forma_pagamento ∈ {cartão, boleto}; se forma_pagamento = boleto então endereco_cobranca obrigatório; cancelamento somente antes do envio
• Perguntas: endereço de cobrança é um Endereco separado ou um tipo de Endereco? “antes do envio” é baseado em status ou data_envio?