Modelo de RFP para desenvolvimento de software (pronto para copiar)

Uma RFP (Request for Proposal, ou pedido de proposta) para desenvolvimento de software é o documento formal que a empresa envia a vários fornecedores para receber propostas comparáveis: mesmo escopo, mesmos requisitos, mesmo formato de resposta e critérios de avaliação declarados. O modelo abaixo tem 12 seções prontas para copiar, do calendário do processo aos pesos de avaliação, e serve para sistemas sob medida, aplicativos e integrações.

Qual a diferença entre RFI, RFP e RFQ?

Os três documentos aparecem em processos de compra de tecnologia e costumam ser confundidos. Cada um responde a uma pergunta diferente.

Para desenvolvimento de software sob medida, a RFP é a mais comum, porque a solução técnica, a equipe e o modelo de trabalho mudam de fornecedor para fornecedor. Se você ainda está organizando o problema, comece pelo guia de como escrever um briefing de software que gera propostas comparáveis e use a RFP como etapa seguinte.

Como usar este modelo?

1. Reúna as áreas envolvidas (negócio, TI, segurança, jurídico e financeiro) antes de escrever.
2. Preencha as 12 seções e apague as que não se aplicam, dizendo por quê.
3. Defina os pesos de avaliação antes de enviar. Critério definido depois das propostas vira justificativa da escolha, não método.
4. Envie a mesma RFP a todos os fornecedores da lista curta, com o mesmo prazo.
5. Responda às dúvidas por escrito e compartilhe as respostas com todos.
6. Avalie com a planilha de pesos e só depois convide os finalistas para apresentar.

Modelo de RFP completo (copie a partir daqui)

1. Instruções e calendário

2. Sobre a empresa contratante

• Atividade, porte e mercados atendidos.
• Área dona do projeto e patrocinador.
• Equipe interna que vai participar (produto, TI, operação) e disponibilidade.

3. Objetivo e problema

• Problema de negócio a resolver, com números atuais (tempo de processo, retrabalho, custo, volume).
• Resultado esperado e como será medido.
• Usuários do sistema (perfis e quantidade aproximada).

4. Escopo

• Módulos ou funcionalidades principais, em ordem de prioridade.
• O que está fora do escopo nesta contratação.
• Entregas esperadas: código-fonte, documentação, ambientes, treinamento.
• Plataformas: web, aplicativo iOS e Android, painel administrativo.

5. Requisitos funcionais

Descreva os requisitos em uma tabela com identificador, para que as propostas respondam item a item. A norma ISO/IEC/IEEE 29148:2018 trata da engenharia de requisitos ao longo do ciclo de vida e pode servir de referência para a redação.

6. Requisitos não funcionais

A norma ISO/IEC 25010:2023 organiza a qualidade de um produto de software em nove características. Use-a como lista de verificação e peça metas mensuráveis:

• Desempenho: tempo de resposta esperado e volume de usuários simultâneos.
• Disponibilidade e confiabilidade: horário de operação, tolerância a falhas.
• Segurança: autenticação, perfis de acesso, registro de ações.
• Manutenibilidade: padrões de código, testes automatizados, documentação.
• Compatibilidade: navegadores, versões de sistema operacional, integrações.
• Acessibilidade e usabilidade para os perfis de usuário descritos.

7. Integrações e dados

• Sistemas que precisam conversar com a solução (ERP, CRM, meios de pagamento, APIs públicas).
• Quem fornece a documentação de cada integração.
• Migração de dados: origem, volume aproximado e qualidade conhecida.

8. Segurança e LGPD

• Dados pessoais tratados e categorias sensíveis, se houver.
• Papel do fornecedor: em regra, operador, que trata dados segundo as instruções da contratante (Lei 13.709/2018, art. 39).
• Medidas técnicas e administrativas de segurança exigidas (art. 46).
• Prazo para o fornecedor avisar a contratante sobre incidentes.
• Certificações, se houver, como a ISO/IEC 27001 (que define requisitos para um sistema de gestão de segurança da informação), com escopo e validade.
• Questionário de segurança anexo: use o modelo com 30 perguntas para fornecedores.

9. Propriedade intelectual e código-fonte

• Titularidade do código desenvolvido e dos artefatos.
• Entrega do repositório e das credenciais ao fim de cada fase.
• Uso de componentes de terceiros e licenças de código aberto.

Os pontos contratuais estão detalhados no artigo sobre código-fonte e propriedade intelectual no contrato de software.

10. Modelo comercial

• Modelo preferido ou aceito: escopo fechado, time and materials ou squad dedicado.
• Forma de pagamento desejada (por marco, mensal).
• Itens que devem vir com preço separado: desenvolvimento, infraestrutura, licenças, sustentação.

11. Equipe, governança e pós-entrega

• Perfis e dedicação da equipe proposta.
• Rituais de acompanhamento e relatórios.
• Garantia após a entrega e prazo para correções.
• Proposta de sustentação e acordo de nível de serviço (SLA).

12. Formato da proposta e critérios de avaliação

A proposta deve conter, nesta ordem: entendimento do problema, solução proposta, resposta item a item aos requisitos, arquitetura e tecnologias, cronograma com marcos, equipe, preço, premissas e riscos, e três cases semelhantes com contato de referência.

Os pesos são um exemplo. Ajuste-os ao risco do projeto, mas declare-os na RFP.

Quais erros mais comprometem uma RFP?

• Pedir preço fechado com escopo aberto. O fornecedor embute risco no valor ou corta qualidade.
• Copiar requisitos de outro projeto sem revisar.
• Esconder o orçamento. Uma faixa de investimento evita propostas fora da realidade.
• Não dizer o que está fora do escopo.
• Prazo de resposta curto demais para a complexidade pedida.
• Avaliar só o preço. Diferenças grandes de valor costumam refletir diferenças de equipe, escopo ou premissas.

Para escolher o modelo comercial certo, veja escopo fechado, time and materials ou squad dedicado.

Próximo passo

Monte a lista curta de fornecedores nos rankings de software houses ou no diretório de empresas, conferindo avaliações verificadas e cases antes de enviar a RFP. Se a sua empresa desenvolve software, crie ou reivindique o perfil gratuito para ser encontrada por quem está preparando o próximo processo de contratação.

Fontes

• ISO — ISO/IEC/IEEE 29148:2018, engenharia de requisitos — referência para a redação e o processo de requisitos
• ISO — ISO/IEC 25010:2023, modelo de qualidade de produto — modelo com nove características de qualidade usado nos requisitos não funcionais
• Planalto — Lei nº 13.709/2018 (LGPD) — papel do operador (art. 39) e dever de adotar medidas de segurança (art. 46)
• ISO — ISO/IEC 27001:2022, sistemas de gestão de segurança da informação — referência de requisitos de segurança que pode ser exigida do fornecedor