GitLab

Como usuário, quero acessar a página inicial (Landing Page), para visualizar os principais fluxos da aplicação.

Critérios de aceite:

1. Logo do projeto.
2. NavBar (Fóruns, informações, leis)
3. Instituições
4. Obs: Mapa de instituições ainda não será adicionado. Posteriormente será colocado na Landing Page.

Como usuário, quero sobre leis e direitos dos refugiados no Brasil, para entender como funciona minha situação legal.

Critérios de aceite:

1. A tela deve ser responsiva para mobile e desktop.

Como usuário, quero acessar a seção "Quem Somos", para conhecer mais sobre a missão, visão e valores da empresa e entender melhor sua história.

Critérios de aceite:

1. A tela deve ser responsiva para mobile e desktop.

Como usuário, quero acessar o mapa de centro de apoios, para saber onde procurar apoio na minha localidade.

Critérios de aceite:

1. Exibição dos Centros de Apoio: O mapa deve exibir pins em cores chamativas indicando os centros de apoio.
2. Requisição de Dados: O mapa deve fazer uma requisição ao backend para obter a lista de centros de apoio e suas localizações.
3. Localização do Usuário: O sistema deve solicitar a localização atual do usuário para exibir o mapa centrado em sua localização. A solicitação de permissão para acessar a localização deve ser clara e explicativa.
4. Zoom do Mapa: Deve haver um botão de ampliar para permitir que o usuário aumente a visualização do mapa.
5. Interação com o Mapa: O usuário deve ser capaz de interagir com o mapa (navegar, fazer zoom, visualizar detalhes de cada centro de apoio ao clicar nos pins).
6. Responsividade: O mapa deve ser responsivo, ajustando-se adequadamente a celular e desktop.
7. Utilizar integração com serviços de terceiro para procurar uma cidade por text e ele converter para coordenadas e então mover o mapa para essas coordenadas.

Como administrador, quero poder cadastrar, visualizar, atualizar e excluir centros de apoio, para gerenciar os centros disponíveis no sistema de forma eficiente.

Critérios de aceite:

Backend

1. O sistema deve permitir cadastrar um novo local com nome, latitude e longitude.
2. O sistema deve permitir buscar todos os locais cadastrados.
3. O sistema deve permitir buscar um local pelo ID.
4. O sistema deve permitir editar um local existente (atualizar nome, lat, long).
5. O sistema deve permitir excluir um local do banco de dados.
6. O backend deve retornar mensagens de erro adequadas caso os dados sejam inválidos ou o local não exista.
7. O CRUD deve ser exposto via API REST com endpoints bem definidos.

Frontend

8. Acesso Exclusivo para Administradores: A tela de gerenciamento dos centros de apoio deve ser acessível apenas para usuários com permissão de administrador. Usuários não administrativos não devem ter acesso a essa tela.
9. Listagem de Centros de Apoio: A tela deve exibir uma tabela com os centros de apoio cadastrados, contendo as seguintes colunas: Nome do Centro, Latitude e Longitude.
10. Botões de Ação: Cada linha da tabela deve ter botões de ação para:

• Editar: Permitir ao administrador editar o nome, latitude e longitude de um centro de apoio
• Excluir: Permitir ao administrador excluir um centro de apoio. Deve ser solicitada uma confirmação antes da exclusão (abrir o modal de deleção)..

11. Cadastro de Novos Centros: Deve haver um botão para adicionar um novo centro de apoio. Ao clicar, o administrador será direcionado para um formulário onde poderá inserir: Nome do Centro, Latitude e Longitude.
12. Edição de Centros de Apoio: Ao clicar no botão de editar, o administrador será direcionado a um formulário com os dados pré-preenchidos do centro de apoio, permitindo que ele edite o nome, latitude e longitude.
13. Validação de Dados: O sistema deve validar os dados inseridos:

• O nome do centro deve ser um campo obrigatório.
• Latitude e longitude devem ser valores numéricos válidos (verificar formato de coordenadas geográficas).

