Backlog do Produto

Introdução

O Backlog do Produto é uma ferramenta essencial no processo de desenvolvimento ágil, representando uma lista priorizada de funcionalidades e requisitos que guiarão o trabalho do Time de Desenvolvimento ao longo das Sprints. Sua principal característica é a constante evolução, já que está em constante atualização, reordenação e refinamento à medida que o projeto avança. Essa flexibilidade permite que o Backlog se adapte ao surgimento de novos requisitos e mudanças nas necessidades do cliente, refletindo o aprendizado contínuo sobre o produto em desenvolvimento.

Dessa forma, o Backlog do Produto nunca está completo, pois acompanha o progresso do projeto, garantindo que o time esteja sempre alinhado às prioridades mais atuais. Ele não apenas serve como um ponto de partida para os primeiros desenvolvimentos, mas também como um guia dinâmico, capaz de se moldar conforme as mudanças no ambiente e nas expectativas do cliente.

No contexto do Scrum, épicos, requisitos e tasks são diferentes níveis de detalhamento das funcionalidades e atividades a serem realizadas.

1. Épicos

Definição: Grandes funcionalidades ou áreas do produto, ainda não detalhadas.
Características:
- De alto nível e grandes demais para uma única Sprint.
- Precisam ser divididos em histórias de usuário.
Exemplo: "Como usuário, desejo poder realizar um pagamento online."

2. Requisitos

Definição: Funcionalidades específicas que o produto deve ter.
Características:
- Mais específicos que os épicos, geralmente representados por histórias de usuário.
Exemplo: "Como cliente, quero ver um resumo do meu pedido antes de pagar."

3. Tasks (Tarefas)

Definição: Atividades detalhadas necessárias para completar um requisito.
Características:
- Pequenas e claras, podem ser completadas em um ou dois dias.
Exemplo: "Implementar o formulário de pagamento."

No contexto deste trabalho, os épicos foram organizados em quatro grandes áreas, cada uma representando um conjunto de funcionalidades essenciais para o desenvolvimento do produto. As áreas são:

Sugestão de bebidas através dos ingredientes: Funcionalidade que permite ao usuário receber sugestões de bebidas com base nos ingredientes disponíveis.
Configuração do cardápio: Permite a personalização e definição dos itens que compõem o cardápio.
Seleção do cardápio: Envolve o processo de escolha dos itens do cardápio pelo usuário, facilitando a experiência de compra.
Notificações: Sistema de comunicação para alertar os usuários sobre atualizações, promoções ou status do pedido.

Essas áreas, ao serem detalhadas e refinadas, serão desdobradas em requisitos e tarefas específicas ao longo do projeto.

Na estrutura de organização do trabalho, utilizamos a seguinte convenção para identificar e categorizar os itens do Backlog do Produto:

EX: Representa um épico, onde X é o número do épico.
RY.X: Refere-se a um requisito, onde X é o número do épico ao qual o requisito RY pertence.
T(B|F).X.Y.Z: Identifica uma tarefa, onde:
B ou F indica se a tarefa é de backend (B) ou frontend (F).
X representa o número do épico.
Y é o número do requisito ao qual a tarefa pertence.
Z é o número sequencial da tarefa.

Essa estrutura permite uma organização clara e detalhada das funcionalidades, requisitos e tarefas dentro do Backlog, facilitando o acompanhamento e a execução do projeto.

Épicos

Épico 1 (E01): Sugestão de Bebidas Baseada nos Ingredientes Disponíveis na Máquina

Objetivo: Permitir que o usuário selecione os ingredientes disponíveis na máquina e, por meio de uma integração com uma API externa, o sistema sugira todas as bebidas que podem ser feitas com esses ingredientes. O administrador terá controle sobre quais bebidas aparecem no cardápio e poderá ocultá-las se necessário.

Requisitos e Tarefas

RF1.1: Listagem de Ingredientes IBA

