Levantamento de requisitos: o guia do fundador não-técnico

Antes de qualquer estúdio escrever uma linha de código, alguém precisa transformar “eu sei o problema” em “é isso que vamos construir”. Esse alguém é você. É o passo que a maioria dos fundadores terceiriza por engano, e depois paga caro.

Um fundador chegou até a gente com uma frase que já ouvimos dezenas de vezes: “quero um app tipo iFood, mas pra clínicas de estética agendarem com fornecedores”. Ele tinha o problema na ponta da língua. Tinha até a margem que ia ganhar. O que ele não tinha era a menor ideia do que isso virava na prática: quantas telas, quem aprova o quê, o que acontece quando o fornecedor cancela, se o pagamento passa por dentro ou por fora. Ele achou que o levantamento de requisitos era trabalho do estúdio. Não é.

Levantamento de requisitos é o processo de descobrir, organizar e registrar o que o software precisa fazer antes de alguém começar a construí-lo. É a ponte entre a dor do negócio, que você conhece melhor do que ninguém, e a especificação técnica, que você não precisa saber escrever. No desenvolvimento de software, é o que separa um projeto que rende cotação justa de um que vira retrabalho e boleto surpresa. E, ao contrário do que a maioria pensa, o protagonista desse processo não é o analista nem o desenvolvedor. É o fundador.

A literatura de engenharia chama isso de elicitação de requisitos. O nome é feio e a maior parte do que se escreve sobre ele foi feito para aluno de ciência da computação ou para quem está estudando pra concurso. Quase nada foi escrito para a pessoa que vai assinar o contrato. Este texto é para essa pessoa.

O que é levantamento de requisitos (sem o linguajar de apostila)

Levantamento de requisitos de software é a fase em que você responde a uma pergunta aparentemente simples: o que esse sistema precisa fazer, para quem, e em quais situações? A resposta vira uma lista de requisitos, ou seja, coisas que o software tem que dar conta. “O cliente agenda um horário”, “o fornecedor confirma ou recusa em até duas horas”, “o sistema cobra automaticamente quando o serviço é concluído”. Cada uma dessas frases é um requisito.

Vale separar três palavras que costumam ser usadas como sinônimo e não são. Levantamento (ou elicitação) é o ato de extrair os requisitos das pessoas e do processo. Análise de requisitos é o trabalho de organizar, priorizar e resolver as contradições do que você levantou. E o documento de requisitos é o registro final, o papel que você entrega ao estúdio para receber uma cotação. São três coisas em sequência. Este guia é sobre a primeira, que é a que ninguém faz direito.

Fred Brooks, que coordenou um dos maiores projetos de software da história, resumiu por que essa fase importa tanto: “a parte mais difícil de construir um sistema é decidir precisamente o que construir”. Escrever o código é a parte que tem solução conhecida. Saber o que pedir é onde os projetos morrem.

Por que o levantamento é seu trabalho, não do estúdio

A tentação é óbvia. Você contrata gente técnica justamente para não ter que entrar nesse detalhe. Por que não deixar o estúdio levantar os requisitos?

Porque o estúdio não conhece o seu negócio. Ele conhece software. Você sabe que a clínica de estética cobra sinal antecipado, que o fornecedor de toxina botulínica não entrega no fim de semana, que existe um cadastro da Anvisa que muda a regra para certos produtos. Nada disso está num briefing de uma linha. Se você não trouxer, o estúdio vai adivinhar. E vai adivinhar errado, porque está adivinhando sobre um setor que não é o dele.

Um bom parceiro técnico ajuda a fazer as perguntas certas e traduz suas respostas em especificação. Mas a matéria-prima é sua. Quando um fundador entrega “um app tipo iFood” e recebe algo que não serve, o reflexo é culpar o desenvolvedor. Na maioria das vezes, o desenvolvedor construiu exatamente o que foi pedido. O problema é que o pedido nunca existiu de verdade.

Há uma segunda razão, mais fria. Requisito vago é a porta de entrada do scope creep e do orçamento que dobra no meio do caminho. Quando o escopo está na sua cabeça e não no papel, cada nova tela vira “extra”, cada ajuste vira aditivo, e você perde a única alavanca de negociação que tinha: saber, antes de fechar, o que estava combinado. Quem faz o levantamento controla o contrato.

As técnicas de levantamento de requisitos que funcionam para um fundador

Os textos acadêmicos listam dez, quinze técnicas. Você precisa de quatro, e dá para rodar todas em uma semana sem contratar ninguém.

Entrevista com quem vive o problema. Sente com três a cinco pessoas que vão usar o sistema ou que sofrem hoje com a ausência dele. No caso da clínica, são as recepcionistas que agendam na mão e os donos que perdem fornecedor por desorganização. Não pergunte “que funcionalidade você quer”. Pergunte “me mostra como você faz isso hoje”. As funcionalidades aparecem sozinhas quando a pessoa descreve a dor real.

Observação do processo atual. Passe uma manhã olhando o trabalho acontecer. Quase sempre você descobre um passo que ninguém menciona em reunião porque virou automático — a planilha paralela, o grupo de WhatsApp onde as confirmações de verdade acontecem, o caderninho. Esses passos invisíveis são metade dos requisitos que faltariam no seu briefing.

Mapeamento do fluxo, do início ao fim. Pegue um caso real e siga ele do começo ao fim: cliente pede, recepção confirma, fornecedor é acionado, serviço é feito, pagamento acontece, comprovante é emitido. Cada seta entre dois passos é um requisito potencial. Cada ponto onde alguém pergunta “e se der errado aqui?” é um requisito que você teria esquecido.

