Documento de requisitos: o guia do fundador não-técnico para fazer um que rende cotação
O que entra, o que fica de fora, e o teste de quando o documento está pronto para mandar para uma fábrica de software.
Em uma terça à tarde, uma fundadora de uma fintech em São Paulo abriu o e-mail e leu três cotações que ela tinha pedido para fábricas de software diferentes, baseadas no mesmo documento de 14 páginas que ela passou um fim de semana inteiro escrevendo. Uma cotação dizia R$ 180 mil em quatro meses. A segunda dizia R$ 420 mil em sete meses. A terceira não vinha como cotação. Vinha como uma lista de 27 perguntas e uma frase: “antes de cotar, precisamos entender melhor.”
As três fábricas leram o mesmo documento e chegaram a três decisões diferentes. Não porque uma estava certa e as outras erradas. Porque o documento não decidia nada por elas.
Esse é o problema central que um documento de requisitos resolve quando funciona, e o problema que ele cria quando é escrito como se fosse uma redação do ensino médio, ou pior, como se fosse a especificação de um sistema bancário de 1998. Para a fundadora não-técnica que está prestes a contratar a primeira versão de um produto, o documento de requisitos não é um exercício acadêmico. É a peça que define quanto custa, quanto demora, e o que vai chegar.
Este guia mostra o que entra, o que fica de fora, e como saber quando o documento está pronto para sair pela porta.
O que é um documento de requisitos, em uma frase
Um documento de requisitos descreve o que um software precisa fazer (e o que ele não precisa fazer) com nível de detalhe suficiente para que uma equipe de desenvolvimento o estime, contrate e construa sem rodadas infinitas de esclarecimento.
É uma definição modesta de propósito. O documento não é a especificação completa do produto. Não é o contrato. Não é o roadmap. É o instrumento que faz a ponte entre o problema que você descreve com clareza (porque é o seu negócio) e o sistema que alguém vai construir (porque é o ofício deles). Tudo que o documento precisa fazer é deixar essa travessia barata.
Quando funciona, três fábricas leem o documento e voltam com cotações próximas em prazo, escopo e preço, com perguntas pontuais em vez de listas de 27 itens. Quando não funciona, você recebe três planos para três produtos diferentes.
Por que o modelo SRS da faculdade não serve para você
O termo técnico é SRS: Software Requirements Specification. É o documento que cursos de Engenharia de Software ensinam a escrever desde os anos 80. A maioria dos modelos que aparecem em primeiro lugar no Google quando você procura “documento de requisitos” são variações desse padrão: índice de 14 seções, requisitos funcionais e não-funcionais separados, diagrama de casos de uso, glossário, matriz de rastreabilidade.
Esse modelo foi projetado para uma realidade que não é a sua. Foi feito para projetos de software contratados por grandes empresas, com prazos de dois a cinco anos, equipes internas de QA que vão testar contra a especificação, e auditoria regulatória depois da entrega. Em uma fintech early-stage, uma clínica que está montando o backoffice, um marketplace de nicho fazendo a primeira versão, esse formato falha por três motivos:
É longo demais. Um SRS bem feito tem 40 a 120 páginas. Nenhuma fábrica de software vai ler 80 páginas antes de cotar. Vão fazer skim das primeiras dez, identificar três pontos confusos, e te mandar a lista de perguntas. Você gastou um fim de semana e está no mesmo lugar.
É feito para validar entrega, não para vender o projeto internamente. O SRS tradicional documenta “o que o sistema vai fazer” para que depois alguém possa testar se ele fez. Você não precisa disso ainda. Você precisa que três fábricas concordem em quanto custa o que você quer.
Pede precisão técnica que você não tem. Requisitos não-funcionais, restrições de arquitetura, modelo de dados conceitual. Se você soubesse escrever isso bem, não estaria procurando uma fábrica. A tentativa de soar técnica produz documentos que ou estão errados (uma fábrica vai notar) ou estão vagos demais (todas vão notar).
A alternativa não é não escrever nada. É escrever um documento mais curto, mais opinativo, e dirigido para um leitor específico: a pessoa que vai cotar o seu projeto.
Os 5 blocos que cabem em 8 páginas
O documento que funciona para uma fundadora não-técnica tem cinco blocos. Cabe em seis a oito páginas. É escrito em prosa, com listas onde a lista ajuda. Cada bloco tem um propósito declarado.
Bloco 1: O problema, em até uma página. Quem é o usuário, qual é a dor real, e por que a dor existe agora. Não é o pitch deck. É a descrição honesta da situação: a operação manual que você está substituindo, a planilha que quebrou, o processo que existe no WhatsApp e precisa virar produto. Quem vai cotar usa essa página para calibrar tudo o que vem depois. Se a dor parece pequena, o orçamento parece grande. Se a dor é óbvia, o resto do documento ganha o benefício da dúvida.
Bloco 2: O usuário, em uma página ou menos. Um parágrafo por persona, com no máximo três personas. Para cada uma: o que ela faz hoje, o que ela precisa que o produto faça, e onde ela usa (mobile, desktop, no balcão, em casa). É aqui que perguntas como “precisa funcionar no celular?” e “tem acesso offline?” se respondem sem virar requisito não-funcional. Eles viram fato de uso.
Bloco 3: O escopo, na forma “entra/fica de fora”, em duas a três páginas. Esta é a parte mais valiosa do documento, e a que mais founders subestimam. Em vez de listar tudo que o sistema vai fazer, divida em duas colunas: o que entra na primeira versão, e o que fica de fora (mas você sabe que existe). A coluna “fica de fora” é o que dá segurança à fábrica para cotar a coluna “entra”. Sem ela, toda fábrica precifica como se o escopo fosse infinito, porque é o que founders normalmente fazem com escopo. Itens típicos da coluna “entra” são funcionalidades concretas: cadastro de cliente, criação de orçamento, exportação para PDF, integração com Pagar.me. Itens típicos da coluna “fica de fora” são funcionalidades que vão existir um dia mas não agora: app nativo, dashboard de BI, integração com o ERP da contabilidade, plano gratuito.
Bloco 4: Os critérios de pronto, em uma página. Para a primeira versão, três a cinco frases que descrevem o que tem que ser verdade no dia do lançamento. “Um corretor consegue cadastrar um imóvel, gerar uma proposta em PDF, e enviá-la para um cliente em menos de cinco minutos.” “A diretoria consegue ver, no fim do mês, quantas propostas viraram contrato.” Esses critérios funcionam como contrato silencioso: você não está aceitando o produto se algum deles ainda não acontece. Eles também ajudam a cotar, porque dizem para a fábrica onde a barra está. Uma frase de critério como “o sistema precisa ter 99,99% de uptime” é cara. “O sistema não pode cair durante o horário comercial de São Paulo” é mais barato e diz quase a mesma coisa para o seu negócio.
Bloco 5: Restrições reais, em meia página. Tempo, dinheiro, regulação. Quando você precisa estar no ar (e por quê). Qual é o teto de orçamento (esteja preparada para responder honestamente; cotações chegam mais próximas da realidade quando o teto está na mesa). Que regulação se aplica (LGPD sempre; PCI se for guardar cartão; HIPAA se for saúde nos EUA; Bacen se for fintech regulada). É o bloco mais curto e o que mais economiza retrabalho. Uma fábrica que sabe que você tem três meses até a próxima parcela de captação vai cotar de forma diferente de uma que acha que tem um ano.
Cinco blocos. Seis a oito páginas. Escrito em fim de semana sem stress, ou em duas tardes com foco. Esse é o documento que rende cotação.
Como documentar requisitos de forma simples
A resposta curta é: você descreve cada bloco em uma reunião de 15 minutos com você mesma antes de escrever. Você abre um documento em branco, coloca o nome do bloco no topo, e responde em voz alta, gravando ou escrevendo do jeito que vier. O texto bonito vem depois.
A armadilha da escrita “técnica” é o que mata a maioria dos documentos. Founders não-técnicos tentam soar como engenheiros porque assumem que essa é a língua que a fábrica espera. Não é. Fábricas de software boas leem o documento em voz alta como se fosse uma reunião comercial. Elas confiam mais em uma descrição clara do problema do que em um diagrama de UML mal desenhado. Se você ficar em dúvida entre “soar profissional” e “ser literal sobre o que está acontecendo”, escolha sempre a segunda.
A segunda armadilha é querer cobrir tudo. Você não vai. Não tem como. O documento de requisitos da primeira versão é, por design, um instrumento incompleto. Ele descreve a primeira versão, não o produto final. Toda decisão que você não tomou agora vira uma pergunta da fábrica depois, e isso é normal. O que você quer evitar é o documento que parece completo mas é vago, porque ele vai gerar perguntas piores: perguntas que parecem detalhe e na verdade são escopo.
A terceira armadilha é deixar o documento parado por semanas porque está “quase pronto”. A versão 0.9 de quem é dona do problema vence a versão 1.0 imaginária todas as vezes. Se o documento atende aos cinco blocos, está pronto.
O teste de cotação: três sinais de que o documento está pronto
Não há checklist objetiva para “documento pronto”, mas há três sinais empíricos que aparecem repetidamente.
Sinal 1: Você consegue ler o documento em voz alta sem precisar abrir parênteses. Se você precisa explicar uma frase enquanto lê, a frase não está pronta. Reescreva. A regra vale para qualquer parágrafo do documento.
Sinal 2: Um amigo do seu nicho de negócio, sem conhecimento técnico, consegue ler e dizer “entendi o que esse produto vai fazer”. Se ele não consegue, a fábrica também não vai. O teste serve para os Blocos 1 a 3 (problema, usuário, escopo).
Sinal 3: Você consegue listar três coisas que ficaram de fora intencionalmente. Se você não consegue, não decidiu o suficiente. Volte ao Bloco 3 e tire mais coisas. “Tudo entra na primeira versão” é o que produz cotações infladas e cronogramas que escorregam.
Quando os três sinais aparecem, o documento está pronto para sair. Mande para duas a quatro fábricas ao mesmo tempo. Você vai aprender mais com a diferença entre as cotações do que com cada cotação isolada.
Onde o documento de requisitos termina e o contrato começa
Confundir documento de requisitos com contrato é a versão mais cara desse erro. O documento de requisitos é um instrumento de comunicação. Ele não obriga ninguém a nada. Ele descreve o produto que você quer e o problema que ele resolve.
O contrato de desenvolvimento de software é o instrumento legal que regula a relação. Ele cobre prazo, preço, condições de pagamento, propriedade do código, garantia, e o que acontece se uma das partes quebrar a promessa. Em geral o contrato anexa o documento de requisitos por referência, mas o contrato governa, não o requisito.
A separação importa porque os dois documentos têm leitores diferentes. O documento de requisitos é lido pela equipe técnica que vai construir. O contrato é lido pela área jurídica (sua e a deles) e por você, no momento de assinar. Se você tenta colocar cláusula contratual no meio do documento de requisitos, você confunde a fábrica. Se você tenta descrever funcionalidade dentro do contrato, você cria um documento legal que envelhece em duas semanas.
A regra prática: o documento de requisitos descreve o produto. O contrato descreve a relação. O escopo vive no requisito. O preço, no contrato. As mudanças que acontecem durante o build vivem em um terceiro documento (geralmente uma ata de reunião ou um ticket no sistema da fábrica), e periodicamente disparam aditivos ao contrato.
Esse trio (requisito, contrato, ata) é o que sustenta um projeto sem ruído. E é onde a análise de fit com a fábrica também acontece: a forma como ela responde ao seu documento de requisitos diz mais sobre como ela vai trabalhar com você do que qualquer apresentação comercial.
Perguntas frequentes
O que significa “requisitos”?
No contexto de software, requisitos são as descrições do que o sistema precisa fazer (requisitos funcionais) e das condições em que ele precisa fazer isso (requisitos não-funcionais, como desempenho, segurança, disponibilidade). Para uma fundadora não-técnica, a tradução prática é: “o que o produto entrega” e “sob quais limites ele entrega”.
Como documentar requisitos de forma simples?
Em cinco blocos curtos: o problema, o usuário, o escopo (entra/fica de fora), os critérios de pronto, e as restrições reais (tempo, dinheiro, regulação). Seis a oito páginas no total. Em prosa, não em diagrama. Escrito para um leitor específico: a fábrica que vai cotar. Detalhes na seção “Os 5 blocos que cabem em 8 páginas” acima.
Documento de requisitos é a mesma coisa que PRD ou especificação funcional?
São primos próximos, mas não a mesma coisa. O documento de requisitos descreve o que o sistema precisa fazer. O PRD (Product Requirements Document) é mais comum em produto interno de empresas com time de PM e descreve o que o produto resolve e para quem, geralmente sem detalhe técnico. A especificação funcional mergulha em telas, fluxos e regras de negócio com mais profundidade. Para uma primeira contratação com uma fábrica, o documento de requisitos curto descrito aqui é normalmente suficiente; PRD e especificação funcional aparecem depois, quando o produto já está rodando e você ou a fábrica precisam coordenar mais detalhe.
Quais são os 4 tipos de documentos que aparecem no ciclo de compra de software?
Em uma compra típica de software custom: o brief (uma a duas páginas que você usa para se apresentar a fábricas e descobrir quem topa conversar), o documento de requisitos (este aqui, seis a oito páginas), o contrato (instrumento legal entre você e a fábrica escolhida), e o SOW (Statement of Work, que em alguns formatos contratuais substitui ou complementa o documento de requisitos no anexo do contrato). Os quatro têm leitores diferentes e propósitos diferentes; misturá-los é o erro mais caro do processo.
Posso pedir para a fábrica escrever o documento de requisitos para mim?
Pode, e às vezes é a coisa certa a fazer (especialmente se você já tem uma fábrica de confiança e vai contratar discovery formal). Mas o resultado costuma ser melhor quando o documento sai da sua cabeça primeiro, mesmo que rabiscado. Você é a única pessoa que conhece o problema com profundidade. A fábrica vai melhorar a forma. Ela não consegue inventar o problema.
Quando o documento de requisitos precisa virar especificação detalhada?
Quando o projeto sai da primeira versão. Para a primeira versão, o documento curto basta porque a maior parte do detalhe é descoberta durante a construção em conversas com a fábrica. A partir da segunda versão (ou de um pivô significativo), os blocos do documento se separam em artefatos maiores: o escopo vira backlog, os critérios de pronto viram testes, as restrições viram política técnica documentada.