Como administrador do sistema,
Eu quero selecionar, com opção de filtragem, os ingredientes disponíveis na máquina a partir da lista oficial IBA,
Para que o sistema possa determinar quais bebidas podem ser preparadas com base nas opções selecionadas.

Critérios de Aceitação:
  1. O administrador deve ser capaz de visualizar a lista completa de ingredientes da IBA.
  2. O administrador pode marcar os ingredientes que estão disponíveis na máquina.
  3. O administrador deve ser capaz de buscar ingredientes específicos por parte de seu nome, visto que a lista é extensa.

Exemplo:
  - O administrador seleciona "Rum", "Ginger Ale" e "Lima".

Tarefas Principais do Backend

Neste contexto, o Backend será responsável por retornar ao frontend uma lista de ingredientes possíveis para a criação de drinks catalogados pelo International Bartenders Association (IBA)

TB1.1.1: Criar Endpoint para Listagem de "Ingredientes IBA"
Descrição: Criar um endpoint que forneça a lista de ingredientes filtrados baseado no filtro informado (caso não seja informado filtro, trazer a lista por completo).
Objetivo: O frontend irá consumir esse endpoint para obter a lista de ingredientes, que será utilizada para sugerir bebidas para o usuário.

Tarefas Principais do Frontend

O Frontend será responsável por exibir os ingredientes fornecidos pelo backend e permitir ao usuário interagir com esses dados, selecionando os ingredientes que estão disponíveis para criação de bebidas.

TF1.1.1: Criar Interface de Listagem de Ingredientes IBA
Descrição: Criar a interface que exibe a lista de ingredientes provenientes da IBA para o usuário selecionar e visualizar.
TF1.1.2: Seleção de Ingredientes (Múltiplos)
Descrição: Permitir que o usuário selecione múltiplos ingredientes da lista de ingredientes da IBA.
TF1.1.3: Filtragem e Busca de Ingredientes
Descrição: Implementar funcionalidades de filtro e busca para facilitar a seleção de ingredientes.

RF2.1: Listagem de Bebidas Possíveis para a montagem do cardápio

Como administrador do sistema,
Eu quero que o sistema exiba uma lista de bebidas que podem ser preparadas com base nos ingredientes selecionados,
Para que eu possa montar o cardápio de bebidas de acordo com os ingredientes disponíveis na máquina.

Critérios de Aceitação:
    1. O administrador deve ver uma lista de bebidas que podem ser preparadas com os ingredientes marcados como disponíveis.
    2. O sistema deve sugerir automaticamente bebidas compatíveis com a combinação de ingredientes selecionados.
    3. O administrador pode adicionar ou remover bebidas da lista sugerida, conforme necessário para compor o cardápio.
    4. O sistema deve atualizar as opções de bebidas em tempo real sempre que houver alterações na seleção de ingredientes.
    5. O sistema deve garantir que apenas bebidas que podem ser preparadas com os ingredientes disponíveis sejam sugeridas.

Exemplo:
    - O administrador seleciona "Rum", "Lima" e "Açúcar".
    - O sistema exibe bebidas como "Mojito", "Daiquiri" e "Caipirinha" como opções viáveis para o cardápio.

Tarefas Principais do Backend

O Backend será responsável por processar as combinações de ingredientes selecionados e retornar ao frontend as bebidas possíveis que podem ser preparadas com esses ingredientes.

TB1.2.1: Criar Endpoint para Listagem de Bebidas Possíveis
Descrição: Criar um endpoint que, dado um conjunto de ingredientes selecionados pelo usuário, retorne a lista de drinks que podem ser preparados com esses ingredientes. A consulta deverá ser feita com base na base de dados da IBA ou em uma lista pré-definida de receitas compatíveis.

Tarefas Principais do Frontend

O Frontend será responsável por apresentar ao usuário as bebidas possíveis de acordo com a seleção dos ingredientes, permitindo que ele visualize as opções e escolha quais drinks deseja apresentar em seu cardápio.

