Pular para conteúdo

Declaração de Escopo do Produto v0.1.2

Histórico de Revisão

Versão 0.1

  • Data: 25/10/2023
  • Autores: Rodrigo, João Pedro, Manoel
  • Primeiras definições de escopo.

Versão 0.1.1

  • Data: 02/11/2023
  • Autores: João Pedro
  • Adição das User Stories, diagrama de casos de uso e alguns itens no backlog do produto.

Versão 0.1.2

  • Data: 03/11/2023
  • Autores: Rodrigo, Manoel, João Mateus
  • Revisão e alinhamento de todos os documentos

1. Problema / Sistema de software

  • Definição da equipe: Manoel: desenvolvedor front-end, representante do Product Owner; Lara: desenvolvedora front-end; João Pedro: desenvolvedor back-end; Mateus Santos: desenvolvedor back-end; Rodrigo: analista de bancos de dados, scrum master; Eduardo: testador, prototipador, desenvolvedor.

  • Resumo do problema: Falta de um espaço/meio de comunicação para a promoção de eventos de interação entre discentes no campus UnB Gama.

  • Sistema de Software. O nome do projeto é GamaHub e seu objetivo é ser uma plataforma para facilitar o encontro de pessoas com interesses em comum e aproximar os discentes.

  • Resumo de tecnologias usadas: Resuma as tecnologias usadas no desenvolvimento, justificando seus usos Serão utilizados a linguagem de programação JavaScript, por afinidade dos membros do grupo; o JS runtime Node.js, pois é o runtime de maior afinidade do grupo; o framework React, para desenvolver o front-end com facilidade e com as conveniências do framework; o software de bancos de dados MongoDB, por afinidade da equipe; a IDE VSCode, por afinidade da equipe e o software de organização Notion, para organizar as sprints, documentos e arquivos do projeto.

  • Resumo da metodologia de desenvolvimento usada: Resuma o a filosofia de desenvolvimento seu ciclo de vida (fases e atividades). Considerando o contexto do projeto que é de uma aplicação web com vários riscos envolvidos e prazo bastante limitado, foi definido um ciclo de vida ágil, assim como os processos do Scrum XP, visando um produto de software que agrade os usuários e aceite mudanças de requisitos.

Outras informações sobre o ciclo de vida:

  • Métodos, técnicas: Pair Programming, Code Review, Refactoring, Padrões de Codificação, Integração Contínua, Propriedade Coletiva, Projeto Simples e Metáforas.
  • Métricas usadas no desenvolvimento: Tempo de capacitação da equipe, tempo em dias e quantidade de desenvolvedores para completar uma sprint, grau de satisfação do PO
  • Testes de software: Os níveis de testes usados serão unitários e integração.

2. Backlog do produto

2.1 Perfis

Tabela 1 - Perfis de acesso
# Nome do perfil Características do perfil Permissões de acesso
1 Administrador Responsável por realizar a moderação dos usuários e eventos cadastrados no sistema. Permite ver, e deletar usuários e eventos cadastrados. Não tem acesso direto às senhas.
2 Usuário Pode cadastrar informações pessoais para contato, registrar eventos e se inscrever em eventos criados por outros usuários. Permite gerenciar seus próprios eventos e dados cadastrados.
3 Visitante Pode ver todos os eventos cadastrados no sistema. Não pode se inscrever ou criar eventos, apenas visualizar.

2.2 Cenários

Tabela 2 - Cenários funcionais

Sistema: GamaHub – Cenários funcionais
Numeração do cenário Nome do cenário Sprints

2.3 Backlog do produto

Tabela 3 - Backlog do produto

Sistema: GamaHub – Backlog do produto
Numeração

(Cenário / requisito)

Sprint Nome do requisito Tipo de requisito

(Funcional / não funcional)

Priorização do requisito

Must, Should, Could

Descrição sucinta do requisito User stories (U.S.) associadas

Identifique as U.S. associadas ao requisito

