Como escrever o documento de requisitos de um aplicativo para celular

O que é o documento de requisitos de um app e em que difere do briefing

O documento de requisitos é o documento onde fica escrito o que o aplicativo precisa saber fazer e como vai perceber que está pronto. Todos o leem ao mesmo tempo: você, o designer e o desenvolvedor. Se os três entenderem o texto da mesma maneira, desaparece a maior fonte de discussões nos projetos: «eu pensava que isso estava incluído».

Não confunda três documentos. O briefing responde a «por quê» e «para quem»: objetivo, público, mercado, orçamento. O documento de requisitos responde a «o que, em concreto, precisa funcionar»: telas, ações, regras, dados. O orçamento responde a «quanto e quando» e surge já a partir do documento de requisitos. Para um site, explicamos o briefing no artigo «Briefing e documento de requisitos de um site»; num aplicativo há mais requisitos: celular, lojas de aplicativos, notificações, funcionamento sem internet.

A boa notícia: não precisa escrever 80 páginas como um engenheiro. Bastam 3–6 páginas em texto simples, seguindo o modelo abaixo. O fornecedor completa os detalhes técnicos, mas não pode adivinhar por conta própria o que o seu negócio precisa.

Há ainda outra vantagem: o documento permite obter propostas comparáveis. Quando cinco estúdios orçam o mesmo texto, os preços podem se colocar lado a lado com justiça. Quando cada um orça a sua versão da ideia, não há nada para comparar.

Modelo de documento de requisitos de aplicativo: 10 seções

Copie esta lista para um documento e preencha cada ponto, nem que seja com uma ou duas frases. Uma seção vazia é uma pergunta que vai precisar resolver na mesma, só que mais tarde e mais cara.

1. Objetivo e resultado mensurável. Uma frase: «os clientes marcam sozinhos e 30 % dos agendamentos chegam pelo app». Sem número também serve, mas então escreva pelo que vai reconhecer o sucesso.
2. Usuários e perfis. Quem usa: cliente, profissional, administrador, entregador. Cada perfil tem as suas telas e permissões.
3. Plataformas. iOS, Android ou ambas; se é preciso tablet; se basta um site que se instala no celular como app (PWA) ou se são necessárias as lojas de aplicativos. Se tem dúvidas, compare primeiro o aplicativo, o site e a PWA em custo e em tarefas.
4. Mapa de telas. A lista de todas as telas e as setas entre elas: entrada, tela principal, catálogo, ficha, carrinho, perfil. Pode desenhar à mão e fotografar.
5. Cenários. Passo a passo, o que a pessoa faz: «abriu, escolheu o serviço, escolheu a hora, pagou, recebeu o lembrete».
6. Funcionalidades com prioridades. Três colunas: «sem isto não se lança», «era bom ter», «mais tarde». É a seção mais importante para o orçamento.
7. Dados e links. Onde ficam guardados os usuários e os pedidos, com que sistemas nos conectamos: pagamento, CRM, contabilidade, mapas, e-mail, aplicativos de mensagens.
8. Requisitos não funcionais. Rapidez, funcionamento sem internet, idiomas, segurança, acessibilidade (mais abaixo).
9. Publicação e contas. Em nome de quem se abrem as contas de desenvolvedor, quem escreve a descrição para as lojas, que países.
10. Aceitação e fases. Como verificamos o resultado, quantas rodadas de correções, como se divide o pagamento por fases.

A cada ponto vale a pena juntar exemplos de aplicativos de que gosta e uma linha sobre o que, em concreto, lhe agrada. «Quero como o Uber» não diz nada; «quero que o mapa com pontos fique como o do Uber e que o cadastro seja por número de celular» diz tudo.

Requisitos de um aplicativo para celular: funcionais e não funcionais

Num documento de requisitos (em inglês, app requirements document) há normalmente dois tipos de registros. Os funcionais descrevem o que o aplicativo faz: «o usuário pode alterar o agendamento até 2 horas antes». Os não funcionais descrevem com que qualidade o faz: depressa, em segurança, de forma clara, nos idiomas certos. São estes últimos que mais vezes se esquecem, e depois se discute.

