Como Escrever Requisitos de Software Sem Ser Técnico

Introdução

Um projeto de sete anos e quinhentos milhões de euros foi cancelado não porque o software fosse ruim, mas porque ninguém conseguiu explicar com clareza o que ele precisava fazer. Foi o que aconteceu com a Lidl, uma das maiores redes de supermercados do mundo. O projeto foi construído sobre o SAP, sistema usado sem esse tipo de problema por milhares de outras empresas. O erro não estava na tecnologia. Estava em como o negócio explicou o que precisava construir. Esse mesmo erro se repete, em escala menor, toda vez que um gestor sem formação técnica tenta descrever um sistema, um aplicativo ou uma funcionalidade para uma equipe de desenvolvimento. Este artigo ensina como escrever requisitos de software com um método de cinco perguntas que não exige nenhuma linha de código.

Por que requisitos mal escritos custam tão caro: o caso Lidl

Um estudo da BCG entrevistou executivos de vinte e cinco setores diferentes para entender por que projetos de tecnologia atrasam e estouram o orçamento. A BCG é uma consultoria global de estratégia. A resposta não foi falta de tecnologia boa. Foi falta de alinhamento entre quem pede o sistema e quem constrói. Quando o objetivo de negócio não fica claro desde o início, a equipe técnica preenche as lacunas do jeito que consegue: com suposições. E suposição em projeto de software tem outro nome, que todo gestor já sentiu na pele: retrabalho.

Foi exatamente isso que aconteceu com a Lidl. Cada equipe interna interpretou os requisitos à sua maneira, porque as regras de negócio nunca foram documentadas de forma unificada. Sem esse alinhamento, o projeto foi ganhando customizações sobre customizações até ninguém mais conseguir controlar o que o sistema deveria fazer. Sete anos depois, a solução foi cancelar o projeto por completo.

A boa notícia para quem lê este artigo é que a maioria dos gestores não precisa aprender a programar para evitar esse cenário. Precisa aprender a descrever o que quer com clareza suficiente para que a equipe técnica não tenha que adivinhar. Isso é o núcleo de qualquer levantamento de requisitos de software bem feito, e é uma habilidade que se desenvolve com prática, não com curso de programação.

O erro mais comum: descrever a solução em vez do problema

O erro mais comum que aparece quando um cliente chega com uma demanda de software é esse: descrever a solução que imaginou, em vez do problema que precisa resolver. É um dos erros comuns em requisitos de software que mais custa caro, porque o pedido parece claro quando na verdade esconde perguntas sem resposta.

O exemplo clássico é o pedido: "preciso de um botão que gere um relatório em PDF." Parece objetivo, mas não é. Qual relatório? Com quais dados? Para quem? Com que frequência? O que essa pessoa faz com o PDF depois de gerado? Sem essas respostas, a equipe técnica só tem duas opções: perguntar tudo de novo ou construir o que foi pedido literalmente, mesmo que não resolva o problema real.

Talvez a resposta certa para esse pedido nem seja um botão que gera PDF. Talvez seja um painel que mostra as informações em tempo real, sem precisar gerar nada. Isso só aparece quando alguém pergunta qual é o problema por trás do pedido, em vez de aceitar de imediato a solução que o cliente já trouxe pronta na cabeça. Descrever o problema é o que abre espaço para a equipe técnica encontrar o melhor caminho, e quase nunca esse caminho é o primeiro que veio à mente de quem pediu.

Quando você descreve a solução que imaginou, você limita as opções da equipe técnica. Quando você descreve o problema, você abre espaço para a melhor solução aparecer.

Como escrever requisitos de software: as cinco perguntas que organizam qualquer requisito

Existe um método simples para não cair nesse erro, e é na prática um guia de requisitos de software para gestores não técnicos que funciona antes de qualquer reunião de escopo. Toda vez que precisar descrever uma funcionalidade, um sistema ou um aplicativo para uma equipe de desenvolvimento, você pode passar pelas cinco perguntas abaixo. As respostas não precisam ser perfeitas. Precisam ser honestas, e é isso que transforma um pedido vago num briefing de projeto de software que qualquer equipe consegue executar sem adivinhar nada.

• 1Qual problema estou tentando resolver? Não é o que o sistema deve fazer, é qual dor existe hoje. "Minha equipe gasta quatro horas por dia consolidando dados de vendas em planilhas manuais" é um problema claro que qualquer equipe técnica consegue atacar.
• 2Quem vai usar isso no dia a dia? Um gerente de operações tem necessidades diferentes de um analista financeiro. Descreva o que essa pessoa faz hoje, passo a passo, para resolver o problema sem o sistema: isso muda completamente como a solução deve ser desenhada.
• 3O que já existe hoje? Qual sistema, planilha ou processo manual está em uso agora. Um projeto de software quase nunca parte do zero, e mapear isso desde o início evita a surpresa de uma integração que ninguém previu.
• 4Como vou saber se funcionou? "O sistema precisa ser rápido" não é um critério de sucesso. "O relatório precisa ser gerado em menos de três segundos" é. Definir o que significa pronto antes de começar evita o ciclo infinito de ajustes onde ninguém fica satisfeito.
• 5O que não pode acontecer de jeito nenhum? Às vezes é mais fácil definir os limites do que o destino. "O sistema não pode aprovar um pedido sem a assinatura do gestor" protege uma regra de negócio que não pode ser quebrada, e restrições assim são tão importantes quanto qualquer funcionalidade nova.

Como aplicar o método na prática: o case de uma rede de clínicas

