Resumo TI Banco de Dados: Levantamento de Requisitos para Modelagem

Começamos aqui o segundo bloco da trilha: modelagem de dados. Antes de desenhar qualquer diagrama entidade-relacionamento, existe uma etapa que muita gente subestima — e que as bancas cobram justamente por ser negligenciada na prática: o levantamento de requisitos. Um modelo de dados só é bom se representa corretamente o que a organização realmente precisa, e isso só se descobre perguntando, observando e documentando antes de modelar.

Neste resumo, você vai entender onde o levantamento de requisitos se encaixa no ciclo de projeto de um banco de dados, quais técnicas são usadas para levantá-los, e a diferença entre requisitos de dados e requisitos funcionais.

🗺️ Onde isso entra no ciclo de projeto de banco de dados

O projeto de um banco de dados segue tradicionalmente quatro grandes fases, em sequência:

• 1. Levantamento e análise de requisitos: descobrir o que o sistema precisa armazenar e como os dados serão usados;
• 2. Projeto conceitual: traduzir os requisitos em um modelo de alto nível, independente de SGBD — tipicamente um diagrama entidade-relacionamento (tema do próximo resumo);
• 3. Projeto lógico: mapear o modelo conceitual para o modelo de dados de um SGBD específico (ex.: tabelas relacionais);
• 4. Projeto físico: definir índices, particionamento e demais decisões de armazenamento (ver resumos sobre componentes de um SGBD e independência física de dados).

O levantamento de requisitos é a fundação de tudo isso: um erro aqui se propaga para todas as fases seguintes, e corrigi-lo depois do sistema em produção é ordens de grandeza mais caro do que corrigi-lo nesta etapa inicial.

🔎 Técnicas de levantamento de requisitos

Não existe uma única forma de levantar requisitos — o projetista normalmente combina várias técnicas:

• Entrevistas com usuários e stakeholders: conversas estruturadas ou semiestruturadas com quem vai usar o sistema no dia a dia e com quem toma decisões sobre ele;
• Questionários: úteis quando há muitos usuários e não é viável entrevistar todos individualmente;
• Análise de documentos existentes: formulários em papel, planilhas, relatórios e sistemas legados já em uso revelam que dados a organização já manipula na prática;
• Observação direta do processo de trabalho: acompanhar a rotina real dos usuários, que frequentemente revela necessidades que ninguém verbaliza espontaneamente numa entrevista;
• Prototipação: construir protótipos simples e validar com os usuários antes de consolidar o modelo completo.

📋 Requisitos de dados vs. requisitos funcionais

O levantamento produz dois tipos de requisito, e confundi-los é um erro comum:

• Requisitos de dados: o que precisa ser armazenado — quais entidades existem (clientes, produtos, pedidos), quais atributos cada uma tem, e como se relacionam entre si. É a matéria-prima do modelo entidade-relacionamento;
• Requisitos funcionais: o que o sistema precisa fazer com esses dados — operações como “cadastrar um pedido”, “calcular o total de vendas do mês”, “emitir um relatório de estoque baixo”. Ajudam a validar se o modelo de dados suporta todas as operações necessárias.

Um modelo de dados tecnicamente correto, mas que não suporta uma operação funcional essencial do negócio, é um modelo que falhou no seu propósito — por isso os dois tipos de requisito precisam ser levantados juntos, não só o de dados.

📝 O produto do levantamento: a especificação de requisitos

O resultado dessa fase costuma ser documentado numa especificação (formal ou informal, dependendo do porte do projeto), contendo pelo menos:

• Lista das entidades identificadas e uma breve descrição de cada uma;
• Atributos relevantes de cada entidade, com indicação de quais são obrigatórios;
• Relacionamentos identificados entre as entidades e suas regras de negócio associadas;
• Lista de operações/consultas que o sistema precisa suportar;
• Restrições de negócio explícitas (ex.: “um pedido não pode ser cadastrado sem cliente associado”).

Esse documento é a entrada para a fase seguinte: o projeto conceitual, onde essas informações são formalizadas num diagrama entidade-relacionamento.

⚠️ Pegadinhas comuns

• Levantamento de requisitos não é uma etapa opcional em projetos pequenos: mesmo sistemas simples se beneficiam de um levantamento mínimo — o risco de retrabalho existe em qualquer escala;
• Requisito de dados ≠ requisito funcional: essa é a distinção mais cobrada — “quais entidades existem” é requisito de dado; “o que o sistema precisa calcular ou processar” é requisito funcional;
• Levantamento de requisitos não produz o modelo entidade-relacionamento diretamente: ele produz a matéria-prima (a especificação); o MER é construído na fase seguinte, de projeto conceitual;
• Requisitos mudam ao longo do projeto: o levantamento inicial não é necessariamente definitivo — projetos iterativos revisitam requisitos conforme o entendimento do negócio amadurece.

🎯 Dica Final para a Prova

Fixe a ordem do ciclo de projeto: levantamento de requisitos → projeto conceitual → projeto lógico → projeto físico. E memorize a distinção central: requisito de dado descreve o “o quê” (entidades, atributos, relacionamentos); requisito funcional descreve o “o que fazer com isso” (operações, cálculos, relatórios).

✓ Agora que você sabe como e onde os requisitos são levantados, o próximo passo é ver como eles se transformam em um modelo formal: os fundamentos do Modelo Entidade-Relacionamento (MER), a principal ferramenta de projeto conceitual em banco de dados.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Modelo Entidade-Relacionamento (MER) – fundamentos

📘 Nenhum modelo de dados nasce do nada — todo bom projeto começa ouvindo com atenção quem vai usar o sistema. Dominar o levantamento de requisitos é entender que modelagem de dados é, antes de tudo, tradução de necessidades reais em estrutura. Continue estudando!