Exemplo para um app de agendamentos num salão

Perfil «cliente». Cadastro por número de celular com código por SMS. Catálogo de serviços com preço e duração. Escolha do profissional e de uma hora livre. Pré-pagamento com cartão. Lembrete com um dia e com 2 horas de antecedência. Cancelamento gratuito até 24 horas antes. Perfil «administrador»: agenda dos profissionais, lista de agendamentos, reembolsos, envio de promoções.

Esta é a parte funcional. Agora, a parte não funcional:

• Rapidez. A tela principal abre sem atraso perceptível num celular médio com cinco anos.
• Conexão. O que o cliente vê sem internet: o último agendamento ou uma mensagem de erro? Um modo offline completo custa dinheiro à parte.
• Idiomas e moedas. Quantos idiomas na interface, em que moeda os preços, como aparecem as datas.
• Segurança e dados. Que dados pessoais se guardam, quem os vê, como a pessoa elimina a sua conta. Se trabalha no seu país, confirme os requisitos de proteção de dados pessoais com um advogado: na UE se aplica o GDPR.
• Acessibilidade. Fonte grande, contraste, descrições para leitores de tela. É conforto e é também exigência de alguns mercados.
• Dispositivos. A partir de que versão de iOS e Android damos suporte e em que telas testamos.

Não se esqueça da parte «invisível»: a maioria dos aplicativos tem um painel de administração onde a equipe gerencia conteúdos e pedidos. No documento de requisitos se escreve numa seção própria; senão, acontece que o app está pronto e não há como gerenciá-lo.

O que registrar sobre App Store e Google Play no documento de requisitos

A publicação é uma fase à parte, com regras próprias, e não depende só de nós. Por isso convém registrar alguns pontos logo no início.

• Contas de desenvolvedor. A Apple cobra US$ 99 por ano, o Google Play US$ 25 uma só vez. Publicamos o aplicativo na sua conta, por isso registre quem a abre e quem guarda os acessos.
• Versão pronta para revisão. Segundo as regras da Apple (seção 2.1, «integridade do aplicativo»), para revisão se envia uma versão acabada: sem espaços reservados nem páginas provisórias, com links a funcionar e, se existir login, com um acesso de demonstração para o revisor; a parte de servidor precisa estar funcionando nesse momento. No documento de requisitos isto passa a ser um ponto de aceitação: «conta de teste e descrição para o revisor prontas».
• Testes para o Google Play. Para contas pessoais novas de desenvolvedor, o Google exige um teste fechado: pelo menos 12 testadores participando por 14 dias seguidos, e só depois abre a publicação para todos. Reserve estas duas semanas no prazo ou abra uma conta de empresa; consulte as condições atuais na ajuda do Google Play.
• Textos e imagens para as lojas. Descrição, capturas de tela, política de privacidade, classificação etária. Quem os escreve e em que idiomas.
• Pagamentos. Se o aplicativo vende bens digitais ou assinaturas, as lojas têm regras e comissões próprias. Para bens físicos e serviços as regras são outras. Registre o que vende e o fornecedor indica o esquema adequado.

Os prazos de revisão das lojas não dependem de nós, por isso nunca prometemos uma data exata de aparecimento na loja. Mais sobre os passos da publicação no artigo como criar um app para celular: da ideia ao App Store.

Cinco erros no documento de requisitos que aumentam prazos e preço

