# Problema e utilizadores

Passar de um pedido de aplicação a uma necessidade observável e a requisitos verificáveis.

Página: https://resumos.rgo.pt/cadeiras/pi/problema-e-utilizadores/

A associação recebe pedidos de empréstimo por mensagens. Na última semana, dois voluntários prometeram o mesmo berbequim para a mesma tarde. O proponente pede “uma aplicação com contas, notificações e inteligência artificial”. O pedido escolhe funcionalidades antes de mostrar qual delas evita a promessa duplicada.

## Necessidade e evidência

Uma **necessidade** descreve a dificuldade de alguém num contexto concreto. Aqui, o voluntário precisa de saber se a ferramenta está disponível antes de confirmar o empréstimo. Uma hipótese inicial é que as reservas duplicadas resultem de consultar registos separados. Outras causas continuam em aberto: ferramentas danificadas, atrasos na devolução ou alterações comunicadas tarde.

A observação decide entre estas causas. Pede um caso recente e acompanha a tarefa onde ela acontece:

1.  Regista como se faz hoje, quem intervém e onde surge o erro.
2.  Pede aos voluntários que reconstruam esses dois casos concretos.
3.  Consulta, com autorização, os registos relevantes do período.
4.  Verifica se as promessas já coincidiam quando foram feitas ou se uma devolução atrasada retirou uma ferramenta que parecia disponível.

Duas perguntas conduzem a evidência diferente. “Usaria uma aplicação?” recolhe uma opinião sobre uma solução sugerida. “Mostra como confirmaste o último empréstimo” permite reconstruir o trabalho real e as exceções. A primeira não substitui a segunda.

No registo, separa o que foi dito, observado e inferido:

| Coluna | Exemplo |
| --- | --- |
| Disse | “Pensei que a ferramenta estivesse livre.” |
| Observado | Duas confirmações para períodos incompatíveis na mesma semana, em dez pedidos acompanhados |
| Inferido | Hipótese a confirmar: os voluntários consultam registos separados |

Os dois casos identificam ocorrências a investigar. Não fixam uma taxa anual nem demonstram que a causa é a separação de registos. Também falta conhecer o número total de pedidos e as condições em que os casos aconteceram.

## Partes interessadas

Uma **parte interessada** influencia o projeto ou é afetada por ele. A direção da associação decide recursos, o voluntário confirma empréstimos e o morador precisa da ferramenta no período combinado. Quem mantém o sistema depois do semestre também condiciona a solução, mesmo sem participar na demonstração.

Fala com quem executa a tarefa, além de quem propõe o projeto. A direção pode querer um painel com muitas estatísticas. O voluntário pode precisar primeiro de consultar uma reserva num telemóvel antigo. Quando os pedidos divergem, explicita o conflito e combina uma prioridade ligada ao problema. O número de pedidos de uma pessoa não mede automaticamente a importância de cada funcionalidade.

Prepara o contacto com a organização e o orientador. Explica a finalidade da observação, combina o que podes registar e usa apenas a informação necessária. Para construir o exemplo ou mostrar o sistema em público, dados fictícios podem conservar os casos difíceis sem divulgar nomes, contactos ou histórico de utilizadores.

## Benefício e contexto

A associação pretende facilitar o acesso a ferramentas que os moradores não precisam de comprar para uma utilização ocasional. Esse é o benefício social esperado. Construir a aplicação, ou contar utilizadores registados, ainda não prova que mais pessoas conseguiram as ferramentas de que precisavam.

Liga o benefício à tarefa e às condições da organização. Uma confirmação fiável pode evitar deslocações para recolher uma ferramenta que afinal não está disponível. A equipa pode observar esse resultado num ensaio ou num período acordado, registando o que comparou. Se a solução exigir que todos os moradores tenham um telemóvel recente, pode excluir quem antes fazia o pedido presencialmente. Manter atendimento pelo voluntário conserva esse acesso enquanto a equipa valida a necessidade.

Antes de automatizar uma etapa, identifica quem pode aprovar o empréstimo, quem atualiza o inventário e quem trata uma devolução atrasada. Essas responsabilidades explicam o funcionamento da organização e condicionam o sistema. Uma regra técnica deve representar uma decisão acordada, em vez de alterar esse funcionamento sem o perceber.

## Requisitos e critérios de aceitação

Um **requisito** descreve uma capacidade ou condição da solução. Um **critério de aceitação** diz que resultado observável permite verificar um caso desse requisito. “O sistema deve ser fácil e rápido” ainda não indica a tarefa, o utilizador ou o modo de a avaliar. Requisitos vagos deste tipo são um erro recorrente em projetos de estudantes: descrevem intenções gerais sem dizer o que conta como cumprido.

Para começar, a equipa pode acordar que um voluntário consulta as reservas de uma ferramenta e confirma um período livre. Depois explicita as regras do domínio. No exemplo há uma unidade de cada ferramenta. Uma reserva ocupa o intervalo `[início, fim)`: inclui o início e exclui o fim. Se uma termina no dia 5, outra pode começar no dia 5. Só são válidos períodos com início anterior ao fim.

