Entenda como estruturar uma requisição técnica em Engenharia com escopo, especificações, interfaces, vendor data, qualidade, testes e critérios de aceite.
Confira!
A requisição técnica em Engenharia é o pacote documental que libera uma aquisição ou contratação para o processo de Procurement com uma baseline técnica suficientemente definida. Ela consolida o que será fornecido, quais requisitos devem ser atendidos, quais documentos compõem a solicitação, como as propostas serão comparadas e quais evidências serão exigidas durante fabricação, instalação, testes e aceite.
Em projetos industriais, de infraestrutura, energia, Data Centers, telecomunicações e sistemas críticos, a requisição técnica funciona como a ponte entre Engenharia e Procurement. Se ela é emitida incompleta, a concorrência começa com lacunas que depois aparecem como dúvidas de fornecedores, propostas heterogêneas, exclusões, aditivos, atrasos, conflitos de interface ou dificuldades de comissionamento.
A requisição não deve ser confundida com uma simples lista de materiais nem com a RFP ou RFQ. Ela é a baseline técnica de entrada utilizada para montar o documento de solicitação ao mercado. Dependendo do objeto, pode reunir especificações, datasheets, desenhos, listas, memoriais, critérios de aceite, requisitos de qualidade, matriz de responsabilidades e documentação de vendor data.
Para que serve uma requisição técnica
A requisição técnica é o gate de maturidade entre Engenharia e Procurement. Sua função é impedir que uma contratação formal seja iniciada com requisitos, interfaces e critérios de aceite ainda indefinidos.
A requisição técnica transforma uma necessidade de projeto em um pacote que pode ser adquirido de forma comparável. Sua função é garantir que Procurement não precise interpretar sozinho o escopo de Engenharia e que os fornecedores recebam a mesma referência técnica.
O World Bank destaca, em seus recursos de Procurement, que Terms of Reference e especificações técnicas precisam ser preparados de forma capaz de orientar o mercado e a avaliação. O PMBOK, por sua vez, conecta Statement of Work, estimativas, documentos de solicitação e avaliação de fornecedores dentro do fluxo de Procurement.
Em organizações EPC/EPCM, o termo Technical Requisition é frequentemente usado para o documento que agrupa especificação técnica, folhas de dados, listas e requisitos documentais de um pacote de compra.
O que a requisição técnica não é
A fronteira do documento precisa ser clara.
| Documento | Função principal |
| lista de materiais | quantifica itens, componentes ou equipamentos |
| especificação técnica | define requisitos técnicos e de desempenho |
| datasheet | registra parâmetros aplicáveis a um equipamento ou item |
| requisição técnica | consolida a baseline técnica do pacote para Procurement |
| RFP | solicita proposta estruturada para objeto complexo |
| RFQ | solicita cotação para objeto suficientemente definido |
| contrato/pedido | formaliza obrigações comerciais e jurídicas |
A requisição pode incorporar ou referenciar todos esses documentos técnicos, mas não substitui o instrumento comercial e contratual.
Quando a requisição está madura para emissão
O critério não deve ser “o documento está escrito”, mas “o mercado consegue formar uma oferta comparável e executável a partir desta baseline?”.
Antes da liberação, a Engenharia precisa verificar se:
- o escopo está delimitado;
- os limites de bateria estão claros;
- interfaces com terceiros estão identificadas;
- requisitos mandatórios estão diferenciados de preferências;
- dados de projeto necessários estão disponíveis;
- alternativas permitidas estão definidas;
- testes e critérios de aceite possuem lógica verificável;
- documentos de fornecedor necessários foram especificados;
- quantidades e unidades são consistentes;
- desenhos e listas utilizam revisões corretas;
- premissas e exclusões do proprietário estão explícitas.
Quando uma dessas lacunas é material, emitir a requisição apenas para “ganhar tempo” pode deslocar o atraso para uma fase mais cara.
Estrutura recomendada da requisição técnica
Não existe um único template válido para todos os setores. A estrutura deve refletir o objeto, mas um pacote de Engenharia pode conter os seguintes blocos.
Identificação do pacote
Código, título, disciplina, sistema, projeto, local de instalação, revisão, responsável técnico e referência ao plano de suprimentos.
Escopo de fornecimento
Descreve o que o fornecedor deverá entregar, incluindo equipamentos, materiais, serviços, Engenharia de aplicação, instalação quando aplicável, testes, documentação, treinamento, sobressalentes e suporte.
Limites e interfaces
Define os pontos em que a responsabilidade do fornecedor começa e termina. Em sistemas integrados, essa seção é tão relevante quanto a especificação do próprio equipamento.
Documentos técnicos aplicáveis
Pode incluir:
- especificações;
- memoriais;
- desenhos;
- diagramas;
- datasheets;
- listas de materiais;
- lista de I/O;
- arquitetura de sistemas;
- estudos de Engenharia;
- normas e padrões;
- documentos de referência do empreendimento.
Requisitos de desempenho
Parâmetros mensuráveis que a solução precisa alcançar. Sempre que possível, devem ser definidos de modo verificável e associados à evidência que demonstrará atendimento.
Requisitos de qualidade e inspeção
Incluem plano da qualidade, ITP, certificados, rastreabilidade, inspeções, witness points, hold points, FAT, testes especiais e tratamento de não conformidades quando aplicáveis.
Vendor data requirements
Define quais documentos o fornecedor deve entregar, em que revisão, formato e prazo. Essa lista deve nascer antes da contratação porque parte dos documentos pode ser necessária para continuar o próprio projeto.
Critérios de aceite
Explicam como o contratante confirmará conformidade: aprovação documental, testes, inspeções, SAT, comissionamento, documentação final ou outros mecanismos.
Escopo de fornecimento precisa incluir serviços invisíveis
Muitas diferenças entre propostas não estão no equipamento principal, mas nos serviços e acessórios que permitem colocá-lo em operação.
A requisição deve verificar, conforme o pacote:
- Engenharia de aplicação;
- desenhos de fabricante;
- acessórios e kits de montagem;
- conectores e interfaces;
- licenças de software;
- configuração;
- integração;
- ferramentas especiais;
- supervisão de montagem;
- start-up;
- FAT e SAT;
- treinamento;
- documentação;
- sobressalentes;
- garantia e suporte.
Quando esses elementos ficam implícitos, cada proponente cria sua própria interpretação e a comparação perde validade.
Limites de bateria e interfaces
Battery limits definem limites físicos ou funcionais do fornecimento. Em Engenharia multidisciplinar, a requisição deve registrar pontos de conexão, alimentação, comunicação, infraestrutura, responsabilidade por cabos, suportes, software, obras civis, integração e testes.
Uma matriz de interfaces pode ser mais eficiente que longos parágrafos.
| Interface | Fornecedor | Contratante/terceiro | Evidência |
| alimentação elétrica | borne do equipamento | circuito e proteção a montante | diagrama e carga elétrica |
| rede de dados | interface Ethernet | switch e infraestrutura | requisitos de porta e protocolo |
| base civil | cargas e chumbadores | projeto e execução da base | desenho de cargas |
| software | licença e configuração | infraestrutura de servidor | matriz de requisitos |
| comissionamento | testes do equipamento | integração do sistema | protocolo SAT |
Essa definição reduz disputas posteriores sobre “escopo por terceiros”.
Requisitos prescritivos e requisitos de desempenho
A requisição deve equilibrar duas formas de especificar.
Requisitos prescritivos definem materiais, modelos, dimensões, arquitetura ou método. São adequados quando interoperabilidade, padronização ou experiência consolidada exigem uma solução específica.
Requisitos de desempenho definem o resultado que precisa ser atingido e permitem que o fornecedor proponha como alcançá-lo. São úteis quando existe espaço legítimo para inovação ou soluções equivalentes.
Uma especificação excessivamente prescritiva pode restringir o mercado sem ganho técnico. Uma especificação excessivamente funcional pode transferir ao fornecedor decisões que deveriam permanecer sob controle da Engenharia.
Como tratar normas e documentos aplicáveis
A requisição deve listar normas somente quando realmente pertinentes ao objeto e à edição aplicável ao projeto. Copiar uma lista extensa de normas de outro pacote cria conflitos e exigências irrelevantes.
Também é necessário definir precedência documental. Se desenho, datasheet e especificação divergirem, o fornecedor precisa saber qual documento governa ou como emitir uma consulta técnica.
Uma hierarquia explícita reduz ambiguidades durante proposta e execução.
Matriz de requisitos para propostas comparáveis
Em pacotes complexos, uma matriz de conformidade pode acompanhar a requisição. Cada requisito recebe identificador e o fornecedor indica atendimento, evidência, desvio ou alternativa.
Essa matriz facilita a futura TBE, porque a avaliação deixa de começar pela leitura desestruturada de centenas de páginas.
Uma classificação típica pode usar:
- conforme;
- esclarecimento necessário;
- desvio;
- alternativa técnica;
- não conforme.
O significado de cada status deve ser definido no processo.
Como preparar requisitos para a TBE
A equipe que elabora a requisição deveria pensar na avaliação futura. Para cada requisito relevante, deve ser possível responder:
- como o fornecedor demonstrará atendimento na proposta;
- qual evidência será aceita;
- se o requisito é eliminatório ou diferenciador;
- se alternativas são permitidas;
- como o requisito será verificado depois da contratação.
Essa rastreabilidade conecta especificação, TBE e aceite.
Requisição técnica e RFI
Quando a Engenharia ainda não consegue preencher a requisição porque existem dúvidas sobre tecnologia, mercado, capacidade ou interfaces, uma RFI pode ser emitida antes.
A consulta serve para amadurecer a baseline, não para substituir o trabalho de Engenharia. Depois de consolidar respostas, a equipe revisa especificações e libera a requisição em nível adequado para RFP ou RFQ.
Requisição técnica e RFP
Em uma RFP, a requisição técnica define a referência contra a qual soluções diferenciadas serão avaliadas. Ela precisa indicar quais requisitos são fixos e onde existe liberdade de solução.
Se essa fronteira não estiver clara, fornecedores podem interpretar qualquer requisito como negociável ou, no extremo oposto, assumir que nenhuma alternativa é permitida.
Requisição técnica e RFQ
A RFQ pressupõe maior estabilidade do objeto. Por isso, a requisição que suporta uma RFQ precisa eliminar diferenças relevantes de escopo, quantidade, desempenho e documentação.
Quando os fornecedores ainda precisam projetar partes substanciais da solução para responder, o processo provavelmente se aproxima mais de uma RFP que de uma RFQ.
Vendor data deve ser definido antes do award
O Vendor Data Requirement List, Vendor Document Register ou estrutura equivalente especifica o que o fornecedor deverá emitir durante o contrato.
Documentos típicos podem incluir:
- datasheets certificados;
- desenhos dimensionais;
- cargas e interfaces;
- diagramas;
- listas de materiais;
- manuais;
- procedimentos de teste;
- certificados;
- relatórios de inspeção;
- documentação de software;
- documentação final e As-Built de fabricante.
Se esses documentos só forem negociados depois do award, o contratante perde poder de estabelecer prazos e formatos sem impacto comercial.
Submittals e ciclos de aprovação
A requisição deve indicar quais documentos são submetidos para informação, revisão, aprovação ou registro. Também deve definir o efeito da aprovação: revisar um desenho de fabricante não transfere ao contratante a responsabilidade pelo projeto do fornecedor, salvo disposição contratual específica.
Os ciclos precisam considerar prazo de revisão e possibilidade de reenvio. Vendor data atrasado pode bloquear fabricação ou Engenharia de outras disciplinas.
Requisitos de qualidade, inspeção e FAT
Para pacotes críticos, a requisição deve criar a base para o controle de qualidade desde o início. Não é suficiente pedir “FAT incluso” sem definir escopo, referência, procedimentos, testemunho e critérios de aprovação.
O mesmo vale para inspeções. O contratante precisa estabelecer quando haverá hold points, witness points, certificados obrigatórios e tratamento de não conformidades.
Essa lógica se conecta à Gestão da Qualidade em Procurement, que acompanha o fornecimento até o aceite.
Condições de entrega e logística técnica
Alguns aspectos de logística possuem natureza técnica e precisam estar na requisição: embalagem especial, preservação, restrições ambientais, orientação de armazenamento, peças soltas, içamento, proteção contra vibração, umidade ou corrosão.
Essas condições podem influenciar projeto de embalagem e até a configuração do equipamento.
Revisões e congelamento da baseline
A requisição técnica precisa ter revisão controlada. Se a Engenharia muda depois que fornecedores começaram a cotar, o processo deve registrar o impacto e emitir revisão ou esclarecimento formal para todos os participantes conforme as regras da concorrência.
Depois do award, mudanças devem seguir o processo de Engineering Change Management ou change control contratual. Alterar silenciosamente a especificação destrói a rastreabilidade entre proposta, contrato e fornecimento.
Checklist de liberação da requisição
Antes da emissão para Procurement, uma verificação independente pode confirmar:
- escopo completo;
- documentos listados e em revisão correta;
- quantidades reconciliadas;
- interfaces definidas;
- critérios de desempenho mensuráveis;
- requisitos mandatórios identificados;
- normas pertinentes;
- vendor data definido;
- qualidade e testes coerentes;
- critérios de aceite estabelecidos;
- estratégia RFI/RFP/RFQ compatível;
- responsáveis por avaliação definidos.
Para pacotes críticos, esse checklist pode funcionar como gate formal.
Indicadores de qualidade da requisição
A qualidade do documento pode ser observada por sinais do processo posterior:
| Indicador | Possível problema de origem |
| grande volume de dúvidas dos fornecedores | escopo ou requisitos ambíguos |
| muitas revisões durante a concorrência | baseline liberada cedo demais |
| propostas com exclusões muito diferentes | limites de fornecimento incompletos |
| TBE longa e com muitas diligências | matriz de requisitos insuficiente |
| mudanças logo após o award | interfaces ou dados de projeto imaturos |
| vendor data negociado posteriormente | requisitos documentais não definidos |
Esses dados podem alimentar lições aprendidas e melhorar templates futuros.
Requisição técnica em serviços de Engenharia
O conceito também pode ser aplicado a serviços, mesmo que o nome utilizado seja Termo de Referência, Statement of Work ou Scope of Services. A lógica permanece: definir escopo, entregáveis, premissas, metodologia esperada, interfaces, critérios de avaliação, medição e aceite de modo que propostas possam ser comparadas.
Em serviços intelectuais, evitar prescrever antecipadamente o próprio produto final é especialmente importante. O documento deve exigir metodologia e evidências suficientes para avaliar capacidade sem transferir ao proponente a execução gratuita do escopo durante a concorrência.
Integração com plano de suprimentos
A data de liberação da requisição é um marco do plano de suprimentos. Se ela atrasa, todas as atividades posteriores do pacote são deslocadas: emissão, propostas, TBE, award, vendor data, fabricação, testes e entrega.
Por isso, Project Controls deve monitorar não apenas compras emitidas, mas também requisições ainda em preparação pela Engenharia.
Considerações finais
A requisição técnica é uma das barreiras mais eficazes contra problemas de Procurement que parecem comerciais, mas nascem de Engenharia insuficientemente definida. Ela transforma requisitos, desenhos, interfaces, qualidade, documentação e aceite em uma baseline comum para o mercado.
Quando elaborada com rastreabilidade e integrada ao plano de suprimentos, à TBE e ao controle de vendor data, ela reduz ambiguidades antes que se tornem preço, atraso, change order ou disputa de responsabilidade.
Vendor data precisa ser contratado antes de ser necessário. Se desenhos e datasheets críticos só forem negociados depois do award, a Engenharia perde previsibilidade justamente nos documentos que alimentam projeto, fabricação e construção.
Referências técnicas
[1] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8. ed. Newtown Square: PMI, 2025. Disponível em: [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok)
[2] WORLD BANK. Procurement learning resources: Terms of Reference and Technical Specifications. Disponível em: [https://www.worldbank.org/en/scci/topic/procurement](https://www.worldbank.org/en/scci/topic/procurement)
[3] WORLD BANK. Procurement Regulations for IPF Borrowers. 7th ed. Washington, DC, 2025. Disponível em: [https://thedocs.worldbank.org/en/doc/c84273d1b230aeb2b0b8134de5dc8cd7-0290012025/original/Procurement-Regulations-7th-Edition-Sep-2025.pdf](https://thedocs.worldbank.org/en/doc/c84273d1b230aeb2b0b8134de5dc8cd7-0290012025/original/Procurement-Regulations-7th-Edition-Sep-2025.pdf)
[4] ISO; IAF. ISO 9001 Auditing Practices Group: Guidance on External Providers. Disponível em: [https://committee.iso.org/files/live/sites/tc176/files/PDF%20APG%20New%20Disclaimer%2012-2023/ISO-TC%20176-TF_APG-ExternalProviders.pdf](https://committee.iso.org/files/live/sites/tc176/files/PDF%20APG%20New%20Disclaimer%2012-2023/ISO-TC%20176-TF_APG-ExternalProviders.pdf)
Perguntas frequentes
É o pacote documental que consolida a baseline técnica necessária para Procurement solicitar e comparar ofertas, incluindo escopo, especificações, interfaces, documentos, requisitos de qualidade e critérios de aceite.
Não. A requisição é a entrada técnica preparada pela Engenharia. A RFP é o documento de solicitação ao mercado que utiliza essa baseline junto com regras comerciais, contratuais e de avaliação.
Escopo, limites, especificações, datasheets, desenhos aplicáveis, requisitos de desempenho, qualidade, inspeção, testes, vendor data, documentação e critérios de aceite, conforme a complexidade do pacote.
Quando a baseline permite ao mercado formar ofertas comparáveis e executáveis sem lacunas materiais de escopo, interface, desempenho ou aceite.
São os requisitos documentais que definem quais desenhos, datasheets, relatórios, manuais, certificados e outros documentos o fornecedor deve entregar, com prazos e status de revisão.
Pode, quando necessário, mas a revisão deve ser controlada e comunicada de forma formal aos participantes para preservar isonomia, rastreabilidade e comparabilidade.
Materiais técnicos complementares
Soluções relacionadas
Serviços relacionados
- Procurement Técnico: especificação, equalização, fornecedores e apoio à contratação
- Apoio Técnico à Licitação e Análise de Propostas de Engenharia: conformidade, técnica e preço
Conteúdos principais sobre o tema
- RFP em Engenharia: como estruturar escopo, requisitos e critérios de seleção
- RFQ em Engenharia: como solicitar propostas comercialmente comparáveis