TF1.2.1: Criar Interface de Exibição das Bebidas Possíveis
Descrição: Desenvolver uma interface onde o usuário poderá ver a lista de drinks sugeridos com base nos ingredientes que ele selecionou. Cada bebida deverá ter informações relevantes, como nome, ingredientes, modo de preparo e um ícone ou imagem representativa.
TF1.2.2: Filtragem de Bebidas
Descrição: Implementar um filtro de pesquisa que permita ao usuário filtrar um determinado drink por parte de seu nome.

RF3.1: Visualização dos Detalhes de uma Bebida

Como usuário (administrador),
Eu quero visualizar os detalhes de uma bebida específica ao selecioná-la,
Para que eu possa obter informações sobre o modo de preparo e as proporções dos ingredientes, com base na base de dados da IBA.

Critérios de Avaliação:
  1. Ao selecionar uma bebida, o sistema deve mostrar as informações completas sobre a bebida, incluindo o modo de preparo e as proporções dos ingredientes.

Exemplo:
  1. O administrador clica na bebida "Mojito" na lista.
  2. O sistema mostra uma tela com o modo de preparo detalhado e as proporções de cada ingrediente.

Tarefas Principais do Backend

TB1.3.1: Criar Endpoint para Detalhes de uma Bebida
Descrição: Criar um endpoint que, dado uma bebida específica selecionada pelo usuário, retorne os seus detalhes, como: Modo de preparar e proporção dos ingredientes. A consulta deverá ser feita com base na base de dados da IBA.

Tarefas Principais do Frontend

TF1.3.1: Exibir Detalhes da Bebida
Descrição: Ao clicar em uma bebida, o usuário deve ser direcionado a uma tela com mais detalhes sobre a receita, incluindo o modo de preparar e proporções dos ingredientes.

RF4.1: Salvar escolhas do usuário para o cardápio

Como administrador,
Eu quero que o sistema salve as bebidas escolhidas para o cardápio,
Para que essas escolhas permaneçam registradas e sejam exibidas corretamente na máquina para os usuários.

Critérios de Aceitação:
  1. O administrador pode selecionar as bebidas que deseja adicionar ao cardápio.
  2. O sistema deve salvar as escolhas do administrador de forma permanente para essa máquina específica.
  3. As bebidas escolhidas devem ser exibidas corretamente no cardápio da máquina assim que forem selecionadas.
  4. Se o administrador fizer alterações no cardápio (adicionar ou remover bebidas), o sistema deve atualizar as escolhas de forma persistente.
  5. O sistema deve garantir que as escolhas do cardápio sejam mantidas, mesmo após o reinício do sistema ou desligamento da máquina.

Exemplo:
  1. O administrador seleciona as bebidas "Mojito" e "Caipirinha" para o cardápio.
  2. O sistema salva essas escolhas e as exibe como opções no cardápio da máquina.
  3. Quando um novo usuário acessar a máquina, ele verá as bebidas "Mojito" e "Caipirinha" no cardápio, como selecionado pelo administrador.

Tarefas Principais do Backend

O Backend será responsável por receber as escolhas do cardápio do administrador e armazená-las de forma persistente.

TB1.4.1: Criar Endpoint para persistir o Cardápio escolhido
Descrição: Criar um endpoint que, dado um conjunto de bebidas selecionadas pelo usuário, o sistema persista essa escolha de bebidas para a montagem do cardápio.

Tarefas Principais do Frontend

O Frontend será responsável por prover uma interface onde o usuário escolha as bebidas desejadas e envie ao backend para a persistência da escolha.

TF1.3.1: Seleção de Bebidas (Múltiplas)
Descrição: Permitir que o usuário selecione múltiplas bebidas, disponíveis com os ingredientes previamente informados, para a composição do cardápio.

Após a implementação desses requisitos listados nesse épico, a máquina terá seu cardápio configurado e assim o usuário poderá escolher as bebidas necessárias para a preparação (Épico 2).

