Parcial 1 do trabalho

Cada aluno deve montar uma dupla e escolher um dos módulos abaixo para entregar as telas feitas em JavaFX até o dia 10/02/2026.

Ao aceitar a tarefa, cada dupla deve criar uma equipe com o nome do sistema e do módulo escolhido, conforme o exemplo:

Sistema1-Logistica-Modulo1

Não deve haver mais de uma equipe para o mesmo módulo.

Divisão dos módulos dos sistemas

Descrição dos Sistemas	Modulos
Sistema1-Logistica	Modulo - 1 Modulo - 2 Modulo - 3 Modulo - 4 Modulo - 5
Sistema2-RastreamentoTR	Modulo - 1 Modulo - 2 Modulo - 3 Modulo - 4
Sistema3-AdaptaCommerce	Modulo - 1 Modulo - 2 Modulo - 3 Modulo - 4 Modulo - 5 Modulo - 6
Sistema4-SAJDrive	Modulo - 1 Modulo - 2 Modulo - 3 Modulo - 4

Sistema1-Logistica

Módulo 1: Gestão de Acessos e Cadastros Essenciais

Descrição

Este módulo é o coração do sistema de logística, responsável pelo controle de acesso, gerenciamento de usuários e pelo cadastro das entidades essenciais para o funcionamento da plataforma. A equipe de desenvolvimento deverá implementar as funcionalidades que garantem a segurança e a integridade dos dados, além de criar a base para o registro de clientes e parceiros.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

1. Autenticação e Controle de Acesso

• 1.1. Autenticação de login e senha: O sistema deve exigir que todos os usuários se autentiquem com login and senha antes de acessar qualquer funcionalidade. (Citação: "O Sistema deve solicitar autenticação de login e senha, antes que seja possível realizar acesso, toda e qualquer funcionalidade do sistema só será possível após a autenticação.")
• 1.21. Controle de Acesso por Nível de Permissão: Implementar um sistema de permissões baseado em perfis específicos para logística (ex: Motorista, Ajudante, Supervisor de Frota, Gestor de Logística, Administrador), onde cada perfil tem acesso a funcionalidades específicas. O administrador deve poder ajustar as permissões dos perfis, e todas as alterações devem ser registradas em um log de auditoria. (Citação: "O sistema deve permitir criar diferentes níveis de permissão... Cada nível deve ter acesso apenas às funcionalidades autorizadas... As permissões devem poder ser ajustadas pelo administrador... Toda alteração de permissão deve ser registrada no log de auditoria.")
• 1.27. Geração de senha temporária para acesso: Criar uma funcionalidade que permita ao usuário solicitar uma senha temporária, que será enviada por e-mail ou SMS. (Citação: "O sistema deve gerar uma senha de acesso ao usuário solicitante, um e-mail/sms deve ser enviado ao usuário contendo a senha de acesso.")
• 1.30. Auditoria de Ações de Usuários: Registrar um log detalhado de todas as ações críticas realizadas pelos usuários, como exclusões ou alterações manuais de dados sensíveis. O log deve incluir usuário, data, hora e descrição da ação. (Citação: "O sistema deve registrar um log completo de todas as ações críticas realizadas pelos usuários...")

2. Cadastros Essenciais

• 1.4. Cadastro de Clientes e Endereços de Entrega: Desenvolver a funcionalidade de cadastro de clientes (pessoa física, jurídica ou estrangeiro), garantindo que informações como nome/razão social, CPF/CNPJ (único), endereço, telefone e e-mail sejam obrigatórios e validados. (Citação: "O tipo de cliente... deve ser informado... O nome ou razão social é obrigatório... O CPF ou CNPJ deve ser válido e único no sistema... O endereço de entrega deve conter rua, número, cidade, estado e CEP válidos... O telefone e o e-mail devem ser informados e estar em formato correto.")
• 1.24. Cadastro de Transportadoras Parceiras: Criar uma seção no sistema para armazenar e exibir informações de empresas parceiras de transporte, incluindo nome/razão social, CNPJ, telefone, localização, e-mail e tipos de veículos disponíveis. (Citação: "O sistema deverá possuir uma aba onde estejam localizadas as informações das empresas parceiras...")

Requisitos Não Funcionais a Considerar

• Segurança: Todos os dados sensíveis devem ser criptografados (2.3).
• Disponibilidade: O sistema deve ter alta disponibilidade (2.1).
• LGPD: Garantir a conformidade com a Lei Geral de Proteção de Dados (2.4).
• Logs: Geração de logs para monitoramento da saúde do sistema (2.9).

Módulo 2: Gestão de Frota e Colaboradores (Motoristas e Ajudantes)

Descrição

Este módulo é focado no gerenciamento completo da frota de veículos e dos colaboradores que atuam nas entregas (motoristas e ajudantes). A equipe de desenvolvimento será responsável por criar as funcionalidades para cadastrar, controlar e monitorar todos os ativos e pessoal envolvidos no transporte.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

1. Cadastro e Controle de Veículos

• 1.2. Cadastro de veículos: Implementar a funcionalidade de cadastro de veículos, com validações estritas para os campos.
  • Placa: Obrigatória e no formato Mercosul (ABC1D23). (Citação: "A placa é obrigatória e deve seguir o exemplo correto exemplo (ABC1D23)")
  • Modelo: Obrigatório, com no mínimo 2 caracteres. (Citação: "O modelo é obrigatório e deve conter pelo menos 2 carácteres")
  • Capacidade: Capacidade máxima em kg, deve ser maior que 0. (Citação: "Qual a capacidade máxima de kg, tem que ser maior que 0")
  • Data de Fabricação: Deve ser entre o ano 2000 e o ano atual. (Citação: "Data de fabricação deve ser entre 2000 a ano atual")
• 1.20. Registro de abastecimentos e consumo de combustível: Permitir que motoristas registrem os abastecimentos realizados e gerar relatórios de consumo mensal por veículo/motorista. (Citação: "O Motorista deve registar no sistema, os abastecimentos realizados. O Sistema poderá gerar relatórios para que seja possível acompanhar o consumo mensal de cada veículo/motorista.")
• 1.26. Bloqueio de veículo em rota/ação não autorizada: Implementar uma funcionalidade crítica de segurança que permita o bloqueio imediato de um veículo em caso de desvio de rota ou outra ação não autorizada, exigindo a intervenção de um supervisor para desbloqueio com justificativa. (Citação: "Bloqueia imediatamente o veículo em caso de rota ou ação não autorizada, exigindo intervenção de supervisor com justificativa obrigatória.")

2. Cadastro e Gestão de Colaboradores

• 1.3. Cadastro de motoristas e ajudantes: Desenvolver a funcionalidade de cadastro de motoristas e ajudantes, com as seguintes regras:
  • Nome: Obrigatório, com no mínimo 2 letras. (Citação: "Nome é obrigatório e deve conter pelo menos 2 letras")
  • CPF: Válido e único no sistema. (Citação: "O CPF deve ser válido e único no sistema")
  • Telefone: Obrigatório, no formato correto com DDD. (Citação: "Telefone é obrigatório e deve esta no formato correto incluindo DDD")
  • Função: Deve indicar se é "motorista" ou "ajudante". (Citação: "O campo função deve indicar se é motorista ou ajudante")
  • CNH (para motoristas): Se a função for "motorista", o sistema deve exigir os dados da CNH (número, categoria e data de vencimento válida). (Citação: "Se for motorista deve conter uma carteira de habilitação básica, com número, categoria e data de vencimento posterior a data atual")
  • Status: Deve indicar se o colaborador está "disponível", "em viagem" ou "afastado". (Citação: "O status deve indicar se a pessoa está disponível em viagem ou afastada")