Protótipo rápido como ferramenta de pergunta. Um desenho de tela, mesmo feio, faz a pessoa reagir de um jeito que nenhuma conversa abstrata consegue. “Ah, mas aqui também tem que mostrar o histórico do cliente” é o tipo de frase que só sai quando há algo concreto na frente. Protótipo, nessa fase, não é entrega. É instrumento de levantamento. (Vale entender a diferença entre wireframe, mockup e protótipo antes de pedir um.)

Existe ainda o workshop, juntar as pessoas numa sala e construir o fluxo coletivamente. Funciona bem quando há mais de um dono de decisão e eles discordam — o que é melhor descobrir agora do que depois do build.

As etapas: do levantamento ao que se entrega

Quem procura as “5 etapas da análise de requisitos” geralmente quer uma sequência. Aqui está a versão que serve a um fundador, sem nome bonito.

Primeiro, eliciar: rodar as técnicas acima e sair com uma lista crua, bagunçada, de tudo que apareceu. Nessa hora a meta é volume, não organização. Anote até o que parecer óbvio.

Segundo, organizar: agrupar o que é parecido, eliminar repetição e separar o que é regra do negócio (“clínica cobra 30% de sinal”) do que é tela (“botão de confirmar agendamento”).

Terceiro, priorizar: marcar o que precisa existir na primeira versão e o que pode esperar. Aqui o levantamento conversa diretamente com o escopo do seu produto mínimo viável. Requisito sem prioridade é desejo, e desejo todo mundo tem demais.

Quarto, validar: voltar para as mesmas pessoas que você entrevistou e ler a lista em voz alta. “É isso? Falta alguma coisa? Isso aqui acontece mesmo assim?” Metade dos erros caros morre nessa conversa de dez minutos.

Quinto, registrar: transformar a lista validada num documento que um estranho técnico consiga entender e cotar. Esse é o ponto em que o levantamento vira artefato, e é assunto de outro texto, sobre como montar um documento de requisitos que rende cotação.

Funcional e não funcional: a divisão que evita a maioria das surpresas

Os requisitos que você levanta vão se dividir em dois tipos, e ignorar o segundo é a causa silenciosa de muito projeto que “funciona na demo e quebra na vida real”.

Requisito funcional é o que o sistema faz: agendar, cobrar, notificar, gerar relatório. É o que aparece naturalmente nas entrevistas, porque é o que as pessoas pensam quando imaginam o produto.

Requisito não funcional é como o sistema precisa se comportar: quantos agendamentos simultâneos ele aguenta numa segunda-feira de manhã, em quanto tempo uma tela carrega, o que acontece com os dados se a internet cair no meio de um pagamento, quem pode ver o quê. Ninguém menciona isso espontaneamente, e por isso some do briefing. Some até o dia em que a clínica faz uma promoção, cem pessoas agendam ao mesmo tempo, e o sistema cai. Pergunte sobre volume, velocidade, segurança e privacidade ainda na fase de levantamento. Custa uma frase agora e um mês de retrabalho depois.

O erro que transforma levantamento em retrabalho

O padrão é sempre o mesmo. O fundador tem pressa, acha que requisito é burocracia, e resolve “ir ajustando no caminho”. Pula o levantamento, manda uma ideia genérica, aprova a primeira tela bonita que aparece e só percebe o buraco quando o produto já está meio construído e mudar custa caro.

A ironia é que pular o levantamento não economiza tempo. Empurra o tempo para frente, onde ele é mais caro. Descobrir um requisito faltando numa conversa de café custa uma frase. Descobrir o mesmo requisito com o código pronto custa uma sprint, às vezes duas. O levantamento não é o que atrasa o projeto. É o que evita que ele atrase.

Levantar requisitos bem não exige saber ler código nem virar gerente de tecnologia. Exige fazer perguntas chatas antes de qualquer pessoa começar a construir, e ter a disciplina de escrever as respostas. É um trabalho de fundador, no melhor sentido: você é a única pessoa que conhece o negócio fundo o bastante para fazê-lo, e é a pessoa que mais perde se ele não for feito.

Perguntas frequentes

O que é levantamento de requisitos?
É o processo de descobrir, organizar e registrar o que um software precisa fazer antes de começar a construí-lo. Envolve conversar com quem vai usar o sistema, observar o processo atual e mapear o fluxo do início ao fim, transformando a dor do negócio em uma lista clara de requisitos. Na prática, é a ponte entre “eu sei o problema” e “é isso que vamos construir”.

Quais são as 5 etapas da análise de requisitos?
Em sequência prática: eliciar (extrair os requisitos das pessoas e do processo), organizar (agrupar e separar regra de negócio de tela), priorizar (definir o que entra na primeira versão), validar (confirmar a lista com quem vive o problema) e registrar (transformar tudo num documento que um estúdio consiga cotar). As cinco juntas levam você do problema na cabeça ao papel na mesa.

Quais são 3 técnicas de levantamento de requisitos?
As três mais úteis para um fundador são a entrevista com quem sofre o problema hoje, a observação do processo atual acontecendo e o mapeamento do fluxo de ponta a ponta. Um protótipo rápido funciona como uma quarta técnica poderosa, porque faz as pessoas reagirem ao concreto e lembrarem de requisitos que esqueceriam numa conversa abstrata.

O que é um documento de levantamento de requisitos?
É o registro final do processo: a lista validada e organizada de tudo que o software precisa fazer, escrita de forma que um parceiro técnico consiga entender e cotar sem adivinhar. O levantamento é a atividade; o documento é o produto dela. Como montar esse documento sem ser técnico é assunto do nosso guia de documento de requisitos.