Épico 2 (E02): Cardápio e Seleção de Drinks

Objetivo: Permitir que o usuário visualize o cardápio com as bebidas disponíveis (com base nas escolhas feitas no Épico 1) e escolha uma bebida para ser preparada, adicionando-a à fila de preparo da máquina.

Requisitos e Tarefas

RF1.2: Exibição do Cardápio de Bebidas Disponíveis

Como usuário,
Eu quero visualizar o cardápio de bebidas disponíveis,
Para que eu possa escolher qual bebida desejo preparar.

Critérios de Aceitação:
  1. O sistema deve exibir uma lista de bebidas disponíveis no cardápio.
  2. Cada bebida no cardápio deve ser apresentada com seu nome.

Exemplo:
  1. O usuário acessa a tela do cardápio e vê uma lista de bebidas, como "Mojito", "Caipirinha" e "Cuba Libre".
  2. O usuário seleciona "Mojito" para iniciar o preparo.

Tarefas Principais do Backend

O Backend será responsável por fornecer as bebidas que fazem parte do cardápio configurado pela máquina e retornar ao frontend a lista de bebidas disponíveis para seleção.

TB2.1.1: Criar Endpoint para Retornar o Cardápio de Bebidas
Descrição: Criar um endpoint que retorne a lista de bebidas configuradas no cardápio, filtrado caso um filtro seja informado (TF1.3.1).
Objetivo: O frontend utilizará esse endpoint para exibir as opções de bebidas disponíveis no cardápio.

Tarefas Principais do Frontend

O Frontend será responsável por exibir as bebidas disponíveis no cardápio e permitir ao usuário interagir com essas opções.

TF2.1.1: Criar Interface de Exibição do Cardápio
Descrição: Criar a interface que exibe a lista de bebidas configuradas no cardápio, permitindo que o usuário visualize os drinks e seus detalhes.
Objetivo: O usuário verá todas as bebidas configuradas na máquina e poderá escolher uma bebida para enviar à fila de preparo.
TF2.1.2: Exibição de Detalhes das Bebidas
Descrição: Permitir ao usuário visualizar os detalhes de cada bebida ao clicar sobre ela. Isso pode incluir informações como nome, ingredientes e uma breve descrição.
Objetivo: O usuário pode tomar uma decisão informada antes de adicionar a bebida à fila de preparo.
TF2.1.3: Filtragem e Pesquisa de Bebidas
Descrição: Implementar um sistema de busca ou filtragem para que o usuário possa encontrar rapidamente a bebida que deseja entre as opções do cardápio por parte de seu nome.
Objetivo: Facilitar a navegação do usuário ao cardápio, especialmente se houver muitas opções de bebidas.

RF2.2: Seleção de Bebidas para Preparação

Como usuário,
Eu quero selecionar uma bebida do cardápio e adicioná-la à fila de preparação,
Para que o processo de preparo da bebida seja iniciado.

Critérios de Aceitação:
  1. O usuário pode selecionar uma bebida disponível no cardápio.
  2. Ao selecionar a bebida, o sistema deve adicionar a bebida à fila de preparação.
  3. O sistema deve exibir uma mensagem confirmando que a bebida foi adicionada à fila e está em processo de preparo.

Exemplo:
  1. O usuário escolhe "Mojito" no cardápio e clica em "Adicionar à fila".
  2. O sistema confirma que "Mojito" foi adicionado à fila de preparação e inicia o processo de preparo.

Tarefas Principais do Backend

O Backend será responsável por processar a solicitação de seleção de bebida e adicioná-la à fila de preparação. A máquina deverá ser informada da seleção para que o processo de preparo possa começar.

TB2.2.1: Criar Endpoint para Adicionar Bebida à Fila de Preparação
Descrição: Desenvolver um endpoint para processar a seleção da bebida e adicioná-la à fila de preparo.

Tarefas Principais do Frontend