Requisitos Não Funcionais a Considerar

• Segurança: Dados sensíveis como CPF e CNH devem ser criptografados (2.3).
• Integridade dos Dados: O sistema deve garantir a consistência das informações, especialmente o status de disponibilidade dos motoristas e veículos (2.7).
• Usabilidade: O formulário de cadastro deve ser intuitivo e com mensagens de erro claras.

Módulo 3: Gestão de Cargas e Estoque

Descrição

Este módulo é central para o controle de mercadorias dentro do sistema de logística. A equipe será responsável por desenvolver as funcionalidades que permitem o cadastro de produtos (cargas), a gestão do estoque, o tratamento de devoluções e perdas, e o processo de recebimento e despacho de mercadorias.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

1. Cadastro de Produtos (Cargas)

• 1.5. Cadastro de produtos: Desenvolver a interface para cadastro de novos produtos com as seguintes regras e validações:
  • Nome: Campo obrigatório. (Citação: "O nome do produto é obrigatório")
  • Peso e Volume: Devem ser valores maiores que zero, pois são essenciais para o planejamento da carga do veículo. O sistema deve emitir um alerta se os valores excederem limites pré-definidos. (Citação: "O peso e o volume devem ser maiores que zero... Produtos com peso e volume acima dos limites devem gerar alerta")
  • Categoria: A categoria do produto deve ser selecionada a partir de uma lista de opções pré-cadastradas (ex: Frágil, Perigoso, Perecível). (Citação: "A categoria do produto deve ser selecionada entre as opções disponíveis")
  • Duplicidade: O sistema não deve permitir o cadastro de produtos duplicados. (Citação: "Não é permitido cadastrar produtos duplicados")

2. Gestão de Estoque e Movimentações

• 1.15. Registro de devoluções de produtos: Implementar a funcionalidade para registrar devoluções, incluindo data, motivo e o responsável pelo recebimento. A devolução deve atualizar o estoque e o status do pedido automaticamente. Permitir anexar observações e fotos dos produtos devolvidos. (Citação: "O sistema deve permitir o registro de devoluções com data, motivo e responsável pelo recebimento. As devoluções devem atualizar automaticamente o estoque e o status do pedido.")
• 1.16. Registro de perdas ou baixas de produtos: Criar uma funcionalidade para registrar a baixa de produtos por motivos como avaria, vencimento, extravio ou erro de armazenamento. (Citação: "O Sistema deve permitir o registro de perda de produtos causadas por: avarias, vencimento, extravio ou erro de armazenamento.")
• 1.17. Recebimento e Programação de Entregas: Desenvolver um mecanismo para importar ou registrar pedidos de entrega. O sistema deve validar se os clientes e produtos do pedido já existem no banco de dados. Pedidos com dados inválidos devem gerar um erro, enquanto pedidos válidos são adicionados a uma fila para programação de entrega. (Citação: "O Sistema deve verificar se os produtos e os clientes já existem no banco de dados, caso não haja registro, deverá exibir uma mensagem de erro, pedidos válidos serão adicionados à fila, para a programação da entrega.")
• 1.22. Emissão de relatório do estoque: Criar uma funcionalidade para gerar relatórios da quantidade de produtos em estoque. O relatório deve ser exportável em PDF e permitir filtros por categoria, nome do produto ou período. (Citação: "Relatório de quantidade de produtos no estoque, o sistema pode gerar um arquivo pdf do relatório.")

Requisitos Não Funcionais a Considerar

• Performance: A consulta de produtos e a geração de relatórios de estoque devem ser rápidas (2.2).
• Integridade dos Dados: As atualizações de estoque (entradas, saídas, devoluções, perdas) devem ser transacionais para garantir a consistência dos dados (2.7).
• Escalabilidade: A estrutura do banco de dados de produtos e estoque deve ser projetada para suportar um grande volume de itens (2.10).

Módulo 4: Planejamento e Execução de Rotas

Descrição

Este é um dos módulos mais complexos e dinâmicos do sistema. A equipe será responsável por desenvolver toda a lógica de criação, otimização, e monitoramento de rotas de entrega. O objetivo é garantir que as entregas sejam planejadas da forma mais eficiente possível, com capacidade de adaptação em tempo real.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

1. Criação e Gerenciamento de Rotas

• 1.6. Cadastro de rotas de entrega: Permitir o cadastro de rotas com origem, destino e pontos intermediários. O sistema deve calcular automaticamente a distância total e o tempo estimado. É mandatório que uma rota tenha um veículo e um motorista associados. (Citação: "A origem e destino da rota devem ser informados... Os pontos intermediários devem ter endereços válidos. Não é possível cadastrar rota sem veículo ou motorista associado. À distância total e o tempo estimado devem ser calculados automaticamente.")
• 1.7. Geração automática de rotas: Desenvolver um algoritmo para a geração automática de viagens, considerando:
  • Disponibilidade: A viagem deve ter um cliente, um veículo disponível e um motorista disponível.
  • Capacidade: A soma do peso e volume dos produtos deve ser compatível com a capacidade do veículo.
  • Custo: O custo da viagem (baseado em distância, pedágios e combustível) deve ser calculado automaticamente.
  • Validação: O sistema deve impedir o início de uma viagem se houver inconsistências. (Citação: "A viagem deve incluir obrigatoriamente um cliente, um veículo disponível e pelo menos um motorista com status disponível... A lista de produtos deve conter itens cadastrados, com soma de peso e volume compatível com a capacidade do veículo...")
• 1.8. Edição de rotas por um supervisor: Permitir que apenas usuários com perfil de "supervisor" possam alterar o trajeto, veículo ou motorista de uma rota. Toda modificação exige uma justificativa obrigatória. (Citação: "Permitir apenas supervisores alterar trajeto, pontos intermediários, veículo ou motorista. Exigir justificativa obrigatória para modificações")

2. Otimização e Monitoramento em Tempo Real

• 1.9. Cálculo do tempo estimado de entrega: O sistema deve calcular o tempo de entrega com base na distância e nas condições de trânsito em tempo real. Este tempo deve ser atualizado dinamicamente. (Citação: "O sistema deve calcular automaticamente o tempo estimado de entrega considerando a distância total da rota e as condições atuais de trânsito. O tempo estimado deve ser atualizado em tempo real...")
• 1.10. Visualização de rotas no mapa: Exibir a rota planejada em um mapa interativo, mostrando origem, destino, pontos intermediários e a posição do veículo em tempo real com função de zoom. (Citação: "O sistema deve exibir a rota planejada em um mapa interativo... incluir origem, destino e pontos intermediários... visualizar o progresso do veículo em tempo real e ter a possibilidade de aplicar zoom.")
• 1.11. Recálculo de rotas em tempo real: Em caso de imprevistos (bloqueios, acidentes), o sistema deve recalcular a rota automaticamente e sugerir a alteração ao motorista, justificando a mudança e informando o novo tempo de chegada. (Citação: "O sistema deve recalcular automaticamente a rota em caso de bloqueios, acidentes ou alterações no trânsito. A possibilidade de uma nova rota deve aparecer para o usuário...")
• 1.29. Geração de Alertas de Desvio de Rota: Emitir um alerta automático para o supervisor se um veículo se desviar significativamente da rota planejada ou exceder o tempo de parada permitido. (Citação: "O sistema deve emitir um alerta automático para o supervisor caso o veículo saia significativamente da rota planejada...")