14. Feedback Visual: Após a ação de adicionar, editar ou excluir um centro de apoio, o sistema deve fornecer um feedback visual (como uma mensagem de sucesso ou erro, um toast por exemplo).
15. Responsividade: A tela pode ser apenas para uso em desktop.

Como usuário, quero poder trocar o idioma de preferência, para que eu utilize a plataforma com o meu idioma nativo.

Critérios de aceite:

1. Pode escolher entre Português, Inglês e Espanhol.
2. Escolher a melhor biblioteca para multi-língua.
3. Quando o usuário trocar a configuração de linguagem, todos os textos da plataforma devem trocar de idioma.

Como usuário, quero me cadastrar na plataforma, para que eu possa visualizar comentários no fórum.

Critérios de aceite:

Backend

1. O usuário deve poder se cadastrar preenchendo nome, e-mail, senha, telefone, cidade e linguagem de preferência.
2. Validar tamanho mínimo da senha (8 caracteres)
3. O sistema deve validar se o e-mail já está cadastrado antes de criar a conta.
4. A senha deve ser hasheada antes de ser armazenada no banco.

Frontend

5. Inputs padrão de Nome, Email
6. Input com máscara de telefone
7. Input com máscara para senha
8. Input com máscara para confirmação de senha
9. Dropdown com bandeiras de idiomas (Inglês, Português, Espanhol)
10. Botão de cadastrar
11. Validação do tamanho da senha (≥ 6 caracteres)
12. Validação de email válido (pode ser regex)

Como usuário ou administrador, quero realizar o login na aplicação fornecendo minhas credenciais (nome de usuário e senha), para que eu possa acessar minha conta de forma segura e personalizada, com um token de autenticação válido.

Critérios de aceite:

Backend

1. O backend deve validar se o (nome de usuário ou email) e a senha fornecidos estão corretos.
2. Se as credenciais estiverem corretas, o sistema deve gerar um token JWT (ou outro mecanismo de autenticação) e enviá-lo de volta para o cliente.
3. Se as credenciais estiverem incorretas, o sistema deve retornar um erro 401 (Não autorizado) com uma mensagem adequada, como "Credenciais inválidas".
4. O token gerado deve ter um tempo de expiração configurável (por exemplo, 1 hora).
5. O sistema deve verificar se o usuário está marcado como ativo no banco de dados. Se o usuário estiver inativo, o sistema deve retornar um erro 403 (Proibido) com uma mensagem apropriada, como "Usuário bloqueado".
6. Middleware de autenticação
7. O sistema deve retornar erros 400 (Bad Request) se o formato dos dados enviados na requisição de login for inválido, como campos obrigatórios ausentes (ex: usuário ou senha não informados).
8. O sistema deve usar algoritmos seguros para a validação de senhas (bcrypt).
9. O sistema deve retornar uma resposta clara e estruturada em caso de sucesso, contendo o token de autenticação e outros dados relevantes, como o nome do usuário e as permissões associadas.

Frontend

10. O formulário de login deve conter os campos de (nome de usuário ou email) e senha.
11. O botão de login deve estar desabilitado até que ambos os campos sejam preenchidos corretamente.
12. O campo de senha deve ser mascarado, de modo que o usuário não veja o valor digitado.
13. Se o usuário tentar submeter o formulário sem preencher os campos obrigatórios, uma mensagem de erro deve ser exibida, indicando que ambos os campos são necessários.
14. Após a validação das credenciais, se o login for bem-sucedido, o sistema deve redirecionar o usuário para a Landing Page.
15. (Toast) Se o login falhar (por exemplo, credenciais incorretas), o usuário deve ver uma mensagem de erro clara, como "Credenciais inválidas", sem revelar informações sensíveis.
16. Caso o backend retorne um erro (por exemplo, o servidor esteja offline ou não seja possível validar as credenciais), o frontend deve exibir uma mensagem genérica de erro, como "Erro ao tentar realizar login. Tente novamente mais tarde".
17. Durante o processo de login (enquanto o sistema está verificando as credenciais), o botão de login deve ser desabilitado, e um indicador de carregamento (spinner ou animação) deve ser mostrado para o usuário.
18. O frontend deve armazenar o token de autenticação (se o login for bem-sucedido) em um local seguro, como localStorage ou sessionStorage, para ser usado nas requisições subsequentes.
19. O token deve ser enviado no header Authorization das requisições posteriores para autenticar o usuário.
20. Deve existir um link ou botão na tela de login que redirecione o usuário para uma página de recuperação de senha, caso ele tenha esquecido suas credenciais.
21. O formulário de login deve ser acessível, incluindo etiquetas apropriadas para leitores de tela e navegação por teclado.

