Caderno de Encargos de Software à Medida: Guia 2026

A maioria dos projetos de software à medida que correm mal em Portugal não falha a escrever código. Falha antes disso, no momento em que a empresa pede orçamentos com uma ideia na cabeça e meia dúzia de frases num email. Cada fornecedor percebe uma coisa diferente, os orçamentos vêm com valores que não se conseguem comparar, e três meses depois ninguém sabe ao certo o que estava combinado. O documento que evita quase tudo isto tem um nome pouco sedutor: caderno de encargos.

Se procurar o termo, só encontra concursos públicos com dezenas de páginas de cláusulas jurídicas. Isso assusta e leva muita PME a saltar a etapa, o que é exatamente o erro. Um caderno de encargos para um projeto privado não precisa de ser um calhamaço legal. Precisa de descrever, com clareza suficiente para um estranho perceber, o problema que quer resolver, o que o software tem de fazer e como vão saber que ficou bem feito. Faça isto bem e transforma uma conversa vaga num concurso justo, em que compara maçãs com maçãs e em que o fornecedor sabe ao que vai. Este guia mostra como escrever esse documento sem o complicar.

O que é (e para que serve) um caderno de encargos

Num contexto privado, o caderno de encargos é o documento que diz ao fornecedor o que precisa e com que regras, antes de haver contrato. Não é a proposta (isso é a resposta dele), nem o contrato (isso vem depois e fecha o que ficou acordado). É a pergunta bem feita.

Serve três propósitos que valem o tempo que leva a escrevê-lo:

• Compara orçamentos a sério. Se todos os fornecedores respondem ao mesmo documento, as diferenças de preço passam a ser informação, não ruído. Quando um cobra metade do outro, vê porquê.
• Protege-o de derrapagens. O que não está escrito vira "extra" a meio do projeto, sempre a seu favor do fornecedor. O caderno de encargos é a fronteira entre o que está orçamentado e o que é trabalho adicional.
• Obriga-o a pensar. Metade do valor do documento é para si. Escrever os requisitos expõe as decisões que ainda não tomou, e é muito mais barato descobri-las agora do que a meio do desenvolvimento.

Comece pelo problema, não pela lista de funcionalidades

O erro mais comum é abrir o documento com uma lista de ecrãs e botões. Isso amarra o fornecedor à sua primeira ideia de solução, que quase nunca é a melhor. Comece um nível acima: que problema do negócio está a tentar resolver, quem são as pessoas que vão usar isto todos os dias, e o que é que tem de ficar melhor para o projeto ter valido a pena.

Um exemplo concreto. "Queremos uma aplicação com login, dashboard e relatórios" é uma lista de funcionalidades. "Os nossos técnicos perdem duas horas por dia a passar folhas de obra do papel para o Excel, e no fim do mês ninguém confia nos números" é um problema. A segunda versão deixa o fornecedor propor uma solução que talvez nem precise de dashboard. Descreva o estado atual, o que dói nele, e como seria o dia a dia se estivesse resolvido.

A estrutura de um caderno de encargos que funciona

Para um projeto de PME, um bom caderno de encargos cabe em cinco a doze páginas e tem esta espinha dorsal:

1. Contexto e objetivos. A empresa, o problema, quem vai usar o software e o resultado de negócio esperado. Duas ou três páginas, no máximo.
2. Requisitos funcionais. O que o software tem de fazer, um comportamento por linha, cada um verificável. "O sistema permite registar uma obra com cliente, morada e fotografias" é testável. "O sistema deve ser intuitivo" não é.
3. Requisitos não funcionais. Desempenho, disponibilidade, segurança e, em Portugal, conformidade com o RGPD sempre que houver dados pessoais. Quantos utilizadores em simultâneo, em que dispositivos, com que tempos de resposta.
4. Integrações e dados. Com que sistemas tem de falar (faturação, ERP, site, banco), que dados existem hoje e que dados é preciso migrar. É aqui que mora grande parte do custo, por isso não o deixe de fora.
5. Entregáveis, fases e critérios de aceitação. O que recebe no fim (código, documentação, formação), em que fases, e como decidem em conjunto que cada fase está concluída.

Separe sempre o que é indispensável do que é desejável. Um fornecedor honesto usa essa distinção para lhe dar uma primeira versão mais barata e rápida; um documento sem ela produz orçamentos inflacionados "por segurança".

Os erros que afundam o projeto

• Pedir tudo para a primeira versão. Quanto mais funcionalidades mete como indispensáveis, mais caro, mais lento e mais arriscado fica. Defina o que resolve 80% da dor e deixe o resto para depois. Veja quanto tempo demora desenvolver software à medida para calibrar expectativas.
• Esconder o orçamento. Não dizer quanto tem para gastar não lhe dá vantagem, dá-lhe propostas que não consegue comparar. Um intervalo ("entre 15.000€ e 25.000€") deixa o fornecedor dimensionar a solução ao seu bolso.
• Confundir caderno de encargos com contrato. Não encha o documento de cláusulas de penalização nesta fase. Isso trata-se no contrato de desenvolvimento de software, depois de escolher o parceiro.
• Especificar a tecnologia sem motivo. A não ser que tenha uma razão real (integrar com um sistema existente, por exemplo), não imponha a linguagem ou a framework. Descreva o resultado e deixe o fornecedor propor como lá chegar.
• Esquecer a manutenção. O software não acaba no lançamento. Diga desde já que quer uma proposta de manutenção e suporte, para não ser apanhado de surpresa.

Modelo prático para adaptar

Não precisa de começar do zero. Uma estrutura em secções numeradas, uma folha de requisitos funcionais em tabela (ID, descrição, prioridade, critério de aceitação) e uma secção de integrações costuma chegar para um projeto de PME. Mantenha cada requisito numa linha, dê-lhe um identificador (RF-01, RF-02) e marque a prioridade como "indispensável" ou "desejável". Essa tabela sozinha resolve metade das discussões futuras, porque passa a existir uma lista única a que ambos os lados se referem.

Uma nota sobre o RGPD, que em Portugal não é opcional. Se o software vai tratar dados de clientes, trabalhadores ou doentes, diga-o explicitamente no caderno de encargos: que dados, com que base legal, por quanto tempo, e que medidas de segurança espera. É mais fácil o fornecedor orçamentar isso à partida do que o acrescentar no fim.

E depois do caderno de encargos

Com o documento na mão, envie-o a três ou quatro fornecedores e marque uma conversa com cada um. As melhores respostas não são as que dizem "sim" a tudo, são as que lhe fazem perguntas que você não tinha considerado. Isso é sinal de que leram o documento e de que pensam no seu problema, e não só no orçamento.

A partir daqui, o caminho é escolher o parceiro certo (veja como escolher uma empresa de software em Portugal) e, se o que procura afinal é um sistema de gestão de prateleira em vez de algo à medida, perceber primeiro software à medida versus SaaS. Seja qual for o rumo, um bom caderno de encargos é o que separa um projeto que ficou dentro do orçamento de um que virou dor de cabeça. Se quiser, podemos ajudar a transformar a sua ideia num caderno de encargos claro antes de pedir orçamentos.