Ficha 01 · Ciclo de vida e metodologias

a) Funcional — uma funcionalidade. b) Não-funcional — desempenho. c) Não-funcional — escalabilidade. d) Funcional — uma funcionalidade. e) Não-funcional — segurança/conformidade. f) Funcional — uma funcionalidade.

Regra: o que o sistema faz = funcional; como/qualidade = não-funcional.

1. Como aluno, quero pesquisar livros por título ou autor para encontrar rapidamente o que preciso.

2. Como aluno, quero ver os livros que tenho requisitados e a data de devolução para não pagar multas por atraso.

3. Como bibliotecário, quero registar a devolução de um livro para manter o inventário actualizado.

(Outras válidas: bibliotecário adicionar novos livros; aluno reservar livro indisponível; bibliotecário ver alunos com livros em atraso.)

1. Dado um aluno com credenciais válidas, quando submete o formulário de login, então é redirecionado para o seu painel.

2. Dado um aluno com senha errada, quando submete o login, então vê uma mensagem de erro genérica e permanece na página de login.

3. Dado um aluno não autenticado, quando tenta aceder a /painel, então é redirecionado para o login.

(Bónus: após 5 tentativas falhadas, a conta é temporariamente bloqueada.)

a) Must — é o núcleo do produto. b) Must — cada utilizador tem as suas tarefas. c) Could — bom ter, não essencial. d) Must — funcionalidade base de uma to-do app. e) Won't (por agora) — complexo, fora do MVP. f) Should ou Could — melhora UX mas não é crítico.

O MVP = todos os Must. Entregar isso primeiro, funcional, antes de avançar.

Problemas: - Estimativa global sem decompor em tarefas — pouco fiável. - Não considera imprevistos (bugs, coisas que não se sabe fazer ainda). - Programadores subestimam sistematicamente. - Não distingue MVP de funcionalidades extra.

Melhorar: - Quebrar em tarefas pequenas (< 1 dia cada) e estimar cada uma. - Somar e adicionar margem (~30%). - Definir MVP e estimar só esse primeiro. - Usar marcos intermédios para validar o ritmo. - Rever a estimativa à medida que se aprende mais.

a) Cascata: - Vantagem: simples de entender, documentação forte, bom quando requisitos são fixos. - Desvantagem: mudança é cara; problemas só aparecem no fim; nada utilizável até ao final.

b) Ágil domina porque os requisitos de software mudam quase sempre durante o projecto. Iterações curtas permitem: feedback cedo, detectar problemas depressa, adaptar a mudanças, e entregar valor incremental em vez de esperar pelo fim. Reduz risco.

Scrum completo (Product Owner, Scrum Master, dailies, várias cerimónias) não faz sentido para 1 pessoa — é desenhado para equipas.

Recomendação: Kanban simples + iterações leves.

• Quadro com colunas: Backlog → A fazer → Em curso → Feito (Trello, GitHub Projects).
• Limitar WIP — uma tarefa "em curso" de cada vez; terminar antes de começar outra.
• Marcos semanais — pequenas metas e auto-revisão ("o que fiz, o que bloqueia").
• Git desde o início — commits frequentes = histórico do progresso.
• Reunião regular com o orientador (faz de "review/retrospetiva").

Mantém disciplina sem o overhead de Scrum em equipa.