Engenharia de requisitos

“Ontem percorri três salas e estavam todas ocupadas”, relata um estudante. A necessidade é encontrar uma sala sem perder tempo em deslocações. “Mostrar salas livres para um intervalo escolhido” já é uma propriedade de uma solução possível. A engenharia de requisitos transforma necessidades e restrições numa definição acordada do sistema.

Objetivos e requisitos

Um objetivo descreve um resultado desejado, como reduzir o tempo necessário para encontrar uma sala. Um requisito descreve uma função ou propriedade que o sistema deve apresentar para resolver o problema.

Perguntar “porquê?” liga um requisito ao objetivo. Perguntar “como pode o sistema ajudar?” permite descobrir alternativas. Se o objetivo for encontrar uma sala, um mapa em 3D não é automaticamente necessário, porque uma lista filtrada pode resolver a necessidade.

Um requisito pode nascer de utilizadores, clientes, responsáveis pelo negócio, equipa de manutenção, sistemas existentes ou regras legais. Identifica a origem e confirma os interesses que representa.

Tipos de requisitos

Um requisito funcional descreve uma função ou um comportamento do sistema. “O sistema permite cancelar uma reserva futura do próprio estudante” inclui uma operação e as suas condições. Não precisa de corresponder a um botão ou a uma interação direta: gerar um relatório noturno também é uma função.

Um requisito não funcional impõe uma qualidade ou restrição, sobre o produto ou sobre o desenvolvimento. Pode tratar de desempenho, fiabilidade, segurança, usabilidade, compatibilidade, manutenção ou portabilidade. “A aplicação tem de funcionar no sistema operativo usado nos dispositivos da escola” é uma restrição de ambiente.

Um requisito de domínio vem das regras do contexto e pode ser funcional ou não funcional. Estas categorias não são três caixas exclusivas. “Uma sala só admite uma reserva confirmada em cada instante” é uma regra do domínio com consequências funcionais.

Tornar a afirmação verificável

“O sistema deve ser rápido” não explica o que medir. Uma versão mais precisa é:

Durante o horário de utilização, com até 200 utilizadores simultâneos e a base de dados de referência, pelo menos 95% das consultas de disponibilidade recebem resposta em até dois segundos, medidos no dispositivo de teste.

Temos operação, carga, dados, medida e limite. Num ensaio acordado de 1000 consultas, pelo menos 950 têm de cumprir os dois segundos. Uma média inferior a dois segundos não basta: muitas consultas rápidas podem esconder consultas lentas. Define também como contar consultas falhadas, para não melhorar a medida excluindo erros.

Os valores são escolhas deste exemplo. Uma exigência verificável também pode ser qualitativa: uma revisão pode confirmar que uma mensagem não contém dados pessoais. Escolhe a medida a partir da necessidade, sem inventar um número só para tornar a frase quantitativa.

Um bom conjunto de requisitos deve ser claro, consistente, necessário, viável e suficientemente completo para o âmbito; se um requisito pede cancelamento e outro diz que reservas nunca mudam, precisamos de resolver a contradição. A Introdução à engenharia de requisitos, ligada nos slides docentes, acompanha esta passagem de uma necessidade para propriedades verificáveis do sistema.

Elicitação

Elicitar é descobrir requisitos, não apenas transcrever pedidos. Escolhe a técnica conforme a dúvida:

Técnica	Quando ajuda	Limite a reconhecer
Entrevista aberta	Explorar trabalho e dificuldades	Pode ficar vaga sem exemplos
Entrevista estruturada	Confirmar questões conhecidas	Pode omitir necessidades inesperadas
Observação	Descobrir rotinas que a pessoa não explica	O comportamento observado precisa de interpretação
Questionário	Comparar preferências de muitas pessoas	Perguntas fechadas limitam descobertas
Brainstorming	Gerar alternativas	Gerar ideias não decide prioridades
Protótipo ou cenário	Testar um percurso concreto	A pessoa pode confundir o protótipo com o produto final

Numa entrevista, prepara objetivos e participantes e pede um episódio concreto: como descreve o estudante a última vez que não encontrou sala? Se sugerir um mapa em 3D, distingue essa solução proposta da necessidade de garantir lugar para o grupo. Confirma a interpretação no fim: o registo da conversa pode originar a história e os critérios de aceitação.

Num brainstorming, separa a geração de ideias da avaliação. Avaliar cada proposta à medida que aparece elimina alternativas antes de as entender.

Análise, especificação e validação

A análise organiza requisitos, identifica omissões e conflitos e apoia a sua prioridade. Em MoSCoW, Must have é indispensável ao âmbito acordado; Should have é importante mas admite adiamento; Could have é desejável se houver capacidade; Won’t have fica fora desse âmbito, sem significar que nunca será feito.

Na aplicação, o responsável pelas salas quer bloqueios por manutenção; o estudante quer disponibilidade atualizada. Perante o conflito, precisamos de saber quem pode bloquear e o que acontece às reservas já existentes.