Alguns meses atrás, o diretor de operações de uma rede de clínicas chegou pedindo "um aplicativo para os pacientes", nas palavras dele. Ao aplicar as cinco perguntas nessa primeira reunião, o escopo do projeto mudou completamente de forma.

O problema real não era a falta de um aplicativo: era que os pacientes ligavam para a clínica para confirmar consultas, reagendar horários e pedir resultado de exame, e a recepção não dava conta do volume. O usuário real também não era só o paciente. Era a recepcionista, que precisava de um painel para gerenciar tudo isso em um só lugar. Além disso, o sistema precisava se integrar ao prontuário eletrônico que a clínica já usava, porque criar um cadastro paralelo de pacientes geraria mais problema do que solução.

O critério de sucesso definido foi reduzir em pelo menos quarenta por cento as ligações recebidas pela recepção. A restrição inegociável foi que nenhum dado de paciente poderia ficar armazenado fora dos servidores da própria clínica. Ela veio direto da pergunta sobre o que não podia acontecer de jeito nenhum.

Com essas respostas em mãos, o escopo ficou claro antes de qualquer linha de código, e isso é o que permite definir o escopo de um projeto de software com previsibilidade. O projeto foi entregue dentro do prazo e a clínica atingiu a meta de redução de ligações já no segundo mês de operação, sem que a equipe de desenvolvimento precisasse adivinhar nada pelo caminho.

Requisito de negócio x requisito técnico: qual a diferença

As respostas às cinco perguntas formam o que se chama de requisito de negócio: o problema e o contexto que o gestor descreve, sem precisar de nenhum vocabulário técnico. É o material que qualquer diretor de operações, product owner ou founder consegue produzir sozinho, numa reunião ou num documento simples.

A partir daí, entra o trabalho da equipe técnica: traduzir esse requisito de negócio em requisito funcional e não funcional. O requisito funcional descreve o que o sistema deve fazer. O requisito não funcional descreve como o sistema deve se comportar enquanto faz isso, como o tempo de resposta, o nível de segurança dos dados ou a disponibilidade do serviço.

Entender essa diferença evita uma armadilha comum: gestores tentando escrever requisito funcional e não funcional sem ter o vocabulário técnico para isso, e acabando com um documento confuso que mistura os dois. O papel de quem não é técnico é entregar um bom requisito de negócio. Traduzir isso em termos de engenharia é trabalho da equipe de desenvolvimento, não do gestor que abriu o projeto.

Como transformar as respostas em um documento que a equipe técnica entende

Depois de responder as cinco perguntas para cada funcionalidade, o próximo passo é organizar essas respostas num documento de requisitos de software que não dependa de ninguém explicar tudo de novo numa ligação. O erro mais comum aqui é misturar tudo em um texto único, onde fica difícil saber qual resposta pertence a qual funcionalidade.

1. 1Separe por funcionalidadeTrate cada funcionalidade, tela ou fluxo como um bloco independente, com suas próprias cinco respostas, em vez de descrever o sistema inteiro de uma vez.
2. 2Estruture cada bloco na mesma ordemProblema, usuário, contexto atual, critério de sucesso e restrição, sempre nessa sequência, para que a equipe técnica saiba onde procurar cada informação.
3. 3Use linguagem simplesEscreva com os mesmos termos que usaria numa conversa, sem forçar um vocabulário técnico que nem o próprio gestor domina. Um exemplo concreto vale mais que uma definição abstrata.
4. 4Compartilhe antes da reunião de escopoEnvie o documento para a equipe técnica com antecedência. As perguntas de acompanhamento chegam mais direcionadas quando todos já leram o mesmo material.

Esse mapeamento de requisitos, aliás, é exatamente o ponto de partida da metodologia da Agence, que organiza cada projeto do levantamento de requisitos até a entrega contínua, em vez de tratar essa etapa como um documento burocrático a mais no início do projeto.

Quando vale a pena chamar uma consultoria para ajudar no levantamento de requisitos

Nem todo levantamento de requisitos precisa de ajuda externa, mas alguns sinais indicam que vale a pena buscar apoio especializado antes de abrir o projeto. Projetos que envolvem integração com vários sistemas já existentes tendem a esconder regras de negócio que só aparecem quando alguém experiente pergunta pelos lugares certos. Isso é comum em integrações com ERP ou prontuário eletrônico, por exemplo. Times que nunca conduziram um levantamento de requisitos estruturado antes também se beneficiam de um método já validado, em vez de aprender por tentativa e erro no meio de um projeto real, especialmente em projetos de desenvolvimento web que precisam se conectar a sistemas legados sem repetir os erros do passado.

Histórico recente de retrabalho é outro sinal claro de que vale a pena buscar apoio para evitar retrabalho em projetos de TI. O mesmo vale para projetos anteriores que estouraram prazo por falta de alinhamento inicial. Prazos e orçamentos apertados pesam ainda mais nesses casos, porque o custo de um requisito mal escrito só aparece depois que o desenvolvimento já começou. Quando falta gente disponível para conduzir esse levantamento internamente, um time de outsourcing de TI pode assumir o mapeamento de requisitos junto com o restante do desenvolvimento, seja em projetos web ou de aplicativos.

Perguntas frequentes sobre requisitos de software

Comece o projeto com o escopo claro, antes da primeira reunião técnica

O método das cinco perguntas é o mesmo mapeamento de requisitos que a Agence usa como primeira etapa em projetos de desenvolvimento web, aplicativos e outsourcing de TI. Se você está planejando um sistema, um aplicativo ou uma nova funcionalidade, fale com nossos especialistas antes de abrir o projeto.

Falar com um especialista