Como escrever os requisitos de um sistema sem ser técnico?

Muitos empresários adiam o projeto de um sistema porque acham que precisam de um documento técnico para começar. Não precisam. Quem conhece o processo é quem está na operação, e essa pessoa consegue descrever o que o sistema deve fazer na própria linguagem. A tradução para termos técnicos é trabalho do fornecedor.

O que faz falta, normalmente, é um jeito organizado de colocar esse conhecimento no papel. Este artigo apresenta um método simples, com modelos e exemplos, para escrever requisitos que qualquer fornecedor consiga entender, orçar e construir.

Por que os requisitos fazem tanta diferença?

Requisitos mal escritos estão entre as principais causas de projetos que não atingem os objetivos. Em estudo do PMI sobre o tema, 47% dos projetos que não cumpriram suas metas tiveram como causa principal a gestão inadequada de requisitos (PMI, 2014).

O custo de corrigir também cresce com o tempo. Barry Boehm e Victor Basili registraram que encontrar e corrigir um problema depois da entrega costuma custar muito mais do que na fase de requisitos: até cem vezes em sistemas grandes e cerca de cinco vezes em sistemas pequenos e não críticos (Boehm e Basili, 2001). Uma regra de negócio esquecida no papel custa uma conversa; descoberta depois do sistema pronto, custa retrabalho.

O excesso também atrapalha. Em análise da Pendo sobre 615 produtos de software, 80% das funcionalidades eram raramente ou nunca usadas (Pendo, 2019). Bons requisitos ajudam a construir menos coisas, e as certas.

O que é um requisito, em linguagem simples?

Um requisito é uma descrição de algo que o sistema precisa fazer, ou de uma condição que ele precisa respeitar. Existem dois tipos principais:

• Requisitos funcionais: o que o sistema faz. Exemplo: "o vendedor consegue ver o estoque disponível ao montar o pedido".
• Requisitos de qualidade: como o sistema precisa se comportar. Exemplo: "o sistema precisa funcionar no celular, porque os vendedores estão na rua".

Você não precisa saber o nome técnico de nenhum dos dois. Basta descrever o que as pessoas precisam conseguir fazer e em que condições.

Como escrever um requisito em uma frase?

O formato mais útil para quem não é técnico é a chamada história de usuário. Ela tem três partes e cabe em uma frase:

A parte do "para" é a mais importante e a mais esquecida. Ela explica o objetivo, e isso permite que o fornecedor proponha uma solução melhor do que a pedida. Talvez a aprovação nem precise acontecer pelo celular, se a regra de desconto for automatizada.

Exemplos de boas histórias

• Como vendedor, quero consultar o estoque disponível ao montar o pedido, para não prometer um item que não tenho.
• Como analista financeiro, quero receber os pedidos faturados automaticamente, para não precisar digitar os valores no sistema de cobrança.
• Como cliente, quero acompanhar o status do meu pedido, para não precisar ligar perguntando.
• Como diretor, quero ver as vendas do mês por região, para decidir onde reforçar a equipe.

Exemplos de histórias que precisam melhorar

• "O sistema deve ser fácil de usar." Fácil para quem, fazendo o quê? Prefira descrever a tarefa.
• "Quero um relatório completo." Completo com quais informações, e para tomar qual decisão?
• "Integrar com o ERP." Quais dados, em que direção, e em que momento?

Como descrever regras e exceções?

Cada história costuma ter regras por trás. Escreva-as logo abaixo, em tópicos, com exemplos concretos. Regras com números e exemplos evitam interpretações diferentes.

• Descontos até 10% são aprovados automaticamente.
• Descontos entre 10% e 20% precisam de aprovação do gerente comercial.
• Descontos acima de 20% precisam de aprovação da diretoria.
• Clientes com título vencido há mais de 30 dias não podem receber desconto.

Depois, liste as exceções: o que acontece quando o caso foge do normal? Pedido parcial, cliente sem cadastro, item sem preço, aprovador de férias. Não precisa resolver todas agora, mas precisa registrar que existem.

Como saber se um requisito foi atendido?

Para cada história, escreva dois ou três critérios de aceite: situações que, se funcionarem, mostram que a história está pronta. Eles servem para o fornecedor testar e para você validar a entrega.

Escrever os critérios costuma revelar detalhes que ninguém tinha pensado, como "o vendedor precisa saber o motivo da recusa". É um dos exercícios mais úteis de todo o processo.

Que outras informações o fornecedor precisa?

Além das histórias, algumas informações ajudam muito o fornecedor a estimar e a propor a solução certa.

• Quem usa: perfis, quantidade aproximada de pessoas e onde elas trabalham (escritório, rua, armazém).
• Volume: quantos pedidos, clientes ou documentos por dia ou por mês.
• Dispositivos: computador, celular, tablet, leitor de código de barras.
• Sistemas existentes: nomes dos sistemas com que o novo precisa conversar.
• Dados atuais: o que precisa ser migrado e onde está hoje.
• Prazos e restrições: datas importantes, faixa de orçamento, exigências legais.

Como mostrar o que você imagina sem desenhar telas?

Exemplos reais valem mais do que descrições. Anexe ao documento:

• A planilha usada hoje, com dados fictícios ou anonimizados.
• Prints de sistemas que você já usa e de que gosta (ou não gosta).
• Fotos de formulários em papel, quadros e anotações da equipe.
• Modelos de documentos que o sistema vai gerar: pedido, proposta, relatório.
• Um rabisco à mão de uma tela, se ajudar a explicar uma ideia.

