Requisitos para uma app iPhone e Android: como escrever

Conseguiria explicar quando uma funcionalidade da sua futura app está realmente pronta? Se a resposta for «quando funcionar bem», ainda falta transformar a ideia numa condição que alguém possa testar.

Para preparar o desenvolvimento de uma app para iPhone e Android, recomendamos começar pelas tarefas do utilizador, pelas regras do negócio e pela forma de verificar cada resultado. Os desenhos dos ecrãs podem vir depois. Primeiro, esclareça o que a aplicação deve permitir fazer.

Não precisa de escrever código nem de escolher uma tecnologia. Precisa de conseguir dizer: «É isto que esperamos que aconteça, nestas condições, e é assim que vamos confirmar.»

Comece por uma tarefa, não por uma lista de ecrãs

Imagine uma empresa portuguesa de aluguer de equipamentos que pretende criar uma app para os seus clientes. É um exemplo hipotético que vamos usar para tornar o documento concreto.

Uma primeira descrição poderia ser: «A app terá entrada na conta, catálogo, reservas e área de cliente.» O problema é que essa lista não explica como o aluguer funciona.

Experimente antes escrever:

> Um cliente com contrato ativo deve conseguir pedir o prolongamento de um aluguer e consultar a decisão da empresa, sem telefonar para o balcão.

Agora há uma tarefa identificável. Ainda falta decidir quem pode pedir, quem aprova e o que acontece ao prazo original, mas já sabemos que conversa ter.

A orientação de qualidade da Google começa precisamente pelo valor para o utilizador: a aplicação deve responder às necessidades do público e aos seus principais casos de utilização. Acrescentar funcionalidades sem essa relação não resolve o problema de base. (developer.android.com)

Para abrir o seu documento, responda a estas perguntas:

Quem vai usar a app e em que situação?
Que tarefa deve conseguir concluir?
Como é feita essa tarefa hoje?
Que resultado justificará o projeto para a empresa?

Evite objetivos como «modernizar a marca». Prefira uma mudança observável, como permitir que o cliente consulte a decisão sobre um prolongamento sem contactar a equipa.

Escreva as regras que hoje estão na cabeça da equipa

Antes de desenhar o botão «Prolongar aluguer», reúna quem recebe pedidos e quem decide sobre eles. Peça-lhes que expliquem as exceções.

No exemplo, uma regra proposta poderia ser: o pedido só pode ser apresentado enquanto o aluguer estiver ativo. Outra: apresentar o pedido não altera a data de devolução; essa data só muda depois da aprovação.

São decisões do negócio. Não devem ficar entregues à interpretação de quem desenha ou programa a app.

Registe também o que acontece quando há desacordo entre pessoas ou sistemas. Se o balcão já prometeu o equipamento a outro cliente, quem tem autoridade para aprovar o prolongamento? Se duas pessoas da mesma empresa fizerem pedidos, qual deles fica válido?

Use frases diretas:

Pode: o responsável da conta consultar os alugueres da sua empresa.
Não pode: um contacto de outra empresa consultar esses alugueres.
Depende de aprovação: alterar a data de devolução.
Continua inalterado até à decisão: o prazo do contrato em vigor.

Assinale as dúvidas como «por decidir» e atribua um responsável. É preferível levar uma pergunta explícita à reunião com a agência do que esconder uma decisão numa frase vaga.

Uma ficha de requisito que pode copiar

Propomos uma ficha por tarefa relevante. Não é necessário criar uma ficha para cada botão: o objetivo é descrever um comportamento completo.

| Campo | Exemplo de preenchimento |

|---|---|

| Identificador | REQ-PROLONGAMENTO |

| Utilizador | Responsável de uma conta empresarial com aluguer ativo |

| Objetivo | Pedir uma nova data de devolução |

| Condições de entrada | Conta autenticada e aluguer associado à empresa |

| Informação necessária | Aluguer, nova data pretendida e comentário opcional |

| Regra de negócio | O pedido não altera o contrato antes da aprovação |

| Resultado esperado | Pedido registado como pendente e visível ao cliente |

| Exceção | Se já existir um pedido pendente, mostrar esse pedido em vez de criar outro |

| Dependência | Sistema de gestão que confirma o estado do aluguer |

| Teste de aceitação | Cliente apresenta o pedido e consulta o estado; a data contratual mantém-se |

| Fora desta entrega | Aprovação automática e negociação de condições pela app |

| Responsável pela validação | Pessoa designada pela direção de operações |

Adapte os campos à sua empresa. Para uma tarefa sem integração externa, a dependência pode ser apenas uma regra que falta aprovar.

A ficha deve permitir uma conversa concreta. Se a agência perguntar o que significa «aluguer ativo», consulte a definição usada pela operação e registe-a. Não responda apenas «o normal».

Acrescente uma data e uma versão ao documento. Quando houver uma alteração, mantenha visível o que mudou e quem a aprovou. Recomendamos que esta seja a referência comum durante o projeto, em vez de distribuir decisões por mensagens e reuniões sem registo.

Defina a aceitação antes de aprovar os desenhos

Um teste de aceitação é uma situação que permite decidir se o requisito foi cumprido. Pode escrevê-lo sem linguagem técnica, usando três partes: dado um contexto, quando alguém faz uma ação, então deve acontecer um resultado.

Para o prolongamento, proponha estes testes:

1. Pedido válido: dado um aluguer ativo, quando o cliente escolhe uma data permitida e confirma, então o pedido aparece como pendente.