Como usuário ou administrador logado, quero fazer fazer logout da minha conta, para que eu não esteja mais autenticado.

Critérios de aceite:

Backend

1. Quando o usuário fizer logout, o backend deve invalidar o token JWT ou qualquer outro mecanismo de autenticação utilizado.
2. O token inválido não deve ser aceito em requisições subsequentes.
3. O sistema deve retornar um status de sucesso (exemplo: 200 OK) ao concluir o logout corretamente, indicando que a sessão foi encerrada.
4. O backend deve garantir que a revogação do token ou qualquer outro mecanismo de logout seja feito de maneira segura, sem expor informações sensíveis.
5. Se houver algum erro ao processar o logout (por exemplo, se a sessão do usuário já tiver expirado), o sistema deve retornar um erro apropriado (exemplo: 401 Unauthorized) com uma mensagem como "Sessão expirada ou já encerrada".

Frontend

6. Deve existir um botão ou link visível na NavBar que, ao ser clicado, execute a ação de logout.
7. O botão de logout deve estar disponível apenas após o usuário estar autenticado.
8. Após o usuário realizar o logout, ele deve ser redirecionado para a tela de login ou para a Landing Page.
9. O redirecionamento deve ocorrer imediatamente após a resposta do backend indicando que o logout foi bem-sucedido.
10. O frontend deve limpar todos os dados de sessão armazenados no navegador (como tokens de autenticação, informações do usuário, etc.) após o logout.
11. O armazenamento local (como localStorage ou sessionStorage) deve ser limpo completamente.
12. Se ocorrer algum erro ao tentar fazer logout (por exemplo, se o servidor estiver indisponível), o sistema deve mostrar uma mensagem de erro genérica, como "Erro ao encerrar a sessão. Tente novamente mais tarde."
13. O botão de logout deve ser acessível, com um texto claro como "Sair" ou "Logout" e suporte a navegação por teclado e leitores de tela.

Como usuário, quero editar as minhas informações pessoais, para que meu cadastro sempre esteja atualizado e de acordo com minhas preferências.

Critérios de aceite:

1. Tela deve ser responsiva para mobile e desktop.
2. Modal contendo um formulário de edição.
3. Os campos não editáveis devem ser exibidos, mas devem estar bloqueados.
4. Informações editáveis:

• Nome
• Senha
• Telefone
• Idioma (DropDown contendo as bandeiras)

Como usuário, quero poder solicitar a recuperação de minha senha, para receber um e-mail com as instruções para redefinir minha senha.

Critérios de aceite:

Backend

1. Verificação de E-mail Existente: O sistema deve verificar se o e-mail inserido está registrado no banco de dados. Se o e-mail não for encontrado, o usuário deve ser informado de que não há conta associada a esse e-mail.
2. Envio de E-mail de Recuperação: Se o e-mail for válido e registrado no sistema, o sistema deve enviar um e-mail para o usuário com um código de recuperação onde o mesmo deve inserir na página selecionada.
3. Fazer a verificação de código já utlizada: Se o código inserido já foi utilizado, a alteração não deve ser efetivada.
4. Verificar a expiração do código: Se já passou 5 minutos que o código foi gerado, alterações não serão mais efetivadas.
5. Verificar se existe algum código não utilizado gerado em menos de 5 minutos: Se caso chegar uma nova requisição de envio de email, mas o usuário já tiver com um código gerado, não utilizado em menos de 5 minutos, deve-se enviar o mesmo código, caso contrário, gerar um novo.