Como criar um glossário da empresa?

Toda empresa tem palavras próprias. "Pedido", "ordem", "romaneio" e "carga" podem significar coisas diferentes em cada operação. Um glossário de uma página, com os termos e o que eles significam para você, evita muitos mal-entendidos com o fornecedor.

Como priorizar os requisitos?

Depois de escrever as histórias, classifique cada uma em uma de quatro categorias. O método é conhecido como MoSCoW, pelas iniciais em inglês, mas pode ser usado em português sem perda:

• Precisa ter: sem isso, o sistema não resolve o problema.
• Deveria ter: importante, mas existe uma solução provisória.
• Poderia ter: desejável, se houver tempo e orçamento.
• Não terá agora: registrado, mas fora da primeira versão.

Uma boa primeira versão costuma ter só os itens do primeiro grupo e alguns do segundo. Isso reduz custo e prazo e permite aprender com o uso antes de investir no resto.

Quais erros evitar ao escrever requisitos?

• Descrever a solução em vez do problema, como "quero um botão azul" em vez de "quero aprovar rápido".
• Escrever sem ouvir quem executa o processo.
• Usar termos vagos: fácil, rápido, completo, moderno.
• Esquecer as exceções e os casos de erro.
• Tratar tudo como prioridade máxima.
• Considerar o documento definitivo: requisitos evoluem com o projeto.

Como fica um requisito completo, do começo ao fim?

Juntando as partes, um requisito bem escrito para um sistema de pedidos fica assim:

• História: como vendedor externo, quero montar um pedido pelo celular durante a visita ao cliente, para não precisar digitar tudo de novo quando voltar ao escritório.
• Regra 1: o preço vem da tabela do cliente cadastrada no sistema; o vendedor não altera preço, só aplica desconto.
• Regra 2: descontos seguem a política de aprovação (até 10% automático, acima disso vai para o gerente).
• Regra 3: itens sem estoque podem entrar no pedido, mas aparecem destacados com o prazo previsto de reposição.
• Exceção 1: se o celular estiver sem internet, o pedido fica salvo no aparelho e é enviado quando a conexão voltar.
• Exceção 2: cliente com título vencido só pode fazer pedido à vista; o sistema avisa o vendedor na hora.
• Critério de aceite 1: um pedido com cinco itens é montado em menos de três minutos por um vendedor treinado.
• Critério de aceite 2: o pedido aparece para o faturamento assim que é enviado, sem nenhuma digitação.
• Prioridade: precisa ter.

Repare que nenhuma linha usa termo técnico. Mesmo assim, o fornecedor tem tudo o que precisa para estimar: quem usa, em que dispositivo, quais regras, quais exceções e como saber que está pronto. Requisitos assim reduzem perguntas, retrabalho e diferenças entre as propostas.

Como validar os requisitos com a equipe?

Antes de enviar o documento ao fornecedor, faça uma rodada de validação com quem executa o processo. Ela costuma revelar regras esquecidas e expectativas diferentes entre as áreas.

• Leia as histórias em voz alta com duas ou três pessoas da operação e pergunte: "é assim mesmo que acontece?".
• Percorra um caso real do mês passado usando as histórias, do início ao fim, e veja se algo ficou de fora.
• Peça a cada área que confirme as regras que a afetam, como descontos para o comercial e prazos para o financeiro.
• Registre divergências entre áreas como decisões pendentes, para a gestão resolver antes da construção.

Como lidar com mudanças durante o projeto?

Requisitos mudam, e isso é normal. A empresa aprende ao ver o sistema funcionando, o mercado muda e surgem ideias melhores. O problema não é a mudança, e sim a mudança sem controle. Algumas regras ajudam:

• Toda mudança vira uma nova história, com regras e critérios de aceite, como as demais.
• Cada nova história recebe uma prioridade e entra na fila, em vez de interromper o que está em andamento.
• Antes de aprovar, pergunte ao fornecedor o impacto em prazo e custo.
• Se algo novo entra, avalie o que pode sair ou esperar.

Projetos com entregas curtas lidam melhor com mudanças, porque as prioridades são revisadas a cada ciclo. Em contratos de escopo fechado, mudanças viram aditivos, e vale combinar desde o início como eles serão tratados.

Perguntas frequentes

Quantas histórias de usuário um sistema precisa ter?

Não existe número certo. Um sistema interno de porte médio costuma começar com 20 a 60 histórias. Mais importante do que a quantidade é cobrir a jornada principal de cada perfil de usuário com regras e critérios de aceite claros.

Preciso usar alguma ferramenta específica?

Não. Um documento de texto ou uma planilha com colunas para história, regras, critérios de aceite e prioridade é suficiente. O fornecedor pode depois levar o conteúdo para a ferramenta de gestão que usar.

E se eu não souber responder alguma pergunta do fornecedor?

Marque como dúvida e siga. Um bom fornecedor ajuda a responder durante o levantamento. Pior do que deixar uma dúvida em aberto é inventar uma resposta que depois se mostra errada.

Quem da empresa deve escrever os requisitos?

Uma pessoa responsável por consolidar, com participação de quem executa cada etapa do processo. O ideal é que essa pessoa conheça bem a operação e tenha autonomia para tomar pequenas decisões durante o projeto.

Próximo passo

Escolha o processo que o sistema vai apoiar e escreva dez histórias de usuário no formato "como, quero, para". Para cada uma, acrescente as regras principais e dois critérios de aceite. Esse material, com a planilha atual anexada, já é suficiente para uma primeira conversa produtiva com qualquer fornecedor.