# Requisitos de software Tipos de requisitos, elicitação até validação, casos de uso em UML e protótipos. Página: https://resumos.rgo.pt/cadeiras/es/requisitos-uml/ Um requisito é uma afirmação sobre o que o sistema deve fazer ou sobre uma restrição que deve respeitar. Todo o resto do projeto (desenho, código, testes) responde a estes textos. Requisitos vagos produzem discussões infinitas; requisitos precisos produzem testes que passam ou falham. ## Tipos de requisitos O que o sistema faz: “o sistema permite iniciar sessão com email e palavra passe”. Cada requisito funcional descreve uma interação observável do utilizador com o sistema. Restrições sobre como o sistema se comporta: desempenho, segurança, usabilidade, fiabilidade. “O início de sessão deve ser rápido” não é um requisito, é um desejo. “95 por cento dos inícios de sessão concluem-se em menos de 2 segundos” é um requisito, porque se consegue testar. Regras do mundo onde o sistema vive: “as palavras passe guardam-se transformadas por uma função de dispersão com sal” ou “a conta bloqueia após 5 tentativas falhadas”. Muitas vezes o cliente nem os menciona porque os acha óbvios, e é aí que moram os mal entendidos. Quando leres um enunciado, classifica cada frase nestes três tipos antes de fazer seja o que for. Metade dos erros em exercícios de requisitos nasce de tratar uma restrição como funcionalidade ou de aceitar um “rápido” sem número. ## Da elicitação à validação Trabalhar requisitos tem quatro atividades: 1. **Elicitação.** Descobrir o que as partes interessadas precisam: entrevistas, observação do trabalho real, questionários. Pergunta sempre pelo problema antes da solução. 2. **Análise.** Resolver conflitos (dois utilizadores que pedem coisas opostas), detetar omissões e ordenar por valor e risco. 3. **Especificação.** Escrever os requisitos de forma clara, completa e testável, com identificadores para os referenciar (R1, R2, …). 4. **Validação.** Confirmar que os requisitos dizem o que o cliente quer: revisões com o cliente, protótipos, e a pergunta de ouro, “como testarias isto”. Um requisito sem teste imaginável volta para trás. ## Casos de uso em UML Um **diagrama de casos de uso** mostra quem usa o sistema e para quê. Tem **atores** (bonecos de palha: utilizador, administrador, sistema externo), **casos de uso** (elipses: ações com valor para o ator) e relações (linhas ator a caso de uso; `<>` para comportamento sempre partilhado; `<>` para comportamento opcional).[1](https://resumos.rgo.pt/cadeiras/es/requisitos-uml/#user-content-fn-uml) Para o início de sessão: ![Diagrama de casos de uso do início de sessão: o Utilizador liga-se a Iniciar sessão, que inclui sempre Validar credenciais; Recuperar palavra passe estende Iniciar sessão a tracejado; o Administrador liga-se a Desbloquear conta.](https://resumos.rgo.pt/cadeiras/es/requisitos-uml/figura-1.svg) Lê-se assim: o utilizador inicia sessão, o que inclui sempre validar credenciais; recuperar a palavra passe é uma extensão opcional desse fluxo; o administrador desbloqueia contas. Cada elipse depois precisa de uma descrição textual: pré condições, fluxo principal e fluxos alternativos (palavra passe errada, conta bloqueada). [Vídeo: Diagrama de Casos de Uso, Eduardo Engenharia de Software](https://www.youtube.com/watch?v=SixryUrg2G8) A miniatura vem do YouTube. O vídeo só carrega quando clicas. [Abrir no YouTube](https://www.youtube.com/watch?v=SixryUrg2G8) ## Protótipos de interface Antes de programar ecrãs, desenha um **protótipo**: um esboço do ecrã de início de sessão com os campos, os botões e as mensagens de erro. Pode ser em papel. O objetivo é validar requisitos com o cliente quando ainda é barato mudar: discutir “onde aparece o erro de conta bloqueada” sobre um desenho demora minutos; discutir sobre código pronto demora dias e cria resistência a mudar. O erro mais comum Descrever a solução em vez do requisito: “o sistema usa uma tabela de dispersão para as sessões” não é um requisito, é uma decisão de desenho disfarçada. O requisito é “o sistema mantém a sessão ativa durante 30 minutos de inatividade”. Guarda o “como” para a arquitetura. ## Exercício: escrever requisitos e o diagrama Escreve para o início de sessão da app: 1. **Um requisito funcional (R1).** “O sistema permite a um utilizador registado iniciar sessão com o seu email e palavra passe, mantendo a sessão ativa durante 30 minutos de inatividade.” Repara: quem, o quê e a condição de sessão numa frase. 2. **Um requisito não funcional mensurável (R2).** “95 por cento das tentativas de início de sessão recebem resposta em menos de 2 segundos, e as palavras passe nunca são guardadas em texto claro.” Tem número, percentagem e uma proibição verificável. 3. **O diagrama de casos de uso.** Desenha os atores (Utilizador, Administrador) e os casos (Iniciar sessão, Validar credenciais com `<>`, Recuperar palavra passe com `<>`, Desbloquear conta). Depois valida cada elipse com a pergunta de ouro: consegues imaginar o teste que a verifica? “Validar credenciais” testa-se com pares válidos e inválidos; “Recuperar palavra passe” testa-se pedindo o email de recuperação. Se algum caso não tiver teste imaginável, o requisito está incompleto. ## Para saber mais * [Guia de diagramas de casos de uso em português, Visual Paradigm](https://guides.visual-paradigm.com/pt/ultimate-guide-use-case-diagrams-2026/): exemplos de `include` e `extend` para rever depois do exercício. Antes de desenhares classes para estes conceitos, revê [classes, construtores e encapsulamento](https://resumos.rgo.pt/cadeiras/p/classes-objetos/): os diagramas de classes da próxima página assentam nessas ideias. A página seguinte é [Arquitetura e desenho](https://resumos.rgo.pt/cadeiras/es/requisitos-uml/arquitetura-desenho/). ## Notas de rodapé 1. Na sintaxe UML, a relação de inclusão escreve-se `<>` com seta contínua do caso base para o incluído, e a de extensão escreve-se `<>` com seta tracejada do caso de extensão para o caso base. [Voltar](https://resumos.rgo.pt/cadeiras/es/requisitos-uml/#user-content-fnref-uml)