Escopo e Cronograma

Home	Escopo e Cronograma	Processo	Design/Mockups	Configuração	Arquitetura	Infra	Código	BD

User Stories

As histórias de usuário formuladas foram organizadas em conjuntos denominados "épicos", com o propósito de simplificar a visualização das funcionalidades do aplicativo nas fases de conclusão, desenvolvimento ativo e planejamento. Cada épico abrange histórias de usuário convencionais ou histórias de administração.

Os épicos criados foram:

Landing Page
Informações
Mapa Centros de Apoio
Configurações
Autenticação e Cadastro
Fórum
Admin: Controle de usuários e empresas
Admin: Gerência do Fórum

Landing Page

US01 – Acessar Landing Page

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

Critérios de aceite:

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

Informações

US02 – Tela de Leis

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

Critérios de aceite:

A tela deve ser responsiva para mobile e desktop.

US03 – Tela de Quem Somos

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:

A tela deve ser responsiva para mobile e desktop.

Mapa Centros de Apoio

US04 – Mapa de Centros de Apoio

Como usuário, quero … para …

Critérios de aceite:

A tela deve ser responsiva para mobile e desktop.
…

US05 – Cadastro de centros de apoio

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

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

Frontend

Configurações

US06 – Adicionar suporte a múltiplos idiomas

Como usuário, quero … para …

Critérios de aceite:

A tela deve ser responsiva para mobile e desktop.
…

Autenticação e Cadastro

US07 – Cadastro de conta

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

Critérios de aceite:

Backend

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

Frontend

US08 – Login

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

O backend deve validar se o (nome de usuário ou email) e a senha fornecidos estão corretos.
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.
Se as credenciais estiverem incorretas, o sistema deve retornar um erro 401 (Não autorizado) com uma mensagem adequada, como "Credenciais inválidas".
O token gerado deve ter um tempo de expiração configurável (por exemplo, 1 hora).
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".
Middleware de autenticação
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).
O sistema deve usar algoritmos seguros para a validação de senhas (bcrypt).
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

O formulário de login deve conter os campos de (nome de usuário ou email) e senha.
O botão de login deve estar desabilitado até que ambos os campos sejam preenchidos corretamente.
O campo de senha deve ser mascarado, de modo que o usuário não veja o valor digitado.
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.
Após a validação das credenciais, se o login for bem-sucedido, o sistema deve redirecionar o usuário para a Landing Page.
(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.
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".
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.
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.
O token deve ser enviado no header Authorization das requisições posteriores para autenticar o usuário.
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.
O formulário de login deve ser acessível, incluindo etiquetas apropriadas para leitores de tela e navegação por teclado.

US09 – Logout

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

Quando o usuário fizer logout, o backend deve invalidar o token JWT ou qualquer outro mecanismo de autenticação utilizado.
O token inválido não deve ser aceito em requisições subsequentes.
O sistema deve retornar um status de sucesso (exemplo: 200 OK) ao concluir o logout corretamente, indicando que a sessão foi encerrada.
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.
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

Deve existir um botão ou link visível na NavBar que, ao ser clicado, execute a ação de logout.
O botão de logout deve estar disponível apenas após o usuário estar autenticado.
Após o usuário realizar o logout, ele deve ser redirecionado para a tela de login ou para a Landing Page.
O redirecionamento deve ocorrer imediatamente após a resposta do backend indicando que o logout foi bem-sucedido.
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.
O armazenamento local (como localStorage ou sessionStorage) deve ser limpo completamente.
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."
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.

US10 – Edição do cadastro de usuário

Como usuário, quero … para …

Critérios de aceite:

A tela deve ser responsiva para mobile e desktop.
…

US11 – Esqueci minha senha

Como usuário, quero … para …

Critérios de aceite:

A tela deve ser responsiva para mobile e desktop.
…

Fórum

US12 – Criação de fórum

Como administrador, quero … para …

Critérios de aceite:

US13 – Criação de tópico

Como administrador ou empresa verificada, quero … para …

Critérios de aceite:

US14 – Comentário

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

Critérios de aceite:

Admin: Controle de usuários e empresas

US15 – Admin: controle de usuários

Como administrador, quero … para …

Critérios de aceite:

US16 – Admin: controle de empresas

Como administrador, quero … para …

Critérios de aceite:

US17 – Criação de empresa

Como administrador, quero … para …

Critérios de aceite:

US18 – Bloquear/Desativar contar

Como administrador, quero … para …

Critérios de aceite:

US19 – Edição do cadastro de empresa

Como administrador, quero … para …

Critérios de aceite:

Admin: Gerência do Fórum

US20 – Deleção de fórum

Como administrador, quero … para …

Critérios de aceite:

US21 – Deleção de tópico

Como administrador, quero … para …

Critérios de aceite:

US22 – Deleção de comentário

Como administrador, quero … para …

Critérios de aceite:

Sprints

Nesta seção, você encontrará as Histórias de Usuário de cada sprint, bem como o estado de aprovação de cada narrativa, tal como determinado pela parte interessada durante as revisões de sprint.

Definição de pronto

Código revisado e aprovado por ao menos dois AGES III/IV
Sem erros no console ao executar o que foi desenvolvido
Estar de acordo com os critérios de aceite da US relacionada
Aceitação do cliente

Escopo por Sprint

Nesta seção, estão dispostas as histórias de usuário por sprint, acompanhadas dos seus estados de aprovação e uma definição de critérios de conclusão para as histórias de usuário.

Legenda para status de aceite

✅ : US aceita
⚠ : US parcialmente aceita, ou entregue com dívida técnica
❌ : US não aceita

Sprint 1 | 19/03 a 09/04

User Story	Descrição	Status
US01	Como usuário, quero acessar a página inicial (Landing Page), para visualizar os principais fluxos da aplicação.
US05	Como administrador, quero poder cadastrar, visualizar, atualizar e excluir centros de apoio, para gerenciar os centros disponíveis no sistema de forma eficiente.
US07	Como usuário, quero me cadastrar na plataforma, para que eu possa visualizar comentários no fórum.
NO-US	Componente de botão
NO-US	Componente de input
NO-US	NavBar
NO-US	SVG Logo

Sprint 2 | 09/04 a 05/05

User Story	Descrição	Status

Sprint 3 | 05/05 a 26/05

User Story	Descrição	Status

Sprint 4 | 26/05 a 16/06

User Story	Descrição	Status