A especificação regista o acordo com o detalhe necessário. Pode usar um documento de requisitos, um backlog com histórias e critérios, modelos, um glossário e protótipos. O formato depende do contexto; uma frase curta não substitui uma regra complexa.

A validação verifica se os requisitos representam as necessidades pretendidas. Revemos com stakeholders, percorremos modelos, experimentamos protótipos e derivamos cenários de aceitação. Podemos validar requisitos antes de existir software, o que importa porque um erro de requisitos corrigido após a entrega pode custar muito mais do que o mesmo erro corrigido na especificação. Derivar os cenários de aceitação cedo também ajuda a clarificar os próprios requisitos.

Estas atividades repetem-se. Um protótipo pode revelar que o estudante precisa de ver acessibilidade da sala, levando a nova elicitação e análise.

Histórias de utilizador

Uma user story regista uma necessidade com informação suficiente para iniciar uma conversa. Um formato útil é “Como estudante, quero reservar uma sala para garantir um lugar para o trabalho de grupo”. Identifica quem, o que pretende e porquê.

Os três C são card, o registo breve; conversation, a discussão dos detalhes; e confirmation, os critérios que permitem confirmar o resultado. O critério INVEST ajuda a rever histórias com a mesma finalidade: é uma orientação para discutir e dividir trabalho, sem exigir que todas as histórias sejam totalmente independentes:

Letra	Pergunta
Independent	Conseguimos reduzir dependências entre histórias?
Negotiable	Há espaço para discutir a solução?
Valuable	Quem recebe valor e qual?
Estimable	Entendemos o suficiente para estimar?
Small	Cabe num intervalo de trabalho curto?
Testable	Conseguimos verificar o comportamento?

“Implementar a tabela de reservas” é uma tarefa técnica. Pode ser necessária, mas não exprime por si só o resultado que o estudante procura. Uma épica é uma história demasiado grande que precisa de ser decomposta.

Exemplo de divisão. A épica “gerir as minhas reservas” divide-se em reservar uma sala livre, consultar as minhas reservas e cancelar antes do início. Cada parte tem utilizador, valor e teste próprios. Se uma parte continuar grande, divide-se outra vez, por exemplo primeiro uma sala e um intervalo simples, depois salas com equipamento.

Critérios de aceitação

Os critérios descrevem condições específicas de uma história. Um cenário Given, When, Then separa contexto, ação e resultado:

Parte	Cenário de reserva
Dado	Um estudante autenticado e a sala A livre das 14h às 15h
Quando	Pede uma reserva para esse intervalo
Então	O sistema confirma uma reserva em seu nome e torna o intervalo indisponível

Acrescentamos um cenário de conflito: dada uma reserva confirmada das 14h às 15h, quando outro estudante pede das 14h30 às 15h30, o sistema recusa e não cria outra reserva. O cenário esclarece uma fronteira que “reservar sala” não explicava.

É esse uso de exemplos de comportamento para criar entendimento comum que se chama BDD. Um ficheiro escrito em Gherkin não garante colaboração nem qualidade, pois os exemplos precisam de resultados esperados corretos e significativos.

Protótipos e mudanças

Um protótipo de baixa fidelidade, como um desenho em papel, permite testar ideias de interação rapidamente. Um protótipo descartável é feito para aprender e depois abandonado. Um protótipo evolutivo cresce até ao produto e precisa de uma estrutura adequada para isso.

Na aplicação, damos ao estudante uma tarefa: encontrar uma sala para quatro pessoas e reservá-la amanhã. Observamos onde procura, que informação lhe falta e como interpreta a confirmação. Não perguntamos apenas se gosta do desenho.

Para ver como testar o percurso de um utilizador antes de implementar o ecrã, observa neste vídeo como um protótipo em papel revela dúvidas de percurso antes de qualquer código:

Abrir no YouTube

No protótipo, o estudante interpreta “pedido enviado” como reserva garantida. Esse resultado obriga a rever o requisito: o ecrã só mostra confirmação depois da resposta do servidor. Acrescentamos o estado de espera e um cenário de recusa por conflito. O desenho revelou uma regra de comunicação, não apenas uma preferência visual.

A gestão de requisitos acompanha estado e alterações. Uma ligação entre necessidade, requisito, desenho e teste dá rastreabilidade. A cadeia do exemplo permite seguir o impacto:

Origem	Acordo ou evidência
Necessidade	Garantir lugar para o grupo
Requisito	Não confirmar reservas sobrepostas
Desenho	criarSeLivre atómica no servidor
Teste	Dois pedidos concorrentes; uma confirmação, uma recusa e uma reserva nos dados

Se a duração máxima passar de duas para três horas, conseguimos localizar regras, mensagens e testes afetados. Crescimento não controlado do âmbito, requirements creep, acontece quando entramos em novas exigências sem avaliar valor, custo e consequências; os modelos UML ajudam a descobrir ambiguidades que o texto não mostrou.