Levantamento de requisitos

“Um site para vender bilhetes” ainda não diz quem compra, como recebe confirmação ou o que acontece quando os lugares esgotam. O levantamento de requisitos fixa essas capacidades e condições antes de escolher tabelas ou código.

Atores e objetivos

Um ator é quem interage com o sistema: uma pessoa com um papel ou outro sistema. Um objetivo é o que esse ator quer conseguir. Na Loja de Bilhetes há dois atores humanos:

• Visitante: explora eventos e sessões sem conta. Quer descobrir o que há e decidir se compra.
• Comprador: está autenticado, compra bilhetes e consulta as suas compras. Quer garantir o lugar com o mínimo de passos.

Fixa os atores antes de escrever qualquer funcionalidade e liga cada funcionalidade ao objetivo de um ator: a pesquisa de eventos serve o Visitante que decide se compra, e a compra serve o Comprador que garante o lugar. Outras condições, como disponibilidade ou compatibilidade, aplicam-se ao sistema inteiro e ficam nos requisitos suplementares.

O desenho resume três interações deste exemplo. Não é um inventário completo: o registo descrito abaixo também pertence ao Visitante. Uma nova interação pode usar um ator existente; só criamos outro ator quando há um papel diferente.

Casos de uso

Um caso de uso descreve uma interação completa entre um ator e o sistema, do início ao resultado. Tem nome, ator, pré-condições e um fluxo numerado de passos que inclui o que acontece quando algo corre mal. No exemplo de comprar bilhete, a pré-condição é ter sessão iniciada. No fim de uma compra bem-sucedida, o bilhete e a reserva de capacidade ficam registados juntos.

1. O comprador escolhe uma sessão com lugares livres.
2. O sistema mostra o preço e os lugares disponíveis.
3. O comprador confirma a compra.
4. O sistema reserva os bilhetes, regista a compra e mostra a confirmação.

Exceção no passo 3: se os lugares esgotarem entre a escolha e a confirmação, o sistema avisa e devolve o comprador à lista de sessões. A exceção faz parte do caso de uso, pois uma compra sem este ramo parece completa no papel e falha na primeira sessão esgotada.

Caso de uso 2, registar conta:

1. O visitante indica nome, email e palavra-passe.
2. O sistema verifica que o email ainda não está registado.
3. O sistema cria a conta e inicia a sessão do novo comprador.

Exceção no passo 2: se o email já existir, o sistema sugere iniciar sessão em vez de criar uma conta duplicada.

Histórias de utilizador

Uma história de utilizador resume uma capacidade desejada em três partes: quem, o quê e para quê. Ajuda a ordenar o trabalho e a discutir necessidades. Não descreve por si só todo o fluxo e as exceções de um caso de uso.

• Como comprador, quero ver os lugares livres de cada sessão para escolher sem adivinhar.
• Como comprador, quero receber confirmação da compra para ter prova do que paguei.
• Como visitante, quero pesquisar eventos por data para planear a semana.

Cada história deve ter uma capacidade concreta e critérios que permitam verificar o resultado. “Como comprador, quero uma boa experiência” não identifica uma operação nem um resultado observável; precisa de ser desenvolvida antes de orientar a implementação.

Artefacto	O que acrescenta à compra
História	Papel, capacidade e benefício: comprar um bilhete para garantir lugar.
Caso de uso	Sequência da escolha à confirmação, incluindo o ramo de sessão esgotada.
Critérios de aceitação	Condições e resultados observáveis que permitem testar sucesso e falhas.

Requisitos e prioridades

Junta tudo numa tabela com identificador, descrição, ator e prioridade, porque a tabela regista o âmbito acordado. Se surgir uma necessidade nova, discute-a e atualiza os requisitos e os artefactos que dependem dela.

Id	Requisito	Ator	Prioridade
R1	Comprar bilhetes para uma sessão com lugares livres	Comprador	Alta
R2	Registar conta com email único	Visitante	Alta
R3	Pesquisar eventos por data	Visitante	Média
R4	Consultar o histórico de compras	Comprador	Média

O requisito “o sistema deve ser rápido” parece razoável, mas não diz quanto é rápido, a medir onde nem em que condições. Rejeita-o na forma atual e substitui-o por algo verificável, por exemplo “a pesquisa de eventos responde em menos de 2 segundos com 1000 eventos na base de dados”; sem uma medida e condições definidas, duas pessoas podem discordar sobre se o requisito foi cumprido.

Funcionalidade, qualidade e regra de negócio

As histórias de utilizador descrevem interações. Os requisitos suplementares registam outras condições que o sistema deve cumprir:

Tipo	Exemplo verificável
Funcional	O comprador consulta os seus bilhetes pagos.
Qualidade	95% das pesquisas respondem em menos de 2 segundos, com a carga e o volume de dados definidos no teste.
Restrição técnica	A aplicação usa o servidor PostgreSQL indicado para a entrega.
Regra de negócio	A soma dos bilhetes ativos não ultrapassa a lotação da sessão.

Uma regra pode exigir verificações em várias camadas. A interface explica «esgotado»; o servidor coordena a compra; a base de dados aplica restrições e bloqueios. Uma regra de negócio não é apenas uma mensagem no formulário.

Um ator é externo ao sistema e representa um papel, não necessariamente uma pessoa diferente; a mesma pessoa pode agir como comprador e administrador, e um serviço de pagamentos também pode ser ator. A base de dados interna da aplicação não é um ator externo só porque participa na implementação.

Critérios de aceitação e rastreabilidade

Para a história «como comprador, quero cancelar uma reserva para libertar o lugar», escreve critérios observáveis:

1. Dada uma reserva minha ainda cancelável, quando confirmo, fica cancelada e deixa de ocupar lugar.
2. Dada uma reserva de outra pessoa, a operação é recusada e não altera dados.
3. Dada uma reserva já cancelada, repetir o pedido não liberta um segundo lugar.

Os critérios incluem sucesso, autorização e repetição. Uma frase do tipo «o botão funciona» não cobre estes casos. Liga cada requisito às regras do modelo, às operações e ao teste que o demonstra. Esta rastreabilidade permite perceber o impacto de mudar uma regra.

As prioridades de entrega distinguem o obrigatório do opcional:

• prototype: funcionalidade obrigatória na entrega do protótipo.
• product: funcionalidade obrigatória no produto final, mas não no protótipo.
• innovation: proposta opcional do grupo, sem obrigatoriedade.

Uma prioridade alta de negócio não equivale a uma marca de entrega: uma história pode ser importante e mesmo assim ficar marcada para o produto em vez do protótipo. Não inventes obrigações a partir de uma ideia complementar.

Processo de desenvolvimento

O processo estruturado organiza fases com resultados definidos: requisitos, especificação da base de dados, arquitetura e produto. Um processo ágil usa iterações e feedback frequente; prototipagem serve para experimentar e reduzir incerteza. LBAW usa fases estruturadas por razões pedagógicas e de calendário. Isso não torna requisitos imutáveis, mas uma alteração tem de ser propagada aos artefactos e à implementação.