2. Pedido repetido: dado um pedido pendente, quando o cliente tenta apresentar outro para o mesmo aluguer, então é encaminhado para o pedido existente.

3. Acesso indevido: dado um utilizador de outra empresa, quando tenta consultar esse aluguer, então não recebe os respetivos dados.

4. Decisão recusada: dado um pedido recusado, quando o cliente abre o detalhe, então vê a decisão e a data de devolução que continua válida.

Estes são critérios propostos para o exemplo, não regras universais do setor. A sua equipa deve aprová-los ou substituí-los.

Inclua interrupções nos testes. As orientações oficiais de qualidade Android contemplam a preservação do estado da aplicação e a prevenção da perda acidental de dados ao mudar de app ou navegar para trás. (developer.android.com)

Traduza isso para uma pergunta operacional: se o cliente sair para consultar uma mensagem e regressar, o que deve encontrar preenchido? Escreva a resposta no requisito correspondente.

Trate as permissões e as contas como comportamentos

«A app usa a câmara» ainda não é um requisito suficiente. Para quê? Em que momento? O que acontece se o utilizador não autorizar?

A documentação Android recomenda pedir permissões no contexto da funcionalidade e degradar o comportamento de forma controlada quando são recusadas, em vez de bloquear indiscriminadamente a aplicação. (developer.android.com)

Se a empresa do exemplo permitir comunicar danos com uma fotografia, proponha um requisito separado: recusar o acesso à câmara impede a captura da imagem, mas não impede consultar os alugueres. Cabe ao negócio decidir se a comunicação pode ser enviada sem fotografia ou se deve oferecer outra via.

Faça o mesmo exercício para a conta. Quem a cria? Quem pode associar outro trabalhador? O que acontece quando alguém deixa a empresa?

Há também condições das plataformas a considerar. A Apple exige que apps que permitem criar uma conta possibilitem iniciar a sua eliminação dentro da aplicação; desativar temporariamente a conta não é equivalente. (developer.apple.com)

Se essa condição se aplicar, inclua o percurso nos requisitos e peça validação específica sobre os dados que devem ser eliminados ou conservados. Não deixe essa decisão escondida na expressão «gestão de utilizadores».

Separe a app do trabalho que a empresa tem de fazer

No nosso exemplo, alguém terá de aprovar ou recusar os prolongamentos. Indique onde essa pessoa trabalha: num sistema já existente ou numa nova área de gestão.

Se ainda não souber, registe a questão antes de fechar o âmbito. Evite presumir que a equipa vai receber e tratar os pedidos por um meio que ninguém escolheu.

Para cada integração, proponha uma pequena ficha complementar:

Que sistema fornece a informação?
Quem é o contacto responsável por esse sistema?
Existe documentação e um ambiente onde testar?
Que informação pode a app consultar ou alterar?
Qual é o comportamento esperado quando o sistema não responde?

Não invente respostas técnicas. Se o fornecedor do sistema ainda não confirmou uma possibilidade, marque-a como dependência por validar.

Peça também que o projeto preveja dados e acessos de demonstração. Nas suas regras de revisão, a Apple solicita acesso completo à app, incluindo uma conta de demonstração ativa quando existam funcionalidades dependentes de autenticação, e serviços de retaguarda disponíveis durante a revisão. (developer.apple.com)

O requisito prático é simples: designar quem prepara esse acesso, com dados adequados a testes, sem recorrer por conveniência à conta real de um cliente.

Delimite a primeira entrega sem deixar tarefas a meio

Para decidir o que entra, use a tarefa inicial como filtro. O cliente precisa de apresentar um pedido e conhecer a decisão. Se retirar a consulta da decisão, considere se o percurso continua a resolver o problema definido.

Já um histórico com filtros avançados pode ficar para depois, se a equipa confirmar que a consulta básica chega para a primeira entrega. A escolha deve ser justificada pelo uso, não pela facilidade de desenhar mais um ecrã.

Sugerimos classificar cada requisito como:

Necessário para concluir a tarefa: faz parte da primeira entrega.
Melhoria posterior: tem utilidade, mas pode esperar.
Por validar: depende de uma decisão ou de uma confirmação externa.
Excluído: não faz parte do pedido atual.

Não use «por validar» como autorização implícita para desenvolver. Atribua-lhe uma decisão e um responsável antes de o transformar num compromisso.

Leve o documento à agência para o testar

O seu objetivo não é entregar uma especificação intocável. É levar uma base que possa ser questionada com utilidade.

Numa reunião de preparação do desenvolvimento mobile, peça à agência que percorra uma ficha consigo. Que regra admite duas interpretações? Que exceção falta? Que dependência precisa de uma prova técnica? Como será demonstrado o resultado em iPhone e Android?

Antes de dar o documento como pronto, confirme:

Cada tarefa tem um utilizador e um resultado identificados.
As regras e exceções têm responsáveis pela aprovação.
Há testes que permitem aceitar ou rejeitar a entrega.
As dependências não confirmadas estão visíveis.
O que fica de fora está escrito.
Está definido quem valida o resultado pela empresa.

Comece pela tarefa que mais justifica a app para o seu negócio e preencha uma ficha completa. Leve-a a quem executa hoje esse trabalho. Só depois alargue o documento.

Para discutir a criação da sua app para iPhone e Android com a VÓRTICA, essa ficha é um ponto de partida concreto: permite centrar a conversa no comportamento que precisa de construir e nas decisões que ainda faltam tomar.