O Documento de Requisitos Técnicos (TOR) é um dos aspectos mais desafiadores na relação entre o cliente e a equipe técnica. Este é um problema antigo: os clientes não sabem como redigi-lo e os desenvolvedores não podem trabalhar sem ele.
Por que isso acontece? Vamos primeiro entender o que é o TOR. Essencialmente, é um documento técnico que descreve todos os requisitos de um produto. O problema é que, na maioria das vezes, o desenvolvedor e o cliente falam idiomas diferentes, então, para um deles, o TOR do outro parece um texto em chinês. O cliente pensa em termos de negócios; ele precisa de um site que venda. Para os desenvolvedores, o conceito de “site que venda” não é útil: eles precisam de instruções claras sobre quais elementos o produto deve incluir para ser eficiente.
De forma semelhante, ao reformar um apartamento, você explica aos trabalhadores em detalhes o padrão de colocação dos azulejos no banheiro, quantas tomadas haverá na sala, a altura do teto e a marca das janelas. Se você chegar com um pedido de fazer uma reforma “estilosa”, é provável que, no final, sua ideia de estilo não coincida com a da equipe de construção.
Com o Documento de Requisitos para um site ou aplicação, tudo é ainda mais complicado: por exemplo, pode acontecer que a funcionalidade do serviço seja tecnicamente inviável da forma como o cliente a imagina, então o produto precisa ser desenvolvido de outra maneira. Ou que uma tarefa que parece pequena e simples para o cliente, na verdade, seja grande e demorada. Isso significa que o trabalho levará mais tempo do que o previsto e o projeto será atrasado.
Como redigir um Documento de Requisitos Técnicos (TOR)
Na verdade, não existe uma maneira universal de elaborar o Documento de Requisitos. Por exemplo, usamos um método interativo, onde primeiro criamos protótipos com comentários e depois escrevemos o TOR com base neles. Essa abordagem é conveniente para garantir a clareza e facilitar a comunicação com o cliente. É assim que esse processo funciona:
A estrutura do Documento de Requisitos Técnicos (TOR)
-
Descrição do projeto e da empresa: tarefas que o produto foi projetado para resolver, valores e requisitos do cliente, identidade corporativa, proposta única de venda (USP) e público-alvo; tudo o que ajuda a equipe de desenvolvimento a estar no mesmo contexto que o cliente e criar os primeiros protótipos.
-
Protótipos: os primeiros esboços visuais do serviço futuro, que permitem demonstrar visualmente sua estrutura.
-
Stack tecnológico: linguagem de programação, framework, requisitos de hospedagem, entre outros. Estrutura proposta do serviço: Por exemplo, no TOR para desenvolver um aplicativo para aprender inglês, o cliente quer ver uma sequência de seções com teoria e prática, um dicionário, uma conta pessoal com configurações e uma página inicial onde o usuário possa selecionar a lição desejada. Essa estrutura pode ser apresentada no formato de descrição ou diagrama.
-
Requisitos funcionais para cada página ou tela: uma descrição do que deve acontecer na tela. Voltando ao exemplo do aplicativo de aprendizado de inglês, na tela de prática aparecerá uma pergunta e três possíveis respostas. Ao selecionar uma, a opção correta será destacada e, em seguida, a tela mudará automaticamente para a próxima pergunta.
-
Cenários do usuário: o que acontece, por exemplo, no caso de uma assinatura paga ou gratuita. Ou como o usuário pode obter informações sobre uma regra específica de idioma por meio do aplicativo.
-
Conteúdo: imagens, textos, vídeos, arquivos de áudio para treinamento de pronúncia e muito mais.
-
Protótipos finais: Após criar o TOR e sua aprovação pelo cliente, corrigimos nossos protótipos e os discutimos com o cliente.
Quem deve estar envolvido no desenvolvimento do TOR?
Se o cliente precisa de um site informativo simples com um formulário de contato, ele pode redigir os Requisitos Técnicos (TOR) sozinho. Mas, para um produto complexo com funcionalidades avançadas, é sempre melhor compor o TOR junto com os desenvolvedores. Assim, será possível alinhar as demandas de negócios com os requisitos técnicos.
E, aliás, um projeto que o cliente considera simples pode esconder muitas armadilhas. Por isso, antes de criar os Requisitos Técnicos, é sempre melhor consultar a equipe técnica. Por exemplo, conosco