Criar Conta Funcional Must Permite ao usuário criar conta para se registar nos eventos. US 01
Listar eventos Funcional Must O sistema lista os eventos cadastrados para os perfis de usuário. US 02
Criar eventos Funcional Must O usuário pode registrar um ou mais eventos. US 03
Excluir evento Funcional Must O usuário pode excluir eventos criados por ele mesmo. US 04
Excluir eventos de usuários Funcional Must O administrador pode apagar um evento, caso o mesmo seja ofensivo de alguma forma, por exemplo. US 05
Banir usuário Funcional Must O administrador pode banir um usuário que tenha uma má conduta. US 06
Editar

informações

Funcional Must O usuário pode editar alguns de seus dados no sistema (Apelido, Pronome) US 12
Editar evento Funcional Must O usuário pode editar seu evento. US 13
Comentários em eventos Funcional Could O usuário pode entrar em contato com o organizador do evento para tirar dúvidas. US 07
Comentários em eventos Funcional Could O usuário pode entrar em contato com o organizador do evento para fazer sugestões ou comentar alguma opinião. US 08
Acrescentar organizadores Funcional Could O organizador do evento pode atribuir um cargo de organizador para outros usuários US 09
Denúncias Funcional Should O usuário pode denunciar um evento ou comentário impróprio / ofensivo US 10
Filtro de categorias Funcional Could O usuário pode filtrar os eventos disponíveis em categorias. US 11
Expirar evento Funcional Should O evento deverá expirar e ser deletado ao fim da data informada pelo usuário US 14
Conformidade com a LGPD Não funcional Must O sistema deve ter sigilo quanto aos dados de usuários mantidos. Os usuários administradores não devem ver senhas cadastradas de usuário, por exemplo.

2.4 Sprints previstas

Tabela 4 - Sprints previstas

Sistema: GamaHub – Sprints previstas
# Sprint Descrição Objetivos Composição de itens do backlog (Lista conforme tabela Backlog do produto)
1 Prototipação do projeto
2 Criar sistema de login de usuário Criar Conta
3 Criar home Visualizar eventos
4
5
6
7
8
Fonte: (Desenvolvedores, 2023)

3. Definição de Ready/Done

  • Ready: Quando a equipe está apta a realizar a tarefa / Não necessita de um tempo para capacitação em questão, sua descrição está clara e alinhada com quem irá executar;
  • Done: Quando a tarefa foi finalizada, testada e validada.

4. US – User Stories

Tabela 5 - User Stories
US 01 Eu como visitante quero criar uma conta para interagir no site.
US 02 Eu como visitante quero que o sistema me mostre os eventos cadastrados, assim posso me informar rapidamente do que está acontecendo no momento antes de decidir se quero ficar na plataforma.
US 03 Eu como usuário quero cadastrar um evento, assim posso reunir pessoas para fazer algo de que gostamos.
US 04 Eu como usuário quero excluir um evento que eu tenha criado, pois desisti do plano inicial.
US 05 Eu como administrador quero apagar eventos criados por usuários, para evitar conteúdos ofensivos/desnecessários.
US 06 Eu como administrador quero poder banir um usuário, para evitar usuários maliciosos na plataforma.
US 07 Eu, como usuário, quero poder tirar dúvidas sobre os eventos, para não ter inconveniências no evento.
US 08 Eu, como usuário, quero poder comentar/sugerir nos eventos, para poder adicionar algo aos eventos.
US 09 Eu, como usuário, quero ter mais pessoas como organizadoras do meu evento, pois assim não ficaria sobrecarregado com tarefas.
US 10 Eu, como usuário, quero poder denunciar eventos/comentários maldosos/perigosos, assim posso ajudar a plataforma a ficar mais segura para usar.
US 11 Eu, como visitante, quero filtrar os eventos por categorias, assim posso encontrar eventos do meu interesse mais facilmente.
US 12 Eu, como usuário, quero poder editar informações do meu perfil, pois posso mudar algo em mim ou ter cometido algum erro no cadastro.
US 13 Eu, como usuário, quero poder editar informações do meu evento, pois posso mudar algo ou inserir novas informações.
US 14 Eu, como usuário, quero que meus eventos expiram automaticamente após o término, pois não há necessidade de fazer isso manualmente.

5. Diagrama de casos de uso

//

6. MVP

O MVP será atingido quando os requisitos / USs marcados como Must forem concluídos e devidamente validados, ou seja, o sistema deverá ser capaz de receber cadastros de usuários que irão cadastrar eventos e também poderão se cadastrar em eventos criados por outros usuários.