Problema e utilizadores

Necessidade e evidência

Uma necessidade descreve a dificuldade de alguém num contexto. “Uma aplicação com IA” escolhe uma solução; não explica a causa das reservas duplicadas.
Testa a hipótese no local: acompanha uma confirmação real, reconstrói casos recentes e consulta os registos com autorização.
“Usaria uma aplicação?” recolhe opinião. “Mostra como confirmaste o último empréstimo” reconstrói o trabalho e as exceções.
Separa relato, observação e inferência. Duas ocorrências numa semana identificam casos a investigar; não fixam uma taxa anual.

O proponente apresenta a necessidade; os utilizadores executam as tarefas. Direção, voluntários, moradores e manutenção podem ter prioridades diferentes.
Combina decisões com quem realiza e com quem condiciona o trabalho. O número de pedidos de uma pessoa não mede a importância de cada funcionalidade.
O benefício esperado é facilitar o acesso às ferramentas. Registos e funcionalidades não provam impacto; observa a tarefa e quem pode ficar excluído.
Identifica quem aprova empréstimos e atualiza o inventário antes de automatizar responsabilidades. Usa dados fictícios em exemplos públicos.

O requisito diz a capacidade ou condição; o critério de aceitação fixa um resultado observável.
Para uma unidade, reservas [início,fim) exigem início anterior ao fim. Perante [2,5):

Duas confirmações simultâneas incompatíveis não podem ambas ficar guardadas. Consultar disponibilidade antes da operação não garante essa regra; o teste consulta o estado final.
Dias sem horas ou fusos não se transportam para reservas por horas sem acordo com os utilizadores.

Escolhe um fluxo completo que permita testar a necessidade, como consultar e confirmar um empréstimo.
Explicita o que continua manual e o que fica fora. Regista decisões, evidência e condições de revisão.
Uma decisão fica verificável quando se sabe quem a confirmou, por que foi tomada e em que condições será revista.