O Frontend será responsável por permitir que o usuário selecione uma bebida e veja o status da preparação em tempo real.

TF2.2.1: Criar Interface de Seleção de Bebida
Descrição: Criar a interface onde o usuário pode clicar em uma bebida para adicioná-la à fila de preparo.
TF2.2.2: Exibir Feedback de Seleção
Descrição: Ao selecionar uma bebida, exibir um feedback visual para indicar que a bebida foi adicionada à fila de preparo.

RF3.2: Cancelamento de Bebida

Como usuário,
Eu quero ser capaz de cancelar uma bebida da fila de preparação,
Para que eu possa interromper o processo caso mude de ideia, **desde que a bebida ainda não tenha começado a ser preparada**.

Critérios de Aceitação:
  1. O usuário pode visualizar a lista de bebidas na fila de preparação.
  2. O usuário pode selecionar uma bebida na fila para cancelar, **desde que o preparo ainda não tenha começado**.
  3. Se o preparo da bebida já tiver começado, o sistema deve impedir o cancelamento e informar que a bebida já está em processo de preparação.
  4. Caso o cancelamento seja permitido, o sistema deve remover a bebida da fila.
  5. O sistema deve exibir uma mensagem confirmando que a bebida foi removida da fila ou informar que o cancelamento não pode ser feito, pois o preparo já foi iniciado.

Exemplo:
  1. O usuário vê que "Caipirinha" está na fila de preparação, mas ainda não foi iniciada.
  2. O usuário decide cancelar a bebida e clica em "Cancelar" ao lado de "Caipirinha".
  3. O sistema confirma que "Caipirinha" foi removida da fila.
  4. Se o usuário tentar cancelar uma bebida que já começou a ser preparada, o sistema informa: "Impossível cancelar, o preparo da bebida já foi iniciado."

Tarefas Principais do Backend

O Backend será responsável por processar o cancelamento de uma bebida e removê-la da fila de preparo.

TB2.3.1: Criar Endpoint para Cancelamento de Bebida na Fila de Preparação
Descrição: Criar um endpoint para permitir que o usuário cancele uma bebida na fila de preparação.

Tarefas Principais do Frontend

O Frontend será responsável por permitir que o usuário cancele a bebida, mostrando o status de cancelamento.

TF2.3.1: Criar Interface para Cancelamento de Bebida
Descrição: Criar a interface onde o usuário pode clicar para cancelar uma bebida na fila de preparo.
TF2.3.2: Exibir Feedback de Cancelamento
Descrição: Exibir um feedback visual ou uma confirmação ao usuário de que a bebida foi removida com sucesso da fila de preparo.

O Épico 2 tem como objetivo principal permitir que o usuário visualize o cardápio de bebidas disponíveis e, a partir disso, selecione uma bebida para adicionar à fila de produção. O sistema também permitirá o cancelamento de bebidas na fila, desde que o preparo ainda não tenha começado. A interação entre o Frontend e o Backend garantirá que as ações do usuário, como adicionar ou cancelar bebidas da fila de produção, sejam realizadas corretamente. Com a conclusão deste épico, o sistema será capaz de gerenciar de forma eficiente a fila de produção de bebidas, garantindo que o processo de preparo seja iniciado ou interrompido conforme as escolhas do usuário.

Épico 3 (E03): Visualização de Status da Máquina

Objetivo: Permitir que o administrador visualize métricas da máquina, a fim de facilitar a gestão e monitoramento do sistema.

Requisitos e Tarefas

RF1.3: Visualização de Status dos Compartimentos de ingredientes

Como administrador,
Eu quero visualizar o status de cada compartimento de ingredientes líquidos da máquina (como rum, vodka, gin, etc.),
Para que eu possa monitorar os níveis desses insumos e garantir que não faltem durante o uso.

Critérios de Aceitação:
  1. O sistema deve exibir o status atual de cada compartimento de ingrediente líquido, incluindo o nível de insumo, em porcentagem.
  2. O status de cada compartimento de ingrediente líquido deve ser atualizado em tempo real.
