Documento de requisitos de um site: o que escrever
Um documento de requisitos existe para uma coisa: garantir que você e quem constrói o site estão a falar do mesmo projeto. Não precisa de ser longo. Precisa de ser específico nos sítios certos.
Este guia mostra o que incluir, o que deixar de fora, e as secções que evitam as discussões mais frequentes.
As secções que não podem faltar#
Cada uma destas existe porque a sua ausência causa um problema previsível.
- Contexto e objetivos. O que faz a empresa e o que o site tem de conseguir, em números.
- Público. Quem visita e com que dúvida.
- Lista de páginas. Todas, agrupadas por modelo, com indicação de quais são novas.
- Funcionalidades. Formulários, pesquisa, filtros, área reservada, o que for.
- Integrações. Cada sistema externo, com quem é responsável por dar acesso.
- Conteúdo. Quem escreve, quem fotografa, quem introduz, e até quando.
- Requisitos técnicos. Idiomas, acessibilidade, desempenho, navegadores suportados.
- Fora do âmbito. A secção mais importante do documento.
- Prazos e responsáveis. Quem decide, e o que acontece se algo atrasar.
A secção «fora do âmbito» evita mais discussões do que todas as outras juntas. Escreva-a mesmo que pareça óbvia.
Como escrever requisitos que se conseguem verificar#
Um requisito vago não é verificável, e o que não é verificável discute-se no fim do projeto.
| Vago | Verificável |
|---|---|
| O site tem de ser rápido | LCP abaixo de 2,5 s nas páginas principais em 4G |
| Tem de funcionar em telemóvel | Utilizável a partir de 360 px, testado em dispositivos reais |
| Tem de ser acessível | Conforme WCAG 2.1 nível AA nos modelos principais |
| Fácil de gerir | A equipa cria e publica uma página sem programador |
| Desenho moderno | Segue o manual de marca; três propostas iniciais |
| Otimizado para SEO | Títulos editáveis, mapa do site, dados estruturados, redirecionamentos |
| Suporta vários idiomas | PT e EN no lançamento; estrutura para acrescentar mais |
O que deixar de fora#
Documentos demasiado detalhados custam tempo a escrever, tempo a ler, e retiram a quem constrói a possibilidade de propor melhor.
- Não especifique tecnologias sem razão. Diga o problema; deixe a solução para a proposta.
- Não escreva o texto de cada botão. Isso resolve-se com ecrãs à frente.
- Não desenhe o site em palavras. Referências visuais funcionam melhor do que descrições.
- Não inclua funcionalidades «para o futuro» sem as marcar claramente como fase dois.
- Não copie requisitos de outro documento sem verificar se se aplicam.
- Não peça o que não vai usar. Cada funcionalidade tem custo de construção e de manutenção.
Se o documento passa das dez páginas para um site institucional, provavelmente está a especificar a solução em vez do problema.
Usar o documento durante o projeto#
O documento não é para arquivar depois de assinado. É a referência que resolve discussões.
- Envie o mesmo documento a todos os candidatos, para obter propostas comparáveis.
- Anexe-o ao contrato, para que o âmbito acordado seja o âmbito escrito.
- Quando alguém pedir algo novo, verifique se está no documento antes de discutir prazo.
- Registe as alterações de âmbito por escrito, com estimativa, antes de o trabalho começar.
- Use a lista de páginas como lista de verificação de conteúdo durante a construção.
- Na entrega, percorra os requisitos verificáveis um a um.
Perguntas frequentes
Que extensão deve ter o documento?
Para um site institucional, cinco a dez páginas chegam. Para um projeto grande com integrações, vinte a trinta. Se estiver a passar muito disso, é provável que esteja a especificar a solução em vez do problema — e documentos assim tendem a ser ignorados por todos, incluindo por quem os escreveu.
Devo dizer qual é o orçamento?
Sim. Quem constrói pode então propor o melhor projeto possível dentro desse valor, em vez de adivinhar. Quem não indica orçamento recebe propostas que variam por um fator de dez e não consegue compará-las. Indicar um intervalo é suficiente; não é preciso revelar o limite exato.
Quem deve escrever o documento?
Alguém do lado do cliente que conheça o negócio, idealmente com apoio de quem percebe de web. Se pedir a uma agência que o escreva, é normal que descreva o projeto que essa agência gosta de fazer — o que pode até ser bom, mas deixa de servir para comparar propostas. Se o fizer assim, pague essa fase à parte.
E se os requisitos mudarem a meio?
Mudam quase sempre, e o documento não impede isso — organiza-o. Tenha um procedimento de alteração: cada pedido novo recebe uma estimativa escrita antes de começar. O problema não são as alterações, é as alterações entrarem sem que ninguém ajuste prazo nem orçamento.
documento de requisitos sitecaderno de encargos websitebriefing siteâmbito projeto webespecificação sitepedido de proposta
