Entenda como estruturar a descrição da solução como um todo no ETP e no Termo de Referência, diferenciando necessidade, solução, objeto, requisitos e ciclo de vida.
Confira!
A “descrição da solução como um todo” é o elemento que conecta a necessidade pública à arquitetura completa capaz de produzir o resultado pretendido. Na Lei nº 14.133/2021, ela aparece no estudo técnico preliminar e também no termo de referência, mas com funções complementares: no ETP, ajuda a demonstrar qual solução foi escolhida após análise do problema e das alternativas; no TR, contextualiza o objeto que será contratado dentro dessa solução, considerando o ciclo de vida e as interfaces relevantes.
Solução não é sinônimo de objeto. Uma necessidade pode exigir vários bens, serviços, sistemas, obras, integrações, manutenção, assistência técnica, treinamento e providências da própria Administração. Parte desses elementos pode ser contratada separadamente. Por isso, um único ETP pode sustentar mais de uma licitação ou contratação direta, e um TR pode tratar apenas de um componente da solução. Mesmo assim, a visão do todo precisa permanecer clara para que fornecedores, fiscalização, gestores e órgãos de controle compreendam a finalidade da contratação e as dependências entre seus elementos.
O que significa “solução como um todo” na Lei 14.133
O art. 18, § 1º, VII, da Lei nº 14.133 determina que o ETP contenha a descrição da solução como um todo, inclusive exigências relacionadas à manutenção e à assistência técnica, quando for o caso. Já o conceito legal de termo de referência, no art. 6º, XXIII, inclui a descrição da solução como um todo considerado todo o ciclo de vida do objeto.
O Tribunal de Contas da União resume a ideia de solução como o conjunto de todos os elementos — bens, serviços e outros componentes — necessários para, de forma integrada, gerar os resultados que atendam à necessidade que originou a contratação.
Essa definição desloca o foco do item comprado para o resultado público. Em vez de perguntar apenas “o que vamos contratar?”, a Administração precisa responder “como o conjunto de elementos necessários vai resolver o problema?”.
O Estudo Técnico Preliminar para obras e serviços de engenharia deve fazer essa passagem da necessidade para a alternativa escolhida de maneira verificável.
Necessidade, solução, objeto, requisitos e escopo não são a mesma coisa
Boa parte das falhas de planejamento nasce da mistura desses conceitos.
| Conceito | Pergunta que responde | Exemplo simplificado |
| Necessidade | Qual problema público precisa ser resolvido? | Reduzir vulnerabilidade e melhorar controle de acesso de um prédio público |
| Solução | Qual conjunto integrado de elementos resolve o problema? | Controle de acesso, CFTV, infraestrutura, software, integração, instalação, treinamento e suporte |
| Objeto | O que será contratado em determinado processo? | Projeto executivo e implantação do sistema de controle de acesso |
| Requisitos | Quais condições de desempenho, qualidade, compatibilidade e segurança devem ser atendidas? | Capacidade, integração, disponibilidade, normas e critérios de desempenho |
| Escopo | Quais atividades, entregáveis, limites, interfaces e responsabilidades compõem o contrato? | Levantamento, projeto, fornecimento, instalação, testes, documentação e aceite |
Essas camadas são relacionadas, mas não intercambiáveis. Um TR pode definir muito bem o objeto e ainda falhar por não explicar como ele se integra aos demais elementos da solução.
A solução como um todo no ETP
A solução como um todo nasce no ETP. Quando necessidade, alternativas, interfaces e ciclo de vida são avaliados tecnicamente, o Termo de Referência deixa de ser uma lista de itens e passa a refletir uma estratégia de contratação.
Conheça o serviço de Estudo Técnico Preliminar para engenharia
No ETP, a descrição da solução aparece depois de etapas que deveriam ter amadurecido a decisão: necessidade, requisitos, estimativas, levantamento de mercado e escolha técnica e econômica da alternativa.
Ela não deve ser escrita como conclusão automática. Precisa sintetizar a alternativa escolhida e mostrar como seus componentes trabalham juntos.
O ETP deve partir do problema, não de uma marca ou item
Se a Administração começa pelo produto que deseja comprar, corre o risco de inverter a lógica do planejamento. O ETP deve evidenciar o problema e a melhor solução, permitindo avaliar viabilidade técnica e econômica.
Um prédio com interrupções frequentes de energia, por exemplo, não possui necessariamente uma necessidade chamada “comprar gerador”. A necessidade pode ser assegurar continuidade de cargas críticas. A solução pode envolver reorganização de cargas, redundância, UPS, gerador, automação, adequações elétricas e procedimentos operacionais.
A escolha depende do contexto técnico e econômico.
A descrição deve consolidar a alternativa escolhida
Depois do levantamento de mercado, a solução como um todo deve registrar a arquitetura que a Administração considera adequada. Não é preciso repetir integralmente cada análise anterior, mas a descrição precisa ser suficiente para compreender:
- quais componentes formam a solução;
- como se relacionam;
- quais resultados produzem;
- quais requisitos críticos precisam ser preservados;
- quais interfaces existem;
- quais elementos cabem à Administração;
- quais dependem de contratações correlatas;
- como manutenção e assistência serão tratadas;
- como o ciclo de vida influencia a decisão.
O que muda no Termo de Referência
O TR precisa transformar a solução selecionada em objeto contratável sem perder contexto, interfaces e critérios de desempenho. Revisão técnica antes da publicação identifica lacunas que podem gerar impugnações e aditivos.
O TR especifica o objeto escolhido para atendimento da necessidade e deve ser fundamentado no ETP quando este for elaborado. A Lei exige que ele apresente a solução como um todo considerado o ciclo de vida do objeto.
O TCU orienta que a descrição do TR pode ser uma transcrição ou síntese atualizada do item correspondente do ETP. Isso não significa copiar mecanicamente. Entre o ETP e o TR pode haver amadurecimento técnico, detalhamento, parcelamento ou atualização de premissas.
A consistência é o ponto central: o TR não pode apresentar um objeto desconectado da solução selecionada no planejamento.
O TR pode contratar apenas parte da solução
Esse é um dos aspectos mais importantes. Um único ETP pode originar vários itens, várias licitações ou mais de um processo de contratação direta. O TR pode cuidar de apenas um componente.
Imagine uma solução de modernização de edifício que inclua:
- diagnóstico e levantamento;
- projeto executivo;
- adequação elétrica;
- climatização;
- sistema de automação predial;
- segurança eletrônica;
- comissionamento integrado;
- treinamento e operação assistida.
A Administração pode contratar esses elementos em processos distintos. Cada TR precisa definir seu objeto específico, mas deve explicar em que posição ele se encontra dentro da arquitetura completa e quais interfaces precisam ser preservadas.
A justificativa de parcelamento do objeto deve conversar diretamente com essa visão integrada.
Solução como um todo não é uma lista de itens
Um erro recorrente é transformar a seção em uma relação de equipamentos ou serviços. Uma lista pode fazer parte da descrição, mas não substitui a explicação das relações funcionais.
Compare duas formas.
Descrição insuficiente
- câmeras IP;
- switches;
- servidores;
- software VMS;
- estações de operação;
- instalação.
A lista informa componentes, mas não explica por que formam uma solução, quais resultados devem gerar, como se integram, quais dependências existem e como serão aceitos.
Descrição orientada à solução
Uma solução de videomonitoramento pode ser descrita como sistema integrado destinado a capturar, transportar, armazenar, gerenciar e disponibilizar imagens de áreas definidas, com infraestrutura de rede compatível, processamento e armazenamento dimensionados, gerenciamento centralizado, postos de operação, integração com sistemas existentes quando aplicável, mecanismos de segurança, documentação, treinamento e critérios de teste e aceite.
Essa formulação revela função, integração e ciclo de vida sem transformar o ETP em especificação executiva.
O ciclo de vida precisa aparecer de forma concreta
Considerar o ciclo de vida não é inserir uma frase genérica sobre manutenção. É analisar como a solução será implantada, operada, mantida, atualizada e eventualmente substituída.
Em engenharia, isso pode envolver:
- vida útil de equipamentos e sistemas;
- disponibilidade de peças;
- assistência técnica;
- contratos de manutenção;
- licenciamento de software;
- atualizações e suporte;
- consumo de energia;
- calibração;
- inspeções periódicas;
- reposição de componentes;
- treinamento de operadores;
- documentação as built;
- descarte e logística reversa quando aplicáveis;
- expansão futura;
- interoperabilidade com instalações existentes.
Uma solução aparentemente mais barata na aquisição pode gerar custo total maior se exigir manutenção proprietária, substituições frequentes ou licenças não previstas.
Manutenção e assistência técnica no ETP
A Lei menciona expressamente manutenção e assistência técnica no item da solução como um todo do ETP. Isso exige avaliar se a efetividade da solução depende de suporte continuado.
Em ativos de engenharia, a pergunta correta não é apenas se o fornecedor oferece garantia. É necessário entender:
- quem realizará manutenção preventiva;
- como serão tratados defeitos;
- quais peças são críticas;
- qual o tempo de reposição aceitável;
- existem capacidades internas na Administração;
- será necessário contrato continuado;
- existem restrições de garantia por intervenção de terceiros;
- haverá atualização de software ou firmware;
- quais documentos e treinamentos são necessários para operação independente.
Esses elementos influenciam a própria escolha da alternativa.
Contratações correlatas e interdependentes
Quando a solução envolve múltiplos contratos, o planejamento precisa coordenar fronteiras, dependências, riscos e sequência de implantação. A visão integrada reduz lacunas entre objetos parcelados.
O art. 18 também exige que o ETP trate de contratações correlatas e interdependentes. Essa informação é complementar à descrição da solução.
Uma contratação é interdependente quando o resultado de uma depende materialmente de outra. Por exemplo, instalar sistema de automação pode depender de infraestrutura elétrica, rede de comunicação, sensores ou adequações físicas que serão contratadas separadamente.
Se essas interfaces não forem identificadas, a Administração pode contratar corretamente cada componente e ainda assim não obter uma solução funcional.
Matriz de interfaces
Uma ferramenta simples é registrar:
| Elemento | Responsável | Dependência | Critério de interface |
| Infraestrutura elétrica | Contrato A | cargas e pontos definidos pelo projeto | tensão, capacidade, proteção e disponibilidade |
| Rede de dados | Contrato B | posições dos equipamentos | portas, PoE, VLAN, banda e redundância |
| Sistema de segurança | Contrato C | elétrica e rede prontas | endereçamento, integração e testes |
| Comissionamento | Administração/consultoria | todos os subsistemas entregues | roteiro integrado e critérios de aceite |
A matriz não é requisito legal com esse nome, mas é uma forma prática de tornar a solução executável.
Como o parcelamento afeta a descrição da solução
Parcelar pode ampliar competitividade, especialização e eficiência, mas também aumenta a quantidade de interfaces contratuais. A solução como um todo precisa funcionar como referência comum entre os processos derivados do mesmo planejamento.
Quando o objeto é dividido, cada contrato deve deixar claro:
- o que está dentro e fora de seu escopo;
- quais entregas de terceiros são pré-requisitos;
- quem coordena interfaces;
- quais padrões comuns serão observados;
- como documentos serão compartilhados;
- quem realiza testes integrados;
- como será tratado o aceite quando um subsistema depende de outro.
Sem essa governança, o parcelamento pode gerar lacunas ou sobreposições.
Descrição da solução e especificação técnica
A solução como um todo não substitui a especificação técnica. As duas peças respondem a perguntas diferentes.
A solução explica o conjunto integrado que atende à necessidade. A especificação traduz requisitos verificáveis do objeto e de seus componentes.
O conteúdo sobre especificação técnica em obras e serviços de engenharia mostra como definir desempenho e critérios sem restringir indevidamente a competição.
Uma descrição de solução excessivamente detalhada pode antecipar especificações desnecessárias; uma especificação sem visão da solução pode otimizar um componente e prejudicar o sistema.
Descrição da solução e Projeto Básico
Em obras e serviços de engenharia, a solução escolhida precisa amadurecer até um nível técnico compatível com a contratação. O Projeto Básico transforma decisões de planejamento em definição suficiente de escopo, desempenho e orçamento.
Em obras, a contratação pode exigir projeto básico com nível de definição muito superior ao que cabe ao ETP. A solução como um todo deve permanecer coerente com essa evolução de maturidade.
O ETP escolhe a direção técnica e econômica. O projeto básico desenvolve elementos suficientes para caracterizar a obra ou serviço, definir métodos e soluções, estimar custos e permitir avaliação adequada da contratação conforme o regime aplicável.
O Projeto Básico na Lei 14.133 segundo o TCU aprofunda essa passagem de decisão para definição técnica.
O problema da solução mudar sem atualizar o planejamento
Durante o desenvolvimento do projeto, podem surgir descobertas que tornem a alternativa originalmente descrita inadequada. Isso não deve ser escondido por simples adaptação textual do TR.
Quando a mudança é material — altera escopo, custo, viabilidade, parcelamento, requisitos ou premissas — a Administração precisa avaliar a necessidade de revisitar o ETP e registrar a nova motivação.
Rastreabilidade de decisão é mais importante que aparência de continuidade documental.
Como descrever uma solução de engenharia de forma útil
Uma estrutura prática pode conter sete blocos.
1. Resultado pretendido
Comece pelo que a solução deve alcançar, não pelos equipamentos.
Exemplo: “assegurar disponibilidade elétrica para cargas críticas durante interrupções da concessionária, preservando segurança, continuidade operacional e capacidade de retorno controlado à condição normal”.
2. Arquitetura funcional
Explique os principais componentes e a relação entre eles.
3. Fronteiras
Indique quais elementos estão dentro da solução e quais pertencem a estruturas existentes ou contratações externas.
4. Interfaces
Descreva dependências com instalações, sistemas, equipes e contratos correlatos.
5. Ciclo de vida
Inclua operação, manutenção, suporte, expansão e desmobilização quando relevantes.
6. Responsabilidades
Identifique providências do contratado e da Administração que sejam críticas à viabilidade.
7. Critérios de integração e aceite
Antecipe como será demonstrado que o conjunto produz o resultado pretendido.
Essa estrutura não precisa aparecer literalmente em todos os processos, mas evita descrições centradas apenas no item adquirido.
Exemplo: solução para continuidade elétrica
Considere uma instalação pública com falhas frequentes de energia e cargas críticas.
A necessidade é manter serviços essenciais.
Uma solução completa pode envolver:
- levantamento de cargas;
- classificação de criticidade;
- adequação de quadros;
- UPS para cargas sem tolerância à interrupção;
- gerador para autonomia prolongada;
- sistema de transferência;
- proteção elétrica;
- combustível e autonomia;
- ventilação e exaustão;
- automação e supervisão;
- testes de transferência;
- manutenção periódica;
- treinamento;
- documentação de operação.
O objeto de uma licitação pode ser apenas o projeto executivo. Outro processo pode contratar equipamentos e implantação. Um terceiro pode cuidar da manutenção. A solução como um todo deve mostrar como essas partes convergem para disponibilidade elétrica.
Exemplo: solução para segurança eletrônica
Uma demanda por “mais câmeras” pode esconder um problema diferente: falta de cobertura, baixa qualidade de evidência, dificuldade de operação, ausência de integração ou infraestrutura insuficiente.
A solução pode combinar:
- levantamento de riscos e áreas críticas;
- arquitetura de CFTV;
- controle de acesso;
- rede e alimentação;
- servidores e armazenamento;
- VMS;
- integração de eventos;
- estações de operação;
- políticas de retenção;
- cibersegurança;
- treinamento;
- manutenção;
- critérios de comissionamento.
O ETP deve escolher a arquitetura em nível compatível com o planejamento. O TR e os projetos detalham o objeto efetivamente contratado.
Exemplo: retrofit de edifício público
Em retrofit, as interfaces tornam-se ainda mais importantes. Uma reforma pode envolver arquitetura, elétrica, climatização, incêndio, acessibilidade, automação, telecomunicações e segurança.
Se cada disciplina for contratada isoladamente sem visão do todo, podem ocorrer incompatibilidades: equipamentos sem espaço técnico, cargas não previstas, interferências de infraestrutura, falta de pontos de rede, ausência de drenagem, conflitos com rotas de fuga ou soluções impossíveis de manter.
A descrição da solução deve explicitar que o resultado depende da integração multidisciplinar e indicar como a coordenação será tratada.
Como evitar direcionamento indevido
Descrever a solução como um todo não autoriza vincular o planejamento a marca específica sem fundamento legal e técnico. A solução deve ser descrita prioritariamente por função, desempenho, integração, restrições reais e resultados.
Quando houver necessidade de padronização, compatibilidade ou indicação de marca em hipótese legalmente admitida, a justificativa deve ser documentada separadamente e refletida nos requisitos pertinentes.
O artigo sobre padronização na Lei 14.133 mostra como diferenciar padronização legítima de restrição indevida.
Como a descrição influencia o orçamento
Uma solução incompleta produz orçamento incompleto. Se o planejamento identifica apenas o equipamento principal e esquece instalação, integração, infraestrutura, licenças, testes, treinamento e documentação, a estimativa de valor não representa o custo da entrega funcional.
Isso gera dois riscos:
- propostas aparentemente elevadas porque os licitantes enxergam itens que a Administração não orçou;
- contratos subdimensionados que exigem alterações posteriores para tornar o objeto utilizável.
Por isso, a solução como um todo precisa ser lida junto com estimativas de quantidades, orçamento e contratações interdependentes.
Como a descrição influencia qualificação técnica
Requisitos de qualificação devem guardar relação com as parcelas tecnicamente relevantes do objeto. A visão da solução ajuda a identificar quais capacidades são realmente críticas, mas não justifica exigir experiência em todos os componentes de uma solução quando o contrato cobre apenas parte deles.
Se o TR contrata apenas infraestrutura de rede dentro de uma solução maior de segurança, a habilitação deve ser proporcional ao objeto daquele processo, não a toda a arquitetura que será implementada por múltiplos contratos.
Esse cuidado preserva competitividade sem perder aderência técnica.
Como a descrição influencia a gestão de riscos
Uma solução bem descrita facilita identificar riscos de interface, dependência e ciclo de vida. Ao enxergar o conjunto, a equipe consegue perguntar:
- o que acontece se uma contratação correlata atrasar;
- existe fornecedor único em alguma interface;
- há tecnologia com risco de obsolescência;
- a Administração possui capacidade de operar o sistema;
- manutenção depende de peças importadas;
- integração exige acesso a sistema existente;
- há necessidade de migração de dados;
- o aceite depende de teste integrado;
- existe risco de lacuna entre contratos.
A gestão de riscos nas contratações públicas ganha precisão quando a arquitetura da solução está visível.
O que o TCU aponta como risco da ausência dessa descrição
O TCU relaciona a falta da solução como um todo no TR à dificuldade de os licitantes compreenderem o contexto em que o objeto se insere, podendo resultar em propostas que não atendem à necessidade que originou a contratação.
Esse risco é especialmente forte em sistemas integrados e projetos multidisciplinares. O fornecedor pode cumprir literalmente seu escopo e ainda entregar algo que não funciona no ambiente final porque interfaces e dependências não estavam claras.
A função da seção é reduzir essa fragmentação de entendimento.
Erros recorrentes
Copiar a definição do objeto
Se a seção repete apenas “contratação de empresa para…”, não descreve a solução.
Listar equipamentos sem integração
A relação de itens não explica arquitetura nem resultado.
Inserir detalhes executivos cedo demais
O ETP não deve virar memorial executivo quando esse nível de detalhamento ainda depende do projeto.
Ignorar contratos correlatos
Partes contratadas separadamente continuam pertencendo à mesma solução.
Esquecer manutenção e operação
A solução precisa permanecer útil depois do recebimento.
Alterar a solução no TR sem registrar a mudança
Atualização é possível, mas mudanças materiais precisam de motivação e rastreabilidade.
Descrever solução maior e exigir habilitação sobre tudo
Qualificação deve ser proporcional ao objeto efetivamente licitado.
Checklist para o ETP
Antes de concluir a descrição da solução como um todo, verifique:
- o problema está claramente definido;
- a solução decorre do levantamento de alternativas;
- os principais componentes estão identificados;
- a integração entre componentes está explicada;
- manutenção e assistência foram avaliadas;
- ciclo de vida foi considerado;
- contratações correlatas e interdependentes estão visíveis;
- parcelamento foi analisado;
- providências da Administração foram identificadas;
- a solução é coerente com estimativa de quantidades e valor;
- a escolha continua tecnicamente e economicamente viável.
Checklist para o Termo de Referência
No TR, confira:
- a solução está coerente com o ETP;
- eventuais atualizações estão justificadas;
- o objeto específico está claramente posicionado dentro da solução;
- interfaces com outros contratos estão descritas;
- requisitos de integração são verificáveis;
- responsabilidades estão delimitadas;
- ciclo de vida do objeto foi considerado;
- critérios de execução, gestão, medição e aceite são compatíveis com a solução;
- não há contradição entre descrição, especificações e projeto;
- o fornecedor consegue compreender o resultado final esperado.
Relação com o planejamento técnico da contratação
A descrição da solução é uma peça de síntese. Sua qualidade depende das etapas anteriores do planejamento: demanda bem formalizada, requisitos consistentes, levantamento de mercado, escolha de alternativa, estimativas e avaliação de riscos.
Quando ela é fraca, normalmente existe um problema anterior que precisa ser corrigido. Quando é robusta, torna-se referência para TR, projeto, orçamento, licitação, execução, fiscalização e aceite.
A formalização da demanda no DFD e o programa de necessidades em engenharia ajudam a construir uma cadeia em que o problema é entendido antes de escolher a solução.
Considerações finais
“Descrição da solução como um todo” não é um campo burocrático do ETP ou do TR. É a representação da lógica técnica que liga necessidade, alternativa escolhida, componentes, interfaces e ciclo de vida.
Em contratações de engenharia, essa visão evita que a Administração compre partes corretas de um sistema errado ou incompleto. Ela também melhora parcelamento, orçamento, especificações, qualificação, gestão de riscos, fiscalização e comissionamento. O ETP deve explicar a solução selecionada; o TR deve posicionar o objeto dentro dela e atualizar o que for necessário sem perder rastreabilidade. Quando essa cadeia é coerente, a contratação deixa de ser uma soma de itens e passa a ser uma estratégia de entrega de resultado público.
Referências técnicas
[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021. Lei de Licitações e Contratos Administrativos. Art. 6º, XXIII, e art. 18, §1º. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm
[2] TRIBUNAL DE CONTAS DA UNIÃO. Licitações e Contratos: Orientações e Jurisprudência do TCU. Seção 4.1.7 — Descrição da solução como um todo. Disponível em: https://licitacoesecontratos.tcu.gov.br/4-1-7-descricao-da-solucao-como-um-todo/
[3] TRIBUNAL DE CONTAS DA UNIÃO. Licitações e Contratos: Orientações e Jurisprudência do TCU. Seção 4.3.3 — Descrição da solução como um todo no Termo de Referência. Disponível em: https://licitacoesecontratos.tcu.gov.br/4-3-3-descricao-da-solucao-como-um-todo/
[4] BRASIL. Instrução Normativa SEGES nº 58, de 8 de agosto de 2022. Dispõe sobre elaboração dos Estudos Técnicos Preliminares no âmbito federal. Disponível em: https://www.gov.br/compras/pt-br/acesso-a-informacao/legislacao/instrucoes-normativas/instrucao-normativa-seges-no-58-de-8-de-agosto-de-2022
[5] BRASIL. Instrução Normativa SEGES/ME nº 81, de 25 de novembro de 2022. Dispõe sobre elaboração do Termo de Referência no âmbito federal. Disponível em: https://www.gov.br/compras/pt-br/acesso-a-informacao/legislacao/instrucoes-normativas/instrucao-normativa-seges-me-no-81-de-25-de-novembro-de-2022
Perguntas frequentes
É a descrição integrada do conjunto de bens, serviços e demais elementos necessários para produzir o resultado que atende à necessidade da contratação, incluindo manutenção e assistência técnica quando aplicáveis.
Não. A solução pode ser mais ampla que o objeto de um processo específico. Um único ETP pode originar vários contratos, e cada objeto pode representar apenas parte da solução.
O TR deve apresentar a solução como um todo de forma coerente com o ETP, podendo transcrever ou sintetizar o conteúdo e incorporando atualizações decorrentes do amadurecimento da contratação.
Sim. O TCU destaca que elementos de uma solução podem ser parcelados em contratações diferentes, de modo que um único ETP pode resultar em mais de uma licitação ou contratação direta.
Significa avaliar não apenas a aquisição ou implantação, mas também operação, manutenção, assistência, suporte, atualização, expansão, consumo, descarte e outras etapas relevantes ao longo da vida útil.
Em regra, deve privilegiar função, desempenho, integração e resultados. Eventual indicação de marca ou padronização precisa observar as hipóteses legais e possuir justificativa técnica específica.
Ela preserva a visão integrada mesmo quando o objeto é dividido. Cada contrato precisa ter fronteiras e interfaces claras para que as partes parceladas continuem produzindo o resultado pretendido.
Materiais técnicos complementares
Serviços relacionados
- Estudo Técnico Preliminar (ETP) para Obras e Serviços de Engenharia
- Revisão Técnica de Termo de Referência para Obras e Serviços de Engenharia
- Planejamento Técnico de Contratações de Engenharia
- Projeto Básico de Engenharia
Conteúdos principais sobre o tema
- Estudo Técnico Preliminar (ETP) para Obras e Serviços de Engenharia: como estruturar uma contratação tecnicamente viável
- Especificação Técnica em Obras e Serviços de Engenharia