Exemplo:
  1. O administrador acessa a tela de métricas e vê o status dos compartimentos de ingredientes líquidos, como "Rum: 75%", "Vodka: 80%", "Gin: 20%".
  2. O administrador pode tomar uma ação para substituir o gin e garantir que a máquina continue funcionando normalmente.

Tarefas Principais do Backend

O Backend será responsável por enviar os dados do status dos compartimentos para o Frontend.

TB3.1.1: Criar Endpoint para Status dos Compartimentos
Descrição: Criar um endpoint que forneça os níveis de insumo de cada compartimento.

Tarefas Principais do Frontend

O Frontend será responsável por exibir as métricas de insumos.

TF3.1.1: Criar Interface de Visualização de Status de Compartimentos
Descrição: Desenvolver a interface que exibe o status dos compartimentos.

RF2.3: Notificação de Erros

Como usuário,
Eu quero ser notificado sobre erros na máquina, como falhas no processo de preparo ou falhas técnicas,
Para que eu possa tomar as ações necessárias para resolver o problema ou buscar assistência.

Critérios de Aceitação:
  1. O sistema deve exibir uma notificação clara sempre que ocorrer um erro, como falha no preparo ou problemas técnicos.
  2. A notificação deve incluir uma descrição do erro, como "Falha no preparo da bebida" ou "Erro de conexão com a máquina".
  3. O usuário deve ser informado sobre o status da resolução do erro, como "Aguarde, estamos resolvendo o problema".

Exemplo:
  1. Durante o preparo, ocorre uma falha técnica na máquina.
  2. O sistema exibe uma notificação: "Erro: Falha na bomba de leite. Ação necessária."
  3. O usuário é informado de que a falha está sendo resolvida.

Tarefas Principais do Backend

O Backend será responsável por identificar erros técnicos ou falhas no processo de preparo e enviar notificações para o Frontend.

TB3.2.1: Criar Endpoint para Notificação de Erros
Descrição: Criar um endpoint para o Backend que receba e registre falhas técnicas ou de preparo. O endpoint deve ser capaz de enviar essas notificações ao Frontend em tempo real, com detalhes sobre o tipo de erro ocorrido.
Objetivo: Garantir que o sistema detecte erros no processo e envie informações sobre o erro (tipo de falha, descrição e possíveis ações corretivas) para o Frontend.
TB3.2.2: Implementar Lógica de Detecção de Erros
Descrição: Desenvolver a lógica no Backend que detecta falhas no processo de preparo ou falhas técnicas na máquina. A detecção pode envolver verificações em tempo real do sistema ou monitoramento de eventos específicos.
Objetivo: Garantir que o Backend consiga identificar automaticamente erros durante o preparo das bebidas ou falhas técnicas, acionando o envio das notificações de erro.

Tarefas Principais do Frontend

O Frontend será responsável por exibir as notificações de erro de forma clara e compreensível.

TF3.2.1: Criar Interface de Notificação de Erros
Descrição: Criar uma interface visual que exiba notificações de erro ao administrador. As notificações devem ser destacadas de forma clara e incluir detalhes sobre o erro (tipo de erro, mensagem explicativa e possíveis ações corretivas).
Objetivo: Garantir que o administrador consiga visualizar rapidamente qualquer falha na máquina ou no processo de preparo e compreenda as ações necessárias para resolver o problema.
TF3.2.2: Implementar Feedback Visual para Erros
Descrição: Adicionar elementos visuais (como cores, ícones ou alertas) para destacar as notificações de erro na interface, facilitando a identificação do problema pelo administrador.
Objetivo: Assegurar que as falhas sejam facilmente percebidas, com uma hierarquia visual que indique a gravidade do erro (ex: erro crítico, erro de preparo, erro técnico).
TF3.2.3: Exibir Histórico de Notificações de Erros
Descrição: Criar uma seção no painel do administrador onde ele pode consultar o histórico de erros passados, com informações sobre os problemas ocorridos e as ações corretivas tomadas.
Objetivo: Permitir que o administrador acompanhe os erros ao longo do tempo e verifique se ações corretivas foram realizadas para evitar a recorrência de falhas.