Requisitos Não Funcionais a Considerar

• Performance: O cálculo e recálculo de rotas, bem como a atualização em tempo real no mapa, devem ter um tempo de resposta mínimo (2.2).
• Integração: Será necessária a integração com uma API de mapas e trânsito em tempo real (ex: Google Maps, Waze API).
• Disponibilidade: A funcionalidade de rastreamento e recálculo de rota é crítica e deve estar sempre disponível (2.1, 2.7).
• Usabilidade (App do Motorista): A interface no aplicativo do motorista para visualização de rota e aceitação de novos trajetos deve ser clara, simples e segura para uso durante a condução.

Módulo 5: Acompanhamento e Finalização de Entregas

Descrição

Este módulo foca no processo final da cadeia logística: a entrega do produto ao cliente. A equipe será responsável por implementar funcionalidades que permitam o acompanhamento do status da entrega, a confirmação do recebimento, a gestão de incidentes e a comunicação com o cliente e outros setores da empresa.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

1. Rastreamento e Status da Entrega

• 1.12. Registro do status das entregas: O sistema deve permitir o acompanhamento do status de cada entrega (ex: "em andamento", "concluída", "cancelada"). O status deve ser atualizado automaticamente, mas também permitir alteração manual por usuários autorizados, registrando data e hora de cada mudança. (Citação: "Cada entrega deve possuir um status atualizado automaticamente conforme o progresso. O status pode ser alterado manualmente por usuários com permissão...")
• 1.18. Atualização do status de pedidos conforme a entrega é realizada: O motorista deve registrar no sistema a data e o horário em que a entrega foi efetuada. (Citação: "O Motorista/Entregador deve registrar no sistema, a data e horário que foi efetuada a entrega do produto.")
• 1.19. Emissão de notificações ao setor de vendas sobre entregas: O setor de vendas e o cliente devem ser notificados sobre mudanças importantes no status do pedido, de forma similar a aplicativos de entrega de comida. (Citação: "O setor de vendas e o cliente devem ser notificados sobre mudanças relevantes no status do pedido (semelhante ao iFood, por exemplo).")

2. Confirmação e Pós-Entrega

• 1.13. Confirmação de entrega via assinatura digital ou código: A entrega só pode ser finalizada com a confirmação do cliente, seja por assinatura digital na tela do dispositivo ou pela inserção de um código de segurança. Um comprovante eletrônico deve ser gerado e armazenado. (Citação: "O cliente deve confirmar a entrega por meio de assinatura digital ou inserção de um código de confirmação. A confirmação deve gerar um comprovante eletrônico armazenado no sistema.")
• 1.14. Geração de relatórios de entregas: Criar um gerador de relatórios de entregas que possa ser filtrado por período, motorista e status. Os relatórios devem conter métricas como quantidade de entregas, distância percorrida e tempo médio. A exportação em PDF e Excel deve ser possível para usuários autorizados. (Citação: "O sistema deve gerar relatórios de entregas com filtros por período, motorista e status... Deve ser possível exportar os relatórios em formato PDF e Excel.")
• 1.23. Possibilidade de reprogramar a data de entrega em caso de falha: Se uma entrega falhar, o cliente deve ser notificado e ter a opção de reagendar a entrega para uma nova data. (Citação: "Caso haja algum imprevisto que resulte em uma falha na entrega do produto, o cliente receberá uma notificação com opção para programar a data de uma próxima entrega.")

3. Gestão de Incidentes

• 1.25. Registro e categorização de incidentes: Permitir o registro de incidentes que podem ocorrer durante a entrega, como avaria, extravio, roubo, atraso significativo, recusa de entrega ou erro de endereço. (Citação: "Registro e categorização de incidentes: Avaria, extravio, roubo, atraso > 2h, recusa de entrega, erro de endereço")
• 1.28. Registro fotográfico de danos: Em caso de avaria, o sistema deve exigir que o motorista anexe uma foto do produto danificado no local. As fotos devem ser associadas ao pedido e validadas quanto ao formato. (Citação: "O sistema deve exigir que o motorista anexe uma foto do produto no local... fotos devem ser veiculadas a o pedido do produto...")

Requisitos Não Funcionais a Considerar

• Disponibilidade: A funcionalidade de confirmação de entrega e registro de status é crítica para a operação e deve estar sempre disponível (2.1).
• Usabilidade (App do Motorista): A interface para o motorista deve ser extremamente simples para registrar a entrega, coletar a assinatura ou código, e registrar incidentes.
• Responsividade (Cliente): A interface de notificação e reagendamento para o cliente deve ser amigável e funcionar bem em dispositivos móveis.
• Segurança: A assinatura digital e os dados do cliente devem ser armazenados de forma segura (2.3).

Sistema2-RastreamentoTR

Módulo 1: Gerenciamento de Contas e Perfil

Descrição

Este módulo é a porta de entrada para o aplicativo de transporte público. A equipe será responsável por implementar todo o ciclo de vida do usuário, desde o cadastro inicial até a gestão de seu perfil. O foco é criar um processo de autenticação seguro e uma experiência de usuário fluida.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

• RF01: Cadastro de Usuário: Permitir que novos usuários se cadastrem na plataforma fornecendo e-mail (com suporte a contas existentes como Gmail ou Apple ID), senha e nome de usuário. (Citação: "O sistema deve permitir que novos usuários realizem seu cadastro na plataforma, fornecendo as informações necessárias: e-mail (que pode ser um já existente como Gmail, ou Apple ID), senha e nome de usuário.")
• RF02: Autenticação de Usuário: Implementar as funcionalidades de login, para que um usuário acesse sua conta, e logout, para encerrar a sessão de forma segura. (Citação: "O sistema deve possibilitar que um usuário cadastrado realize login... e logout...")
• RF03: Recuperação de Senha: Oferecer uma opção de "Esqueci minha senha" que envie um código de verificação para o e-mail do usuário. Ao informar o código no aplicativo, o usuário será direcionado para uma tela de redefinição de senha. (Citação: "O sistema deve oferecer uma opção de 'Esqueci minha senha', permitindo que o usuário redefina sua senha por meio de um código enviado ao e-mail cadastrado...")
• RF04: Edição de Perfil: Criar uma área de perfil onde o usuário possa visualizar e editar suas informações pessoais cadastradas, como nome de usuário e e-mail. (Citação: "O sistema deve permitir que o usuário acesse uma área de perfil onde possa visualizar editar suas informações pessoais cadastradas.")

Requisitos Não Funcionais a Considerar