Frontend

6. Tela de Recuperação de Senha: O sistema deve fornecer uma tela de recuperação de senha onde o usuário pode inserir seu e-mail para solicitar a recuperação.
7. Validação de E-mail: O sistema deve validar o e-mail inserido, verificando se é um formato válido (por exemplo, formato de e-mail com "@" e ".com").
8. Após a validação, deve-se direcionar o usuário para uma página que contenha os seguintes inputs:

• Código de verificação
• Nova senha
• Repetição da nova senha
• Um botão para reenvio do código

9. Design Responsivo: A tela de recuperação de senha e a página de redefinição de senha devem ser responsivas e funcionar bem em celular e desktop.
10. Usabilidade e Clareza: As instruções no e-mail e nas páginas devem ser claras e simples, guiando o usuário de forma intuitiva durante todo o processo de recuperação de senha.

Como usuário, quero visualizar os assuntos do fórum, para participar das discussões de forma eficiente.

Critérios de aceite:

Backend

1. Apenas administradores podem criar novos assuntos.
2. Listagem deve aceitar query params para paginação. A ordenação da lista será feita aparecendo primeiro os últimos assuntos criados.
3. Apenas o administrador pode excluir qualquer assunto.
4. Não terá update de assunto.
5. Caso um usuário não autorizado tente deletar um assunto, o sistema deve retornar um erro apropriado (ex: 403 - Forbidden).

Frontend

6. O fórum deve exibir os assuntos existentes em cards. Cada card deve conter:

• Título do assunto
• Breve descrição do assunto
• Botão de "Entrar na discussão", que redireciona o usuário para a página da discussão do assunto.

7. A página do fórum deve ser responsiva, ajustando-se adequadamente a diferentes tamanhos de tela (celular e desktop).
8. Quando os assuntos estão sendo carregados, o usuário deve ver um indicador de carregamento para melhorar a experiência.
9. O usuário deve ser capaz de navegar facilmente pela lista de assuntos e acessar as discussões com um simples clique no botão "Entrar na discussão".

Como usuário, quero visualizar os tópicos do fórum, para participar das discussões ou gerenciar os tópicos de forma eficiente.

Critérios de aceite:

Backend

1. O sistema deve verificar o papel do usuário (administrador ou usuário verificado) para garantir que apenas esses usuários possam criar ou excluir tópicos. Administrador pode excluir qualquer tópico, usuário verificado pode excluir apenas tópico criado por ele mesmo.
2. Listagem deve aceitar query params para paginação. A ordenação da lista deve ser feita conforme o que for recebido do frontend, (Mais comentários, data de criação).

Frontend

3. A página deve exibir os tópicos existentes em cards. Cada card deve conter:

• Título do tópico
• Descrição curta do tópico
• Número de comentários associados a cada tópico
• Botões de ação que permitem aos administradores (ou usuários verificados) criar, editar ou excluir tópicos. Esses botões de ação (criar e excluir) só devem estar visíveis para administradores e usuários verificados

4. O botão "Criar novo tópico" deve estar visível apenas para administradores e usuários verificados.
5. Ao clicar no botão, o administrador será redirecionado para um formulário onde poderá inserir o título, descrição e adicionar tags.
6. Quando o administrador clicar no botão de excluir, o sistema deve pedir confirmação para garantir que o tópico será excluído permanentemente.
7. O usuário verificado apenas poderá excluir tópicos criados por ele mesmo.
8. O número de comentários ao lado de cada tópico deve ser dinâmico, indicando a quantidade atual de interações dentro de cada tópico.
9. A página do fórum e os cards dos tópicos devem ser responsivos e bem ajustados a diferentes tamanhos de tela, conforme mostrado na imagem (celular e desktop).
10. Após a criação, atualização ou exclusão de um tópico, o sistema deve fornecer um feedback visual, como uma mensagem de sucesso ou erro.

Como administrador ou empresa verificada ou usuário, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …

Como administrador, quero … para …

Critérios de aceite:

1. …