RF3.3: Cadastro de Líquidos

Como administrador,
  Eu quero cadastrar um líquido, sua quantidade e em qual compartimento ele está armazenado,
  Para que a API consiga devolver os resultados das bebidas cadastradas e eu possa visualizar na tela de status dos compartimentos.

Critérios de Aceitação:
  1. O sistema deve exibir um formulário para cadastro do líquido, da quantidade (em ml) e do compartimento onde será inserido.
  2. O status de cada compartimento de ingrediente líquido deve ser atualizado em tempo real, indicando se o compartimento está vazio ou com qual líquido está ocupado.

Exemplo:
  1. O administrador deseja colocar vodka na máquina. Ele acessa a tela de cadastro de líquidos e cadastra 1 litro de vodka no compartimento 1.
  2. O administrador deseja cadastrar gin na máquina. Ao escolher o compartimento, ele verifica que o compartimento 2 já está sendo utilizado para armazenar gin, então ele apenas reabastece.

Tarefas Principais do Backend

O Backend será responsável por garantir que os dados enviados pelo usuário sejam corretamente salvo.

TB3.3.1: Criar Endpoint para Cadastro do Líquido
Descrição: Criar um endpoint para o Backend que receba os dados do cadastro do líquido.
Objetivo: Garantir a integridade dos dados do formulário de cadastro de líquido.
TB3.3.2: Implementar Lógica de Cadastro de Líquidos
Descrição: Desenvolver a lógica para cadastro de líquidos que garante que os dados enviados pelo usuário sejam corretamente salvos no banco de dados.
Objetivo: Garantir que o líquido cadastrado pelo usário seja corretamente salvo no banco de dados.

Tarefas Principais do Frontend

O Frontend será responsável por exibir o formulário de cadastro de líquidos.

TF3.3.1: Criar Interface de Cadastro de Líquidos
Descrição: Criar uma interface visual que exiba um formulário para determinar qual líquido será utilizado, qual a quantidade e em qual compartimento ele será alocado.
Objetivo: Garantir que o administrador consiga cadastrar de forma facil e rapida o líquido que a maquina possui para a produção das bebidas.
TF3.3.2: Implementar Feedback Visual para Erros
Descrição: Adicionar elementos visuais (como cores, ícones ou alertas) para destacar as notificações de erro na interface, facilitando a identificação do problema pelo administrador.
Objetivo: Assegurar que as falhas sejam facilmente percebidas, com uma hierarquia visual que indique a gravidade do erro (ex: erro crítico, erro de preparo, erro técnico).
TF3.3.3: Implementar Feedback Visual sobre os status dos Compartimentos
Descrição: Adicionar um elemento visual que mostra se o compartimento já esta em uso ou se esta vazio.
Objetivo: Assegurar que o administrador não cadastre um líquido que já esta cadastrado ou que substitua o líquido errado.

Este épico tem como objetivo garantir que o administrador seja informado de forma clara sobre falhas técnicas ou no processo de preparo das bebidas. Com a criação de endpoints no Backend para detectar e enviar notificações e uma interface no Frontend para exibi-las, o administrador poderá identificar rapidamente problemas e tomar as ações necessárias para corrigir falhas, assegurando o bom funcionamento da máquina e a continuidade do serviço.

Além dos requisitos funcionais, alguns requisitos não funcionais foram definidos para a padronização da aplicação e cumprimento de pontos básicos da arquitetura e cumprimento de padrões de mercado.

Requisitos Não Funcionais (RNF)