• Segurança e Privacidade (RNF04): Todos os dados do usuário, especialmente a senha, devem ser armazenados de forma criptografada. O processo de recuperação de senha deve ser seguro para evitar acesso não autorizado.
• Usabilidade (RNF05): A interface de cadastro, login e edição de perfil deve ser intuitiva e de fácil utilização.
• Conectividade (RNF06): As funcionalidades devem operar de forma consistente em diferentes condições de rede (3G, 4G, 5G, Wi-Fi).
• Armazenamento (RNF09): As informações dos usuários devem ser armazenadas em uma infraestrutura de nuvem com políticas de backup.

Módulo 2: Consulta de Rotas e Horários

Descrição

Este módulo constitui o núcleo informativo do aplicativo, permitindo aos usuários planejar suas viagens. A equipe será responsável por desenvolver as funcionalidades que exibem informações sobre linhas de ônibus, horários, trajetos e tarifas, garantindo que os dados sejam claros e acessíveis.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

• RF05: Listagem de Linhas: O aplicativo deve exibir uma lista completa de todas as linhas de ônibus disponíveis no sistema. (Citação: "O aplicativo deve ser capaz de exibir uma lista completa de todas as linhas de ônibus disponíveis no sistema...")
• RF06: Consulta de Horários: Para uma linha selecionada, o aplicativo deve apresentar os horários programados de saída e chegada dos ônibus. (Citação: "O aplicativo deve apresentar os horários programados de saída e chegada dos ônibus para uma linha selecionada.")
• RF07: Planejamento de Rota (Pesquisa de Destino): Permitir que o usuário pesquise um destino por endereço. O sistema, então, deve calcular e sugerir as rotas de transporte público disponíveis para chegar a esse destino. (Citação: "O aplicativo deve permitir que o usuário pesquise um destino por endereço e o sistema deve calcular e sugerir as rotas de transporte público disponíveis.")
• RF08: Detalhamento de Trajeto: Ao selecionar uma linha específica, o aplicativo deve exibir um mapa ou uma lista de todas as paradas existentes ao longo do seu trajeto. (Citação: "Ao selecionar uma linha, o aplicativo deve exibir todas as paradas existentes ao longo do seu trajeto.")
• RF09: Filtro de Acessibilidade: Implementar um filtro que permita ao usuário visualizar apenas as linhas ou veículos que oferecem recursos de acessibilidade, como elevadores para cadeirantes. (Citação: "O aplicativo deve permitir a filtragem de linhas ou veículos que possuam recursos de acessibilidade...")
• RF10: Calculadora de Tarifas: Fornecer uma funcionalidade que exibe o valor atual da passagem e mantém o usuário informado sobre aumentos, atualizando o valor com base em decretos da legislação vigente. (Citação: "O aplicativo deve fornecer uma funcionalidade de calculadora de tarifas que exibe o valor atual da passagem e informa sobre eventuais aumentos...")

Requisitos Não Funcionais a Considerar

• Desempenho (RNF01): As consultas de rotas e horários devem ter um tempo de resposta inferior a 1 segundo.
• Usabilidade (RNF05): A apresentação das informações de rotas, paradas e horários deve ser clara e fácil de entender.
• Disponibilidade (RNF02): O serviço de consulta deve estar disponível 24/7.
• Manutenibilidade (RNF08): O banco de dados de rotas, horários e tarifas deve ser facilmente atualizável pela equipe administrativa.

Módulo 3: Mapa e Rastreamento em Tempo Real

Descrição

Este módulo é responsável pela funcionalidade mais dinâmica e interativa do aplicativo: o rastreamento de ônibus em tempo real. A equipe irá desenvolver a integração com mapas e GPS para fornecer aos usuários informações precisas sobre a localização dos veículos, horários de chegada e pontos de ônibus próximos.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

• RF11: Rastreamento de Veículos: Exibir a localização dos ônibus em tempo real em um mapa interativo. O sistema deve buscar a localização dos veículos através de uma API fornecida pela empresa de ônibus. (Citação: "O aplicativo deve exibir a localização dos ônibus em tempo real no mapa, permitindo ao usuário acompanhar o deslocamento do veículo por meio de uma API que busca a localização dos veículos cadastrados na empresa fornecedora do ônibus.")
• RF12: Pontos Próximos: Utilizar a geolocalização (GPS) do dispositivo do usuário para identificar e exibir no mapa os pontos de ônibus mais próximos a ele. (Citação: "O aplicativo deve usar a geolocalização (GPS) do usuário para identificar e mostrar os pontos de ônibus mais próximos.")
• RF13: Atualização Dinâmica de Horários: Com base na localização do usuário e nos dados de trânsito em tempo real, o sistema deve simular e atualizar automaticamente os horários de chegada dos ônibus, informando sobre possíveis atrasos. (Citação: "O aplicativo deve simular e atualizar automaticamente os horários de chegada e as rotas com base em dados em tempo real, informando atrasos...")
• RF14: Compartilhamento de Viagem: Permitir que o usuário compartilhe sua localização em tempo real com outras pessoas durante o trajeto da sua viagem. (Citação: "O aplicativo deve permitir que o usuário compartilhe sua localização em tempo real (durante a viagem) com outras pessoas.")

Requisitos Não Funcionais a Considerar

• Desempenho (RNF01): A atualização da posição dos veículos no mapa e o cálculo de horários devem ser extremamente rápidos, com tempo de resposta inferior a 1 segundo.
• Conectividade (RNF06): O rastreamento deve funcionar de forma estável em diferentes qualidades de conexão de rede (3G, 4G, 5G). O aplicativo deve lidar de forma inteligente com perdas momentâneas de conexão.
• Escalabilidade (RNF07): A arquitetura deve suportar um grande número de usuários (mínimo de 5.000) acessando o serviço de rastreamento simultaneamente.
• Segurança e Privacidade (RNF04): O compartilhamento de localização só pode ser iniciado pelo usuário e deve ser fácil de interromper. O acesso à localização do usuário deve ser solicitado e justificado claramente.
• Compatibilidade (RNF03): Garantir que a integração com os serviços de GPS e mapas funcione corretamente em Android e iOS.

Módulo 4: Personalização e Histórico

Descrição

Este módulo visa aprimorar a experiência do usuário, permitindo que ele personalize o aplicativo de acordo com suas necessidades e acesse facilmente informações recorrentes. A equipe será responsável por implementar funcionalidades de favoritos e histórico de viagens.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

• RF15: Linhas Favoritas: Implementar uma funcionalidade que permita ao usuário marcar linhas de ônibus e rotas como "favoritas". Deve haver uma seção de fácil acesso no aplicativo para listar essas rotas favoritas, agilizando consultas futuras. (Citação: "O aplicativo deve permitir que o usuário marque linhas e rotas como 'favoritas' para acesso rápido.")
• RF16: Histórico de Rotas: O aplicativo deve registrar automaticamente e exibir um histórico das rotas que o usuário pesquisou ou utilizou recentemente. Isso permite que o usuário refaça uma busca ou consulta de forma rápida, sem precisar inserir os dados novamente. (Citação: "O aplicativo deve registrar e exibir um histórico das rotas recentemente utilizadas ou pesquisadas pelo usuário.")

Requisitos Não Funcionais a Considerar

