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 acessar o mapa de centro de apoios, para saber onde procurar apoio na minha localidade.
Critérios de aceite:
- Exibição dos Centros de Apoio: O mapa deve exibir pins em cores chamativas indicando os centros de apoio.
- 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.
- 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.
- Zoom do Mapa: Deve haver um botão de ampliar para permitir que o usuário aumente a visualização do mapa.
- 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).
- Responsividade: O mapa deve ser responsivo, ajustando-se adequadamente a celular e desktop.
- 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.
US05 – Gerenciamento 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
- 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.
- 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.
- 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)..
- 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.
- 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.
- 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).
- 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).
- Responsividade: A tela pode ser apenas para uso em desktop.
Configurações
US06 – Adicionar suporte a múltiplos idiomas
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:
- Pode escolher entre Português, Inglês e Espanhol.
- Escolher a melhor biblioteca para multi-língua.
- Quando o usuário trocar a configuração de linguagem, todos os textos da plataforma devem trocar de idioma.
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
- Inputs padrão de Nome, Email
- Input com máscara de telefone
- Input com máscara para senha
- Input com máscara para confirmação de senha
- Dropdown com bandeiras de idiomas (Inglês, Português, Espanhol)
- Botão de cadastrar
- Validação do tamanho da senha (≥ 6 caracteres)
- Validação de email válido (pode ser regex)
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 editar as minhas informações pessoais, para que meu cadastro sempre esteja atualizado e de acordo com minhas preferências.
Critérios de aceite:
- Tela deve ser responsiva para mobile e desktop.
- Modal contendo um formulário de edição.
- Os campos não editáveis devem ser exibidos, mas devem estar bloqueados.
- Informações editáveis:
- Nome
- Senha
- Telefone
- Idioma (DropDown contendo as bandeiras)
US11 – Esqueci minha senha
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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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").
- 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
- 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.
- 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.
Fórum
US12 – Assunto
Como usuário, quero visualizar os assuntos do fórum, para participar das discussões de forma eficiente.
Critérios de aceite:
Backend
- Apenas administradores podem criar novos assuntos.
- Listagem deve aceitar query params para paginação. A ordenação da lista será feita aparecendo primeiro os últimos assuntos criados.
- Apenas o administrador pode excluir qualquer assunto.
- Não terá update de assunto.
- Caso um usuário não autorizado tente deletar um assunto, o sistema deve retornar um erro apropriado (ex: 403 - Forbidden).
Frontend
- 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.
- A página do fórum deve ser responsiva, ajustando-se adequadamente a diferentes tamanhos de tela (celular e desktop).
- Quando os assuntos estão sendo carregados, o usuário deve ver um indicador de carregamento para melhorar a experiência.
- 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".
US13 – Tópico
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
- 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.
- 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
- 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
- O botão "Criar novo tópico" deve estar visível apenas para administradores e usuários verificados.
- Ao clicar no botão, o administrador será redirecionado para um formulário onde poderá inserir o título, descrição e adicionar tags.
- 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.
- O usuário verificado apenas poderá excluir tópicos criados por ele mesmo.
- 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.
- 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).
- 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.
US14 – Comentário
Como usuário, quero poder criar, visualizar e apagar comentários em um tópico do fórum, para que eu possa interagir e contribuir com discussões relevantes.
Critérios de aceite:
Backend
- O usuário deve poder criar um comentário em um tópico específico do fórum.
- O comentário deve conter:
- ID do usuário que comentou (autor)
- ID do tópico relacionado
- Conteúdo do comentário (as imagens vão conter URL por enquanto, posteriormente vamos adaptar para usar buckets S3)
- Data/hora de criação
- O sistema deve validar que:
- O conteúdo não está vazio
- O tópico existe
- O usuário está autenticado
- O usuário deve poder visualizar todos os comentários relacionados a um tópico.
- Os comentários devem ser retornados ordenados por data de criação (do mais recente para o mais antigo).
- Cada comentário exibido deve mostrar:
- Nome do autor
- Conteúdo
- Data/hora do comentário
- O usuário deve poder apagar um comentário apenas se:
- Ele for o autor do comentário OU
- Ele for um administrador/moderador
- O conteúdo do comentário deve ter limite de caracteres (ex: até 500).
- Toda ação deve ser protegida por autenticação (JWT, session, etc.).
- Utilizar soft delete.
Frontend
- O usuário autenticado deve conseguir adicionar um novo comentário em um tópico.
- O comentário deve conter no mínimo 1 caractere e no máximo 500 caracteres.
- O comentário pode conter uma imagem e texto (no máximo 1 imagem por comentário).
- Após a criação, o novo comentário deve ser exibido imediatamente abaixo do tópico.
- Apenas usuários autenticados devem conseguir visualizar os comentários de um tópico.
- Deve ser possível responder a um comentário específico, criando uma espécie de "thread".
- Um aviso de confirmação deve ser apresentado antes da remoção definitiva.
- O sistema deve impedir envio de comentários vazios ou com apenas espaços em branco.
- Mensagens de erro claras devem ser exibidas em caso de falha (ex: limite de caracteres excedido, falha na conexão).
- Os comentários devem ser exibidos com:
- Nome de usuário (ou identificador anônimo, se aplicável)
- Tempo decorrido desde a publicação (ex: “2 minutos atrás”)
- Texto do comentário
Admin: Controle de usuários e empresas
US15 – Admin: controle de usuários
Como administrador, quero visualizar, ativar e desativar usuários cadastrados, para que eu possa gerenciar quem tem acesso ao sistema de forma eficiente.
Critérios de aceite:
- Acesso Exclusivo para Administradores: A tela de controle de usuários deve ser acessível apenas para administradores.
- Listagem de Usuários: A tela deve exibir uma tabela com os usuários cadastrados, contendo as seguintes colunas:
- Nome
- Telefone
- Nacionalidade
- Status (Ativo/Inativo)
- Ações:
- Ativar/Desativar: Cada linha deve ter um botão para ativar ou desativar o usuário, conforme o status atual.
- Ao clicar, deve ser exibido um modal de confirmação antes da execução.
- Após ativar ou desativar, o sistema deve exibir uma mensagem de sucesso ou erro (ex: toast).
- Responsividade: Tela pode ser otimizada para desktop apenas.
US16 – Admin: controle de empresas
Como administrador, quero visualizar e verificar empresas cadastradas, para que eu possa permitir ou restringir quais empresas podem criar tópicos no sistema.
Critérios de aceite:
- Acesso Exclusivo para Administradores: A tela de controle de empresas deve ser acessível apenas para administradores.
- Listagem de Empresas: A tela deve exibir uma tabela com as empresas cadastradas, contendo:
- Nome da empresa
- CNPJ
- Status de verificação (Verificada/Não verificada)
- Status (Ativa/Inativa)
- Ações:
- Verificar Empresa: Empresas não verificadas devem ter um botão "Verificar" para conceder permissão de criar tópicos.
- Após verificada, o botão deve sumir ou ficar desabilitado.
- Um modal de confirmação deve ser exibido antes de confirmar a verificação.
- Ativar/Desativar: Cada linha deve ter um botão para ativar ou desativar a empresa, conforme o status atual.
- Ao clicar, deve ser exibido um modal de confirmação antes da execução.
- Após verificar uma empresa, o sistema deve exibir uma mensagem de sucesso ou erro (ex: toast).
- Responsividade: Tela pode ser otimizada para desktop apenas.
US17 – Criação de empresa
Como administrador, quero poder cadastrar empresas para que elas possam criar tópicos para divulgação de vagas e informações.
Critérios de aceite:
- Input de CNPJ com a máscara para o mesmo;
- Validar o tamanho do CNPJ;
- Ter as mesmas validações dos inputs do cadastro de conta padrão;
US18 – Bloquear/Desativar contar
Como administrador, quero … para …
Critérios de aceite:
- …
US19 – Edição do cadastro de empresa
Como empresa, 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:
- Tela deve ser responsiva para mobile e desktop.
- Modal contendo um formulário de edição.
- Os campos não editáveis devem ser exibidos, mas devem estar bloqueados.
- Informações editáveis:
- Nome
- Senha
- Telefone -Idioma (DropDown contendo as bandeiras)
Admin: Gerência do Fórum
US20 – Deleção de fórum
Como administrador, quero poder deletar assuntos do fórum, para manter a organização e remover tópicos irrelevantes ou inadequados.
Critérios de aceite:
- O botão de lixeira para deletar um assunto deve ser exibido apenas para usuários com perfil de administrador. Usuários comuns e empresas verificadas não devem ver esse botão.
- Ao clicar no botão de lixeira, deve ser exibido um modal ou diálogo de confirmação com a mensagem: "Tem certeza que deseja deletar este assunto? Essa ação não poderá ser desfeita."Deve ter as opções "Cancelar" e "Confirmar".
- Ao confirmar, o assunto deve ser removido da lista de forma imediata.
- Deve ser apresentado um toast, dizendo:"Assunto deletado com sucesso."
US21 – Deleção de tópico
Como administrador ou usuário verificado, quero poder deletar tópicos do fórum (respeitando minhas permissões), para manter o fórum organizado e com conteúdos relevantes.
Critérios de aceite:
- O botão de lixeira para deletar um tópico deve ser visível apenas para:
- Administradores (em todos os tópicos)
- Usuários verificados (somente nos tópicos que eles mesmos criaram)
- Usuários comuns não devem ver o botão de deletar em nenhum caso
- Ao clicar no botão de lixeira, deve ser exibido um modal de confirmação com a mensagem: "Tem certeza que deseja excluir este tópico? Esta ação é irreversível." O modal deve conter as opções "Cancelar" e "Confirmar".
- Ao confirmar a exclusão, o tópico deve ser removido da lista visível de forma imediata.
- Um toast deve informar o sucesso ou falha da operação, com mensagens como: "Tópico deletado com sucesso." e "Erro ao deletar o tópico. Tente novamente."
US22 – Deleção de comentário
Como administrador ou usuário do fórum, quero poder deletar comentários (meus ou, se for o caso, de outros como administrador), para gerenciar adequadamente as contribuições e manter a relevância da discussão.
Critérios de aceite:
- O botão de lixeira deve aparecer:
- Para usuários comuns: somente nos comentários que eles mesmos criaram
- Para administradores: em todos os comentários
- O botão de lixeira não deve ser renderizado em comentários que o usuário não pode deletar.
- Ao clicar no botão de lixeira, deve ser exibido um modal ou diálogo de confirmação com a mensagem: "Tem certeza que deseja deletar este comentário? Essa ação não poderá ser desfeita." O modal deve conter os botões: "Cancelar" e "Confirmar".
- Ao confirmar a deleção, o comentário deve desaparecer imediatamente da interface.
- Um toast deve ser exibida com a mensagem:"Comentário deletado com sucesso."
- Se a deleção falhar por qualquer motivo (ex: erro de rede), deve ser exibida uma mensagem de erro clara: "Não foi possível deletar o comentário. Tente novamente."
US23 – Edição do avatar
Como usuário, quero editar meu avatar (a partir dos avatares disponíveis), para deixar meu perfil mais customizado do jeito que eu gosto.
Critérios de aceite:
- O usuário deve visualizar uma galeria de avatares pré-selecionados para escolher.
- Ao clicar em um avatar, ele deve ser imediatamente destacado ou marcado como selecionado.
- Deve haver um botão de confirmação para salvar a escolha do novo avatar.
- Após a confirmação, o avatar do perfil deve ser atualizado imediatamente.
- Se o usuário sair da tela sem confirmar, nenhuma alteração deve ser salva.
- A interface deve ser responsiva, adaptando a visualização da galeria a diferentes tamanhos de tela.
- Apenas os avatares disponibilizados no sistema podem ser escolhidos (sem upload de imagem personalizada).
- Caso ocorra algum erro ao salvar a escolha, deve ser exibida uma mensagem de erro apropriada ao usuário.
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 |
---|