| Caso | Resultado esperado |
| --- | --- |
| Não há reserva e pede-se `[2,5)` | Confirmar e guardar a reserva |
| Já existe `[2,5)` e pede-se `[4,6)` | Recusar o conflito, conservando a reserva existente |
| Já existe `[2,5)` e pede-se `[5,7)` | Permitir, porque os intervalos não se sobrepõem |
| O início é igual ao fim | Recusar um período vazio |

A regra tem de valer também quando dois voluntários confirmam em simultâneo períodos incompatíveis. Mostrar disponibilidade na página não basta. A confirmação tem de impedir que ambas as reservas fiquem guardadas, por isso o teste consulta o estado final dos dados, e não apenas as mensagens apresentadas. Esta condição pertence ao requisito, mesmo antes de escolher a base de dados.

Os dias desta tabela são unidades abstratas, sem horas ou fusos. Se o projeto reservar por horas, a equipa terá de definir também a interpretação dos instantes e da devolução. Não transportes uma convenção sem a acordar com os utilizadores.

## Âmbito do primeiro incremento

O **âmbito** delimita o que a equipa vai resolver. Um primeiro incremento pode permitir a um voluntário consultar e confirmar empréstimos, com tratamento de conflitos. Contas públicas, pagamentos e recomendações automáticas ficam fora enquanto não forem necessárias para testar essa tarefa.

Escreve também o que continua manual. Se a recolha da ferramenta é combinada por telefone, o protótipo não substituiu todo o processo. Leva ao orientador e ao proponente uma proposta com a necessidade, a evidência disponível, o fluxo escolhido e os critérios. Uma decisão fica verificável quando se sabe quem a confirmou, por que foi tomada e em que condições será revista.

## Exercícios

Reformular um pedido e procurar evidência

Uma associação empresta ferramentas. O diretor pede “uma aplicação com inteligência artificial e notificações”. Dois voluntários relatam que, na última semana, prometeram o mesmo berbequim para períodos incompatíveis. Ainda não conheces os registos nem o processo atual.

Formula uma necessidade sem escolher a tecnologia. Propõe um contacto e uma observação que ajudem a distinguir registos separados de atrasos na devolução. Que conclusão podes tirar dos dois relatos e qual ainda não podes?

Solução

Uma necessidade possível é permitir ao voluntário confirmar se a ferramenta pode ser emprestada no período solicitado antes de prometer a entrega. Inteligência artificial e notificações são propostas de solução, não evidência de que resolvem a dificuldade.

Pede aos voluntários para reconstruírem esses dois casos, consulta com autorização os registos relevantes e acompanha uma confirmação. Verifica se as promessas já coincidiam quando foram feitas ou se uma devolução atrasada retirou uma ferramenta que deveria estar disponível. São causas que podem exigir soluções diferentes.

Os relatos identificam duas ocorrências a investigar. Não fixam uma taxa anual nem demonstram que a causa é a separação de registos. Também é necessário conhecer o número de pedidos e as condições em que os casos aconteceram.

Confere a tua resposta:

*   Separei o pedido de tecnologia da necessidade dos voluntários.
*   Propus observar uma confirmação real e verificar onde ocorre o conflito.
*   Não tratei duas ocorrências observadas como uma taxa anual.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/pi/problema-e-utilizadores/#necessidade-e-evid%C3%AAncia)

Definir resultados para reservas incompatíveis

Há uma unidade de uma ferramenta e já existe a reserva `[3,7)`. O início está incluído, o fim excluído, e os períodos exigem início anterior ao fim.

Indica o resultado esperado para `[4,8)`, `[7,9)` e `[6,6)`. Depois considera outra ferramenta inicialmente livre, com duas tentativas simultâneas para `[2,5)` e `[4,6)`. Que propriedade deve o teste verificar nos dados guardados, além das mensagens apresentadas?

Solução

`[4,8)` sobrepõe-se à reserva existente e deve ser recusada. `[7,9)` começa no fim excluído da anterior e pode ser aceite. `[6,6)` é vazio e viola início anterior ao fim, independentemente de outras reservas.

Na ferramenta inicialmente livre, os períodos das duas tentativas sobrepõem-se. No máximo uma pode ficar confirmada. Se uma for aceite, a outra deve receber o conflito correspondente; ambas não podem ficar guardadas. O teste consulta o estado final, porque duas mensagens de aparente sucesso não provam que a regra foi preservada. A ordem entre as tentativas não está definida no enunciado, por isso não se pode exigir antecipadamente qual delas vence.

Confere a tua resposta:

*   Recusei \[4,8) e aceitei \[7,9) perante \[3,7).
*   Recusei \[6,6) pelo contrato de período válido.
*   Exigi no máximo uma confirmação entre duas tentativas simultâneas incompatíveis.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/pi/problema-e-utilizadores/#requisitos-e-crit%C3%A9rios-de-aceita%C3%A7%C3%A3o)