• Usabilidade (RNF05): As ações de favoritar uma linha e acessar o histórico devem ser simples e intuitivas, integradas de forma natural à interface principal.
• Armazenamento (RNF09): Os dados de favoritos e histórico são específicos de cada usuário e devem ser armazenados de forma segura na nuvem, associados à conta do usuário.
• Manutenibilidade (RNF08): As atualizações do aplicativo não devem apagar os dados de favoritos e histórico do usuário. O sistema deve garantir que esses dados persistam entre as versões.
• Responsividade (RNF10): A exibição do histórico e das linhas favoritas deve se adaptar a diferentes tamanhos de tela, como smartphones e tablets.

Sistema3-AdaptaCommerce

Módulo 1: Gestão de Usuários e Acessos

Descrição

Este módulo é o alicerce da segurança e da administração do sistema AdaptaCommerce. A equipe será responsável por implementar o fluxo de inicialização do sistema, o cadastro de usuários, a autenticação e o sistema de permissões, garantindo que apenas usuários autorizados acessem as funcionalidades corretas.

Requisitos Funcionais Essenciais

A equipe deve desenvolver as seguintes funcionalidades, todas com prioridade Essencial:

• [RF001] Validação de Chave de Desenvolvedor para Login: Antes de permitir o cadastro do primeiro usuário, o sistema deve exigir a inserção de uma chave de desenvolvedor secreta. Esta chave deve ser armazenada de forma segura no código-fonte ou em um arquivo de configuração protegido. (Citação: "O sistema deve exigir a inserção de uma chave de desenvolvedor, armazenada em uma área privada do código-fonte ou arquivo de configuração protegido, antes de permitir o cadastro do primeiro usuário.")
• [RF002] Usuário Administrador Inicial: O primeiro usuário criado no sistema (após a validação da chave de desenvolvedor) deve ser automaticamente reconhecido como "Administrador", com plenos poderes. O login deste usuário será feito com nome e senha pré-definidos pelo desenvolvedor. (Citação: "O sistema deve reconhecer o primeiro usuário criado como Administrador, login mediante fornecimento de nome e senha previamente definidos pelo Desenvolvedor.")
• [RF003] Cadastro de Usuários: O administrador deve ter a capacidade de cadastrar novos usuários. Para cada novo usuário, o administrador definirá sua função (ex: Vendedor, Financeiro), um ID único e uma senha que atenda aos critérios de segurança (mínimo de 8 caracteres, iniciar com maiúscula, conter caractere especial). (Citação: "O sistema deve permitir que o administrador cadastre novos usuários, definindo suas funções, ID e senhas de acesso.")
• [RF004] Login: Implementar a tela de login onde os usuários se autenticam com ID e senha. O sistema deve bloquear automaticamente um usuário após 5 tentativas de login inválidas. (Citação: "O sistema deve permitir a autenticação de usuários com base em ID e senha. Além disso, deve bloquear automaticamente usuários com mais de 5 tentativas de login inválidas.")
• [RF005] Permissões de Usuários: Criar um sistema de controle de acesso baseado em funções (Administrador, Vendedor, Financeiro, Estoquista). Cada função terá acesso a um conjunto específico de funcionalidades. Apenas o Administrador pode alterar as permissões de outros usuários. (Citação: "O sistema deve oferecer níveis de acesso diferenciados... com base na sua respectiva função... Alterações de permissões só devem ser realizadas pelo usuário Administrador.")
• [RF027] Auditoria de usuários: O sistema deve registrar automaticamente a data, a hora e qual usuário Administrador realizou o cadastro de um novo usuário. (Citação: "O sistema deve ser capaz de salvar automaticamente a data e hora do cadastro de usuários, além do usuário ADM que realizou o cadastro.")

Requisitos Não Funcionais a Considerar

• Segurança (RNF003): A autenticação deve ser implementada via token JWT. Todas as senhas devem ser armazenadas com proteção de hash.
• Conformidade (RNF008): O tratamento de dados dos usuários deve seguir as normas da LGPD.
• Integridade (RNF009): O sistema deve validar todos os dados inseridos para prevenir inconsistências, especialmente a unicidade do ID de usuário.
• Usabilidade (RNF004): A interface de login e cadastro de usuários deve ser clara e intuitiva.

Módulo 2: Gestão de Cadastros (Clientes e Fornecedores)

Descrição

Este módulo é responsável pelo cadastro e gerenciamento das entidades fundamentais do negócio: clientes e fornecedores. A equipe deverá criar interfaces de cadastro robustas, com validações de dados rigorosas e funcionalidades de consulta que facilitem a operação diária do sistema.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades:

Essenciais

• [RF006] Cadastro de Fornecedores: Permitir o cadastro de novos fornecedores com campos obrigatórios como Nome, CNPJ, Inscrição Estadual (IE) e endereço completo. O sistema deve validar o formato do CNPJ (14 dígitos), IE, CEP (8 dígitos) e outros campos. (Citação: "O sistema deve permitir que o usuário com as devidas permissões cadastrem novos fornecedores... CNPJ: deve conter 14 dígitos numéricos válidos... CEP: deve ter 8 dígitos...")
• [RF008] Cadastro de Clientes: Implementar o cadastro de clientes, diferenciando entre Pessoa Física (PF), Pessoa Jurídica (PJ) e "Outros". CPF/CNPJ são obrigatórios e devem ser únicos e válidos. Clientes "Outros" devem fornecer um documento alternativo. (Citação: "O sistema deve permitir que os usuários com as devidas permissões cadastrem novos clientes, sendo separado em três tipos de clientes:PF,PJ e Outros...")

Importantes

• [RF013] Consulta de Fornecedor: Permitir a consulta de fornecedores cadastrados, exibindo seus dados, pedidos em aberto e histórico de mercadorias. (Citação: "O sistema poderá permitir que os usuários com as devidas permissões consultem os fornecedores cadastrados.")
• [RF015] Consulta via CEP: Integrar o sistema a um serviço de consulta de CEP. Ao informar um CEP válido nos formulários de cliente ou fornecedor, os campos de endereço (Logradouro, Bairro, Cidade, Estado) devem ser preenchidos automaticamente. (Citação: "O sistema deve permitir que os usuários com as devidas permissões realizem consultas de endereço por meio do CEP, retornando automaticamente as seguintes informações...")

Requisitos Não Funcionais a Considerar

• Integridade (RNF009): Garantir a validação rigorosa de todos os dados de entrada para evitar inconsistências, como CPFs/CNPJs duplicados ou inválidos.
• Desempenho (RNF002): As consultas de fornecedores devem ter um tempo de resposta inferior a dois segundos.
• Usabilidade (RNF004): Os formulários de cadastro devem ser intuitivos, com mensagens de erro claras para o usuário.
• Portabilidade (RNF007): O sistema deve funcionar corretamente nos principais sistemas operacionais (Windows, macOS, Linux).

Módulo 3: Gestão de Estoque e Inventário

Descrição

Este módulo é vital para o controle de mercadorias da empresa. A equipe será responsável por desenvolver as funcionalidades que automatizam a atualização do estoque, permitem a realização de inventários, gerenciam requisições de produtos e emitem alertas inteligentes para evitar rupturas ou perdas.

Requisitos Funcionais Essenciais

A equipe deve desenvolver as seguintes funcionalidades, todas com prioridade Essencial:

• [RF010] Atualização de Estoque: O estoque de um produto deve ser atualizado automaticamente em duas situações principais: após a confirmação de uma venda e após a entrada ou saída de produtos registrada através de uma Nota Fiscal eletrônica (NF-e). (Citação: "O sistema deverá atualizar automaticamente após a efetuação de cada venda e após a entrada/saída de produtos via NF-e.")
• [RF012] Inventário de Produtos: Implementar uma funcionalidade para a realização do inventário de estoque. O sistema deve permitir o registro completo de todos os produtos armazenados, com identificação, classificação e contagem de cada item. (Citação: "O inventário de estoque é o registro completo de todos os produtos armazenados em uma empresa. Ele identifica, classifica e exibe o valor de cada item...")
• [RF014] Requisitar produtos: Permitir que usuários autorizados (como o Estoquista) criem requisições de compra para fornecedores. A requisição deve conter os dados do produto, a quantidade desejada, e registrar o usuário que a criou. O status inicial da requisição deve ser "Pendente". (Citação: "O sistema deve permitir que os usuários com as devidas permissões realizem requisições de produtos... o sistema deve registrar automaticamente o usuário requisitante e definir o status inicial da requisição como 'Pendente'.")
• [RF024] Alertas de Estoque Mínimo: O sistema deve monitorar a quantidade de produtos em estoque e emitir um alerta (através de notificação no sistema ou relatório) quando a quantidade de um item atingir o nível mínimo que foi previamente configurado para ele. (Citação: "O sistema deve emitir alertas (notificação/relatório) quando a quantidade de um produto atingir o nível mínimo configurado.")
• [RF025] Alertas por Validade: O sistema deve verificar a data de validade dos produtos cadastrados e emitir alertas para os itens que estão próximos do vencimento, com base em um prazo configurável (ex: 30 dias antes do vencimento). (Citação: "O sistema deve emitir alertas para produtos cuja data de validade esteja a menos de um prazo configurável (ex.: 30 dias).")

Requisitos Não Funcionais a Considerar

• Desempenho (RNF002): As operações de atualização de estoque devem ser rápidas para não atrasar o processo de venda. O tempo de resposta deve ser inferior a dois segundos.
• Integridade (RNF009): As atualizações de estoque devem ser transacionais e atômicas para garantir que o banco de dados nunca fique em um estado inconsistente.
• Disponibilidade (RNF010): O sistema de controle de estoque é crítico para a operação e deve estar disponível 99,9% do tempo.
• Escalabilidade (RNF005): O sistema deve ser capaz de gerenciar um grande volume de produtos e transações de estoque sem degradação de performance.

Módulo 4: Gestão Financeira e de Vendas

Descrição

Este módulo é o motor financeiro do sistema, responsável por registrar as vendas, processar pagamentos e calcular os impostos associados. A equipe deverá criar uma interface de vendas eficiente e garantir que todos os cálculos e registros financeiros sejam precisos e confiáveis.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades:

Essenciais

• [RF009] Registro de Venda: Implementar a funcionalidade principal de registro de uma venda. O sistema deve capturar a data, hora, o cliente associado, a lista de produtos vendidos com suas respectivas quantidades e preços unitários, descontos aplicados e o status da venda (ex: "Concluída", "Pendente"). (Citação: "Registrar cada venda contendo data, hora, cliente, produtos, quantidades, preços unitários, descontos e status da venda.")
• [RF020] Registro da Forma de Pagamento: Para cada venda, o sistema deve permitir o registro da forma de pagamento utilizada (dinheiro, cartão de crédito/débito, boleto, etc.). Além disso, deve controlar o status do pagamento (ex: "Pago", "Parcialmente Pago", "Pendente"). (Citação: "Registrar a(s) forma(s) de pagamento utilizadas numa venda (dinheiro, cartão, boleto, etc.) e seu status (pago/parcial/pendente).")

Importantes

• [RF021] Cálculo de Impostos na Venda: O sistema deve ser capaz de calcular automaticamente os impostos aplicáveis a uma venda (como ICMS, IPI, PIS, COFINS) com base nos produtos vendidos e nas regras fiscais vigentes. (Citação: "Calcular automaticamente os impostos aplicáveis de uma venda... com base nos produtos e regras fiscais aplicáveis no país de origem da aplicação.")

Requisitos Não Funcionais a Considerar

• Integridade (RNF009): É crucial que todos os cálculos de totais, descontos e impostos sejam exatos. Os dados da venda devem ser validados para evitar inconsistências.
• Desempenho (RNF002): O processo de registro de venda deve ser rápido para não criar filas no ponto de venda. O tempo de resposta da funcionalidade deve ser inferior a dois segundos.
• Segurança (RNF003): Se o sistema processar pagamentos com cartão, deve seguir as normas de segurança PCI.
• Conformidade (RNF008): O cálculo de impostos deve estar em conformidade com a legislação fiscal, que pode mudar. O sistema deve ser flexível para atualizações nas regras de cálculo.
• Usabilidade (RNF004): A interface do ponto de venda (PDV) deve ser extremamente intuitiva e otimizada para agilidade, mesmo para usuários com pouco treinamento.

Módulo 5: Gestão Fiscal (NF-e)

Descrição

Este módulo é dedicado exclusivamente à gestão de Notas Fiscais Eletrônicas (NF-e), um componente crítico para a conformidade legal de qualquer negócio no Brasil. A equipe será responsável por desenvolver as funcionalidades de cadastro, emissão, e visualização de NF-e, garantindo a integração com os outros módulos e a aderência às normas fiscais.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades:

Essenciais

• [RF016] Cadastro de Notas Fiscais Eletrônicas: Permitir que usuários autorizados (como do setor Financeiro) registrem NF-e de entrada (compras). O sistema deve capturar informações chave como Número da Nota, Chave de Acesso (com validação de 44 dígitos), Data de Emissão, Fornecedor, e os produtos da nota. (Citação: "O sistema deve permitir que os usuários com as permissões devidas cadastrem e registrem notas fiscais eletrônicas (NF-e)... Validar a chave de acesso, garantindo que contenha 44 dígitos numéricos.")
• [RF017] Emissão de Notas Fiscais Eletrônicas: Desenvolver a funcionalidade de emissão de NF-e de saída (vendas), seguindo o Manual de Orientação do Contribuinte (MOC). O sistema deve preencher campos como Tipo de Operação, Cliente, Endereço, Produtos, e códigos fiscais (CFOP, CST), validando-os conforme a legislação. Ao final, deve gerar e armazenar o arquivo XML resultante. (Citação: "O sistema deverá contar com a função de emissão de NF-e obedecendo o MOC... Gerar e armazenar o XML resultante da NF-e emitida.")

Importantes

• [RF018] Vínculo Automático de Produtos à NF-e: Ao cadastrar uma NF-e de entrada, o sistema deve tentar vincular automaticamente os itens da nota aos produtos já cadastrados no sistema, utilizando o código do produto como chave de correspondência para agilizar o processo de entrada no estoque. (Citação: "Quando um usuário importar/cadastrar uma NF-e, vincular automaticamente os produtos do sistema aos itens da nota quando houver correspondência por código.")
• [RF019] Visualização de NF-e emitida: Após o cadastro ou emissão de uma NF-e, o sistema deve gerar automaticamente uma representação gráfica da nota, o DANFE (Documento Auxiliar da Nota Fiscal Eletrônica), para visualização e impressão. (Citação: "Ao importar/cadastrar ou emitir uma NF-e, o sistema deverá gerar um DANFE para visualização e impressão opcional.")

