Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Lobo-guará
  • Wiki
  • Wiki
  • Escopo e Cronograma

Escopo e Cronograma · Changes

Page history
Update Escopo e Cronograma até a US13 authored May 27, 2025 by Nicholas Stefanello Luz's avatar Nicholas Stefanello Luz
Hide whitespace changes
Inline Side-by-side
Escopo-e-Cronograma.md
View page @ d7390f4b
......@@ -66,17 +66,21 @@ Os épicos criados foram:
<details>
<summary>US04 – Mapa de Centros de Apoio</summary>
> **Como** usuário, **quero** … **para** …
> **Como** usuário, **quero** acessar o mapa de centro de apoios, **para** saber onde procurar apoio na minha localidade.
**Critérios de aceite:**
1. A tela deve ser responsiva para mobile e desktop.
2. …
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.
</details>
<details>
<summary>US05 – Cadastro de centros de apoio</summary>
<summary>US05 – Gerenciamento de centros de apoio</summary>
> **Como** administrador, **quero** poder cadastrar, visualizar, atualizar e excluir centros de apoio, **para** gerenciar os centros disponíveis no sistema de forma eficiente.
......@@ -92,6 +96,18 @@ Os épicos criados foram:
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.
</details>
......@@ -100,11 +116,12 @@ Os épicos criados foram:
<details>
<summary>US06 – Adicionar suporte a múltiplos idiomas</summary>
> **Como** usuário, **quero** … **para** …
> **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. A tela deve ser responsiva para mobile e desktop.
2. …
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.
</details>
......@@ -123,7 +140,14 @@ Os épicos criados foram:
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)
</details>
......@@ -188,45 +212,95 @@ Os épicos criados foram:
<details>
<summary>US10 – Edição do cadastro de usuário</summary>
> **Como** usuário, **quero** … **para** …
> **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. A tela deve ser responsiva para mobile e desktop.
2. …
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)
</details>
<details>
<summary>US11 – Esqueci minha senha</summary>
> **Como** usuário, **quero** … **para** …
> **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:**
1. A tela deve ser responsiva para mobile e desktop.
2. …
#### 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.
</details>
### Fórum
<details>
<summary>US12 – Criação de fórum</summary>
<summary>US12 – Assunto</summary>
> **Como** administrador, **quero** … **para** …
> **Como** usuário, **quero** visualizar os assuntos do fórum, **para** participar das discussões de forma eficiente.
**Critérios de aceite:**
1. …
#### 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".
</details>
<details>
<summary>US13 – Criação de tópico</summary>
<summary>US13 – Tópico</summary>
> **Como** administrador ou empresa verificada, **quero** … **para** …
> **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:**
1. …
#### 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.
</details>
<details>
......
Clone repository
  • Arquitetura do Projeto
  • Banco de Dados
  • Configuração do Ambiente
  • Código
  • Escopo e Cronograma
  • Processos
  • codigo
  • design
    • mockups
  • Home
  • mockups