Além dos requisitos funcionais, foram definidos alguns requisitos não funcionais (RNF) para garantir a padronização da aplicação, o cumprimento dos pontos fundamentais da arquitetura e a aderência a padrões de mercado amplamente reconhecidos. Esses requisitos são essenciais para assegurar que a aplicação seja robusta, escalável, segura e de fácil manutenção ao longo do tempo. A seguir, apresentamos os RNF organizados de acordo com as principais áreas de impacto.

1. Tecnologia de Backend (NestJS)

RNF1: A aplicação do lado do servidor será construída utilizando o framework NestJS, uma plataforma moderna e eficiente para a construção de APIs escaláveis.
RNF2: O NestJS deverá ser configurado para seguir a arquitetura modular, com módulos bem definidos, promovendo a reutilização e manutenção fácil do código.
RNF3: A aplicação backend deverá ser implementada utilizando TypeScript, aproveitando suas vantagens de tipagem estática e autocompletar para maior robustez no desenvolvimento.

2. Tecnologia de Frontend (React com TypeScript)

RNF4: O frontend da aplicação será desenvolvido utilizando React com TypeScript, garantindo que o código seja fortemente tipado e fácil de manter.
RNF5: A aplicação frontend deverá ser totalmente responsiva, utilizando CSS-in-JS ou frameworks como Material-UI ou TailwindCSS, garantindo uma boa experiência de usuário em diferentes dispositivos.

3. Banco de Dados (PostgreSQL)

RNF6: O banco de dados será PostgreSQL, escolhido por sua robustez, escalabilidade e conformidade com transações ACID.
RNF7: O sistema deverá garantir que o PostgreSQL seja configurado para operações de leitura e escrita com alto desempenho, utilizando índices e boas práticas de modelagem de dados.

4. Protocolos de Comunicação (MQTT)

RNF8: A comunicação entre a aplicação e o firmware dos dispositivos será realizada utilizando o protocolo MQTT, para garantir comunicação eficiente em tempo real.

5. Compatibilidade e Integração

RNF9: A aplicação frontend será compatível com os dispositivos móveis e tablets, utilizando abordagens responsivas e frameworks como TailwindCSS ou Material-UI para garantir uma boa interface de usuário em diferentes telas.

Storymap

No contexto do Scrum, o termo Storymap refere-se a uma técnica visual utilizada para mapear e organizar as histórias de usuário, facilitando a compreensão das prioridades e da sequência de trabalho a ser realizada ao longo de um projeto. O Story Mapping Scrum é uma abordagem eficaz para planejar e estruturar as funcionalidades ou requisitos de um produto, permitindo que a equipe visualize de forma clara o fluxo de trabalho e organize o desenvolvimento de maneira incremental.

Com base nessa introdução, o diagrama a seguir ilustra a organização do projeto, destacando os épicos, requisitos e tasks, e como essas tasks estão interconectadas. Ele ajuda a equipe a entender como as atividades se relacionam entre si, proporcionando uma visão clara das dependências e facilitando o planejamento e a execução eficiente do projeto.


Versão em PDF do StoryMap

Roadmap

A partir dos requisitos e tarefas descritos acima, foram definidos milestones para organizar e estruturar o desenvolvimento do projeto. Dentro de cada milestone, foram criadas issues no GitLab, com o objetivo de facilitar o acompanhamento, gerenciamento e execução das atividades, garantindo maior transparência e controle sobre o progresso do produto. Esse processo permite que a equipe tenha uma visão clara das entregas, prazos e responsabilidades, além de possibilitar a priorização de tarefas e a identificação de possíveis bloqueios ou atrasos no desenvolvimento.

Referências

PEREIRA, P.; TORREÃO, P.; MARÇAL, A. S. Entendendo Scrum para gerenciar projetos de forma ágil. Mundo PM, v. 1, p. 3-11, 2007.

Tabela de versionamento

Versão	Data	Descrição	Responsável
1.0	13/11/2024	Criação do Documento, Descrição de Épicos e Requisitos	Guilherme Brito
1.1	22/11/2024	Revisão do documento	Nicolas