Requisitos Não Funcionais a Considerar

• Conformidade (RNF008): Este módulo é 100% focado em conformidade legal. A emissão do XML e a validação de campos como CFOP e CST devem seguir rigorosamente as especificações da SEFAZ e a legislação tributária vigente.
• Integridade (RNF009): A validação dos dados de entrada é crucial. Uma chave de acesso incorreta ou um CPF/CNPJ inválido podem invalidar todo o documento fiscal. O sistema deve ter múltiplas camadas de validação.
• Manutenibilidade (RNF006): A legislação fiscal muda com frequência. A arquitetura deste módulo deve permitir que as regras de negócio (cálculos de impostos, códigos fiscais) sejam atualizadas de forma fácil e segura.
• Segurança (RNF003): Os arquivos XML das notas fiscais são documentos legais e devem ser armazenados de forma segura e com backup.

Módulo 6: Inteligência de Negócio e Administração

Descrição

Este módulo agrupa funcionalidades avançadas que fornecem inteligência para o negócio e garantem a segurança e a continuidade da operação. A equipe será responsável por desenvolver sistemas de auditoria, relatórios gerenciais, rotinas de backup/restauração e um assistente de IA para suporte ao usuário.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades:

Essenciais

• [RF022] Auditoria de Compras: O sistema deve manter um histórico detalhado de todas as compras realizadas, permitindo análises sobre o desempenho dos fornecedores (preços, prazos de entrega). (Citação: "O sistema deve manter o histórico de compras realizadas pelos Usuarios e desempenho dos fornecedores.")
• [RF023] Controle de Fornecedores: Implementar uma ferramenta que permita comparar preços e prazos entre diferentes fornecedores e que se integre com os módulos de compras e estoque para automatizar a reposição de mercadorias. (Citação: "O sistema deverá permitir comparar preços e prazos, além de integrar-se diretamente com os módulos de compras e estoque para automatizar o processo de reposição de mercadorias.")
• [RF028] Backup: Desenvolver uma funcionalidade que permita a realização de backups periódicos (agendados ou manuais) de todos os dados do sistema, garantindo a integridade das informações. (Citação: "O sistema deve permitir a realização de backups periódicos dos dados, garantindo a integridade das informações.")
• [RF029] Restauração de Dados: Criar a funcionalidade complementar ao backup, que permita a restauração dos dados a partir de um arquivo de backup em caso de falha, perda ou corrupção do banco de dados. (Citação: "O sistema deve permitir a restauração desses dados em caso de falhas, perdas ou corrupção no banco, assegurando continuidade operacional.")

Importantes

• [RF026] Relatórios Gerenciais e Indicadores: Criar um painel de controle (dashboard) interativo com relatórios e indicadores de desempenho. Deve oferecer análises de vendas por período, produtividade dos vendedores, lucro bruto e margens de contribuição. (Citação: "O sistema deve gerar relatórios e paineis interativos com indicadores de desempenho comercial...")

Desejáveis

• [RF030] Assistência IA: Desenvolver um chatbot assistente, baseado em Inteligência Artificial, para auxiliar os usuários na utilização do sistema. O chatbot deve ser capaz de responder a perguntas sobre as funcionalidades, guiando o usuário e melhorando a experiência de uso. (Citação: "O sistema possuiria um chatbot assistente baseado em Inteligência Artificial que teria a função de auxiliar os usuários na utilização do sistema.")

Requisitos Não Funcionais a Considerar

• Disponibilidade (RNF010): A funcionalidade de backup e restauração é crítica para a continuidade do negócio. Deve ser confiável e bem testada.
• Desempenho (RNF002): A geração de relatórios complexos não deve afetar a performance do sistema para os demais usuários. Considerar a geração assíncrona ou o uso de um banco de dados analítico separado.
• Escalabilidade (RNF005): A base de dados de auditoria e relatórios crescerá rapidamente. A arquitetura deve ser projetada para lidar com esse grande volume de dados.
• Usabilidade (RNF004): Os painéis de relatórios devem ser intuitivos, com gráficos e visualizações que facilitem a compreensão dos dados pelos gestores. O chatbot de IA deve ter uma linguagem natural e ser genuinamente útil.

Sistema4-SAJDrive

Módulo 1: Pagamento e Bilhetagem

Descrição

Este módulo é responsável por todas as transações financeiras dentro do aplicativo, desde a recarga de créditos até o pagamento da passagem. A equipe deverá implementar um sistema de pagamento seguro e versátil, incluindo a gestão de cartões de transporte e a integração com gateways de pagamento externos.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

• RF17: Pagamento Direto: Implementar uma funcionalidade de pagamento que se comunique com um provedor de pagamento (ex: um aplicativo de cartão de crédito) para autorizar uma transação e retornar uma confirmação de sucesso ou falha. (Citação: "o aplicativo deve possibilitar pagamento por meio de um pedido enviado ao provedor do pagamento... e que retorna uma condição caso o pagamento tenha sucesso ou não.")
• RF18: Cartão Virtual: Desenvolver um sistema de cartão de transporte virtual próprio da plataforma, que pode ser usado para o pagamento da passagem. (Citação: "O aplicativo deve permitir a criação e utilização de um cartão virtual próprio da plataforma para pagamento da passagem.")
• RF19: Gerenciamento de Cartões: Criar uma interface onde o usuário possa gerenciar seus cartões de transporte cadastrados, permitindo ações como adicionar, remover ou editar um cartão. (Citação: "O aplicativo deve fornecer uma interface para o usuário gerenciar seu cartão de transporte já cadastrado (ex: remover ou editar).")
• RF20: Recarga (PayPal): Integrar o sistema de recarga do cartão virtual com a plataforma de pagamento PayPal. A funcionalidade deve enviar uma requisição com o valor desejado e processar a transação. (Citação: "O aplicativo deve permitir a recarga dos cartões virtuais, possuindo integração com o sistema de pagamento PayPal...")
• RF21: Consulta de Saldo: Fornecer uma interface clara para o usuário visualizar o saldo de créditos disponível em seu cartão de transporte cadastrado. (Citação: "O aplicativo deve permitir ao usuário uma interface para visualizar seu cartão cadastrado e o saldo de crédito.")
• RF22: Pontos de Venda (Mapa): Utilizando o GPS do usuário, o aplicativo deve exibir em um mapa a localização dos pontos de venda físicos mais próximos onde é possível comprar bilhetes ou realizar recargas. (Citação: "O aplicativo deve exibir no mapa a localização dos pontos de venda de bilhetes e recarga físicos mais próximos ao usuário...")

Requisitos Não Funcionais a Considerar

• Segurança e Privacidade (RNF04): Todas as transações financeiras e dados de cartão devem ser processados de forma segura, utilizando criptografia e em conformidade com as normas do setor de pagamentos. Aderência estrita à LGPD.
• Disponibilidade (RNF02): O sistema de pagamento e consulta de saldo deve estar sempre disponível (24/7).
• Usabilidade (RNF05): O processo de pagamento, recarga e consulta de saldo deve ser simples, rápido e transparente para o usuário.
• Conectividade (RNF06): As transações devem ser tratadas de forma a prevenir falhas em caso de instabilidade na conexão de internet.