1. Sem prioridades. Quando tudo é «muito necessário», o orçamento inclui tudo e a primeira versão se lança daqui a meio ano em vez de dois meses. Divida as funcionalidades em «obrigatório», «era bom ter» e «mais tarde».
2. Sem critérios de aceitação. «Bonito e prático» não se verifica. «O agendamento se cria em no máximo quatro toques» se verifica.
3. Painel de administração e perfis esquecidos. O aplicativo para o cliente é metade do produto. A outra metade é a ferramenta da sua equipe.
4. Integrações vagas. «Conectar ao CRM» são volumes de trabalho diferentes para sistemas diferentes. Indique o sistema e descreva que dados vão para onde.
5. Sem responsável. Se as decisões do seu lado são tomadas por três pessoas, o projeto trava nas aprovações. Nomeie uma pessoa que diz «sim» ou «não».

Outra armadilha frequente é escrever o documento para o «produto ideal» já acabado. É melhor descrever a primeira versão, que testa a ideia com pessoas reais, e numa lista à parte tudo o que acrescentará se funcionar. Como é essa primeira versão e quanto custa explica o artigo MVP: o que é e quanto custa lançá-lo.

Verifique se o documento de requisitos está pronto para orçamento

Responda à lista de verificação abaixo. Mostra se pode enviar o documento aos fornecedores ou se convém fechar primeiro as lacunas. Se responder «não» à maioria dos pontos, não tem mal: parte das perguntas pode se resolver com o fornecedor, e estamos disponíveis para isso. E se ainda não tem certeza da própria ideia, comece pelo quiz de preparação.

Quem deve escrever o documento de requisitos: o próprio, o fornecedor ou em conjunto

Há três cenários que funcionam, e a escolha depende da clareza da sua ideia.

• Escreve o próprio, pelo modelo. Serve quando a ideia é simples e conhece o seu público. Recebe várias estimativas e as compara.
• O fornecedor escreve a partir do seu briefing. É cômodo, mas lembre-se: quanto mais detalhado o documento, mais exato o orçamento. Um documento gratuito muitas vezes acaba por ser um «documento sob medida do nosso preço», por isso pergunte a quem pertence se escolher outra equipe.
• Trabalho prévio pago. Para produtos complexos (perfis, pagamentos, vários sistemas) fazemos isso como fase separada: a sessão de arquitetura por US$ 3.890. No final ficam o mapa do produto, o orçamento e o plano da primeira versão. O valor se abate ao projeto, e o mapa fica com você em qualquer caso, mesmo que depois escolha outra equipe.

Se precisa de telas e não só de texto, junte design e protótipo, a partir de US$ 2.190: um protótipo clicável no celular explica a ideia melhor do que dez páginas de descrição. Nos pacotes prontos de aplicativo o design já está incluído.

Como escolher a quem confiar o documento e o próprio projeto explica o artigo como escolher uma agência web sem se enganar: as mesmas perguntas servem para quem desenvolve aplicativos. E quanto custa o aplicativo em si pode ver em quanto custa criar um app.

O que escolher na sua situação

• A ideia é simples: um cenário, um perfil. Preencha o modelo sozinho, envie a duas ou três equipes e compare as respostas. Um aplicativo para iOS e Android custa a partir de US$ 11.990; o valor exato se calcula no orçamento depois do documento de requisitos.
• Há vários perfis, pagamento, integrações. Não escreva tudo às cegas: comece pela sessão de arquitetura e receba o documento sob a forma de mapa do produto e orçamento.
• Não tem certeza de que precisa mesmo de um app. Talvez baste um site no celular ou um aplicativo no Telegram. Compare as opções e o custo antes de escrever o documento.
• Já tem um documento de outro estúdio. Mostre-o a nós e a outros fornecedores: um documento, várias propostas. Como comparar as respostas com justiça explica o artigo como comparar orçamentos e propostas de fornecedores.
• Precisa começar o mais rápido possível. Descreva só as funcionalidades obrigatórias e deixe o resto para a segunda versão.

Não sabe por onde começar? Faça o quiz «Está pronto para desenvolver o seu produto?»: 17 perguntas, uma análise personalizada e um desconto no desenvolvimento, com um código promocional que lhe chega por e-mail (exceto no «Site em 24 horas»). Mostra as lacunas da ideia e ajuda a escolher o formato de início na sua cidade ou à distância.