Módulo 2: Notificações e Alertas

Descrição

Este módulo tem como objetivo manter o usuário informado de forma proativa sobre eventos importantes de sua viagem. A equipe será responsável por implementar um sistema de notificações push que alerte o usuário sobre a proximidade do ônibus, mudanças de trajeto e lotação do veículo.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

• RF23: Alerta de Embarque: O aplicativo deve enviar uma notificação push para o usuário quando o ônibus que ele pretende pegar estiver se aproximando do ponto de embarque selecionado. O gatilho para a notificação será a saída do ônibus da última parada anterior ao ponto do usuário. (Citação: "O aplicativo deve enviar notificações (push) ao usuário quando o seu ônibus estiver próximo... do ponto de embarque selecionado. (Notificação será feita assim que o onibus sair da última parada anterior à de destino)")
• RF24: Alerta de Modificação de Trajeto: Caso ocorra uma modificação inesperada no trajeto de uma linha de interesse do usuário (como um desvio ou interdição), o aplicativo deve notificá-lo. A notificação deve dar ao usuário a opção de continuar com a viagem (atualizando as informações) ou cancelar a solicitação de embarque. (Citação: "O aplicativo deve notificar o usuário caso ocorra uma modificação inesperada... no trajeto de uma linha de seu interesse e perguntar se o usuário quer continuar com o pedido ou cancelar a solicitação de embarque.")
• RF25: Alerta de Lotação: O aplicativo deve fornecer uma estimativa da lotação do ônibus que está se aproximando. Essa informação será visual, representada pela coloração da miniatura do ônibus no mapa, e calculada com base na contagem de solicitações de embarque feitas por todos os usuários do aplicativo para aquele veículo. (Citação: "O aplicativo deve notificar a lotação estimada do ônibus que está se aproximando (por meio da coloração da miniatura no mapa). Tal parâmetro é medido com base na contagem de solicitações de embarque...")

Requisitos Não Funcionais a Considerar

• Desempenho (RNF01): O envio de notificações deve ocorrer em tempo real, com latência mínima.
• Usabilidade (RNF05): As notificações devem ser claras, concisas e relevantes para o usuário. Deve ser possível para o usuário gerenciar as preferências de notificação.
• Conectividade (RNF06): O sistema de notificações deve ser resiliente a falhas de conexão, garantindo a entrega das mensagens assim que a conexão for restabelecida.
• Escalabilidade (RNF07): A infraestrutura deve ser capaz de lidar com o envio de um grande volume de notificações simultâneas para milhares de usuários.
• Compatibilidade (RNF03): O serviço de notificação push deve ser compatível e funcional tanto em dispositivos Android quanto iOS.

Módulo 3: Feedback e Suporte

Descrição

Este módulo estabelece um canal de comunicação direto entre o usuário e a administração do serviço de transporte. A equipe será responsável por desenvolver ferramentas que permitam aos usuários relatar problemas, enviar sugestões e avaliar a qualidade do serviço, fornecendo dados valiosos para a melhoria contínua.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

• RF26: Envio de Comentários (Problemas): Permitir que o usuário envie feedback estruturado sobre problemas específicos ocorridos durante sua viagem. O formulário deve guiar o usuário a fornecer as informações necessárias para a análise do problema. (Citação: "O aplicativo deve permitir que o usuário envie comentários estruturados sobre eventuais problemas ocorridos durante a viagem.")
• RF27: Envio de Sugestões: Disponibilizar uma funcionalidade para que os usuários possam enviar sugestões gerais de melhoria, tanto para o aplicativo quanto para o serviço de transporte em si, direcionando-as à central de atendimento. (Citação: "O aplicativo deve possibilitar o envio de sugestões gerais de melhoria (para o app ou para o serviço) diretamente para a central de atendimento.")
• RF28: Avaliação do Motorista: Ao final de uma viagem, o aplicativo deve oferecer ao usuário a opção de avaliar a qualidade do serviço prestado pelo motorista, como por exemplo, através de um sistema de estrelas ou um formulário simples. (Citação: "O aplicativo deve permitir que o usuário avalie a qualidade do serviço prestado pelo motorista ao final da viagem.")

Requisitos Não Funcionais a Considerar

• Usabilidade (RNF05): A interface para envio de feedback e avaliações deve ser simples e rápida de usar, para encorajar a participação dos usuários.
• Armazenamento (RNF09): Todos os dados de feedback, sugestões e avaliações devem ser armazenados de forma organizada na nuvem, para análise posterior pela equipe administrativa.
• Segurança e Privacidade (RNF04): Opcionalmente, permitir o envio de feedback anônimo, mas garantindo que, se o usuário estiver logado, seus dados sejam tratados com confidencialidade.
• Manutenibilidade (RNF08): A categorização dos feedbacks deve ser flexível, permitindo que a equipe administrativa ajuste os tipos de problemas e sugestões que podem ser reportados.

Módulo 4: Integrações e Relatórios (Admin)

Descrição

Este módulo abrange funcionalidades avançadas, tanto para o usuário final quanto para a administração do sistema. A equipe será responsável por desenvolver a capacidade de integração do aplicativo com dispositivos vestíveis e assistentes virtuais, além de construir um painel administrativo para a geração de relatórios estratégicos.

Requisitos Funcionais

A equipe deve desenvolver as seguintes funcionalidades, com base na documentação original:

Para Usuários

• RF30: Integração (Dispositivos Externos): O aplicativo deve ser capaz de se conectar com dispositivos como smartwatches e assistentes virtuais (ex: Google Assistant, Siri). Essa integração deve permitir a realização de consultas rápidas (como "que horas passa o próximo ônibus?") e o recebimento de alertas diretamente nesses dispositivos. (Citação: "O aplicativo deve permitir a conexão com dispositivos smartwatch e assistentes virtuais para consultas e alertas rápidos.")

Para Administradores

• RF29: Geração de Relatórios (Admin): Desenvolver um módulo administrativo (web ou desktop) que permita a geração de relatórios sobre o uso do sistema. Os relatórios devem incluir estatísticas chave, como as linhas mais acessadas, horários de pico, número de reclamações por categoria, e avaliações médias dos motoristas. (Citação: "O sistema (em seu módulo administrativo) deve ser capaz de gerar relatórios sobre o uso, incluindo estatísticas como linhas mais acessadas e número de reclamações.")

Requisitos Não Funcionais a Considerar

• Compatibilidade (RNF03): A integração com smartwatches e assistentes virtuais deve ser testada e garantida para as plataformas mais populares do mercado.
• Segurança e Privacidade (RNF04): O acesso aos dados para geração de relatórios deve ser restrito a usuários autorizados (administradores). Os relatórios devem anonimizar os dados dos usuários para proteger sua privacidade.
• Desempenho (RNF01): A geração de relatórios complexos não deve impactar o desempenho do sistema para os usuários finais. A geração pode ser um processo assíncrono.
• Escalabilidade (RNF07): O sistema de relatórios deve ser projetado para processar um grande volume de dados à medida que o número de usuários e viagens aumenta.
• Usabilidade (RNF05): O painel administrativo deve ser intuitivo, permitindo que os gestores filtrem e visualizem os dados de forma eficaz.

Entrega

Link para Entrega