Sport Tech Club

Appearance

Casos de Uso - Sport Tech Club ​

Versão: 1.0.0
Data: 2026-01-09
Status: Draft

Sumário ​

Introdução ​

Este documento descreve todos os casos de uso do Sport Tech Club, seguindo o formato UML/Cockburn, com foco em clareza, completude e rastreabilidade com requisitos e regras de negócio.

Objetivo ​

Detalhar as interações entre atores e sistema, fluxos principais, alternativos e de exceção, garantindo entendimento comum entre stakeholders técnicos e de negócio.

Escopo ​

Casos de uso cobrem todas as funcionalidades do sistema organizadas por módulos, priorizados para implementação em fases (MVP, Fase 2, Fase 3).

Atores ​

Atores Primários ​

AtorDescriçãoPersona Relacionada
PlayerJogador/Aluno que utiliza a arenaAna Paula (Aluno), Pedro Henrique (Avulso)
Arena OwnerProprietário/Dono da arenaRoberto Silva
Arena ManagerGerente operacional da arenaMariana Costa
ReceptionistAtendente da recepçãoMariana Costa
InstructorProfessor/Instrutor de aulasCarlos Eduardo
StaffFuncionário (bar, manutenção)Lucas Ferreira
Event ParticipantParticipante de evento pontualJulia Santos
SponsorPatrocinador/AnuncianteRicardo Almeida
System AdminAdministrador do sistema-

Atores Secundários ​

AtorDescrição
Payment GatewaySistema externo de pagamento
Access Control SystemSistema de controle de acesso físico (Ziggy)
Camera SystemSistema de câmeras/gravação
IoT DeviceDispositivos IoT (botões, sensores)
Notification ServiceServiço de envio de notificações
CRM SystemSistema de gestão de relacionamento
ERP SystemSistema de gestão empresarial

Convenções ​

Formato de ID ​

UC-[MÓDULO]-[NÚMERO]

Exemplos:

  • UC-AUTH-01: Primeiro caso de uso de Autenticação
  • UC-BOOK-05: Quinto caso de uso de Reservas

Prioridade ​

PrioridadeFaseDescrição
MVPFase 1Essencial para lançamento
P2Fase 2Importante, não bloqueante
P3Fase 3Inovação e otimização

Níveis de Detalhamento ​

  • Alto Nível (Kite): Visão geral do caso de uso
  • Nível do Mar (Sea Level): Interações do usuário com sistema
  • Subaquático (Fish): Detalhes internos e integrações

Este documento foca em Nível do Mar com detalhes Subaquáticos quando necessário.

UC-AUTH: Autenticação e Autorização ​

UC-AUTH-01: Fazer Login ​

Prioridade: MVP
Ator Principal: Player, Staff, Instructor, Arena Manager
Atores Secundários: Notification Service
Pré-condições:

  • Usuário deve estar cadastrado no sistema
  • Sistema deve estar disponível

Pós-condições:

  • Usuário autenticado com sessão ativa
  • Token JWT gerado
  • Última atividade registrada

Trigger: Usuário acessa aplicativo ou portal web

Fluxo Principal ​

  1. Usuário acessa tela de login
  2. Sistema exibe opções de autenticação:
    • Email/Senha
    • Google SSO
    • Apple ID
    • Facebook
  3. Usuário seleciona método e fornece credenciais
  4. Sistema valida credenciais contra Identity Context
  5. Sistema verifica se MFA está habilitado
  6. SE MFA habilitado:
    • Sistema envia código de verificação (SMS ou Authenticator App)
    • Usuário informa código
    • Sistema valida código
  7. Sistema cria sessão ativa
  8. Sistema gera token JWT com claims (userId, tenantId, roles, permissions)
  9. Sistema registra login em AuthenticationAttempt
  10. Sistema retorna token e perfil do usuário
  11. Sistema exibe dashboard apropriado ao perfil

Resultado: Usuário autenticado e redirecionado ao dashboard

Fluxos Alternativos ​

3a. Usuário seleciona "Esqueci minha senha"

  1. Sistema redireciona para UC-AUTH-03 (Recuperar Senha)

4a. Credenciais inválidas

  1. Sistema incrementa contador de tentativas falhas
  2. Sistema registra falha em AuthenticationAttempt
  3. SE tentativas < 5:
    • Sistema exibe mensagem "Credenciais inválidas"
    • Retorna ao passo 3
  4. SENÃO:
    • Sistema bloqueia conta temporariamente (15 minutos)
    • Sistema envia notificação de bloqueio ao email
    • Sistema exibe mensagem de bloqueio
    • Termina caso de uso

6a. Usuário não recebe código MFA

  1. Sistema oferece opção "Reenviar código"
  2. Sistema reenvia código
  3. Retorna ao passo 6

6b. Código MFA inválido

  1. Sistema incrementa tentativas de MFA
  2. SE tentativas < 3:
    • Sistema exibe erro
    • Retorna ao passo 6
  3. SENÃO:
    • Sistema cancela login
    • Sistema envia alerta de segurança
    • Termina caso de uso

Fluxos de Exceção ​

E1. Sistema de autenticação indisponível

  1. Sistema exibe mensagem "Serviço temporariamente indisponível"
  2. Sistema registra erro em logs
  3. Sistema envia alerta para equipe técnica
  4. Termina caso de uso

E2. Token JWT expirado (em requisições subsequentes)

  1. Sistema detecta token expirado
  2. Sistema retorna erro 401 Unauthorized
  3. Cliente solicita refresh token
  4. Sistema valida refresh token
  5. Sistema gera novo JWT
  6. Sistema retorna novo token

E3. Sessão detectada em localização suspeita

  1. Sistema detecta login de IP/país diferente do habitual
  2. Sistema bloqueia login temporariamente
  3. Sistema envia email de verificação
  4. Usuário deve confirmar que foi ele
  5. Após confirmação, sistema libera login

Regras de Negócio ​

  • RN-AUTH-001: Senha deve ter mínimo 8 caracteres, letra maiúscula, minúscula, número e símbolo
  • RN-AUTH-002: MFA é obrigatório para perfis Admin e Arena Manager
  • RN-AUTH-003: Sessão expira após 24h de inatividade ou 7 dias de criação
  • RN-AUTH-004: Máximo 5 tentativas de login antes de bloqueio temporário
  • RN-AUTH-005: Bloqueio temporário dura 15 minutos
  • RN-AUTH-006: Usuário pode ter até 3 sessões simultâneas

Requisitos Relacionados ​

  • RF-USER-001 (Cadastro de Usuários)
  • RF-USER-002 (Gestão de Perfis e Papéis)
  • RNF-SEC-001 (Autenticação segura)
  • RNF-SEC-002 (Proteção contra brute force)

UC-AUTH-02: Cadastrar Usuário ​

Prioridade: MVP
Ator Principal: Player, Instructor, Staff
Atores Secundários: Notification Service
Pré-condições:

  • Email não deve estar cadastrado
  • Sistema deve estar disponível

Pós-condições:

  • Usuário cadastrado no sistema
  • Email de verificação enviado
  • Perfil básico criado

Trigger: Usuário acessa tela de cadastro ou primeiro login via SSO

Fluxo Principal ​

  1. Usuário acessa tela de cadastro
  2. Sistema exibe formulário:
    • Nome completo
    • Email
    • Telefone
    • Senha (se não for SSO)
    • Data de nascimento
    • Aceite de termos de uso e privacidade (LGPD)
  3. Usuário preenche formulário
  4. Sistema valida dados:
    • Email único no tenant
    • Formato válido de email e telefone
    • Senha atende requisitos de segurança
    • Idade mínima (14 anos) ou responsável informado
  5. Sistema cria UserAccount no Identity Context
  6. Sistema cria PersonProfile
  7. SE usuário tem menos de 18 anos:
    • Sistema solicita dados do responsável
    • Sistema vincula responsável ao perfil
  8. Sistema gera token de verificação de email
  9. Sistema envia email de verificação
  10. Sistema cria Consent records para termos aceitos
  11. Sistema exibe mensagem de sucesso
  12. Sistema sugere download do app (se web)

Resultado: Usuário cadastrado com status PENDING_VERIFICATION

Fluxos Alternativos ​

1a. Usuário opta por cadastro via Google/Apple/Facebook

  1. Sistema redireciona para provedor de identidade
  2. Usuário autoriza acesso
  3. Sistema recebe dados do provedor (email, nome, foto)
  4. Sistema cria UserAccount e OAuthCredential
  5. Email considerado verificado automaticamente
  6. Pula para passo 11

4a. Email já cadastrado

  1. Sistema exibe erro "Email já cadastrado"
  2. Sistema oferece opções:
    • Fazer login
    • Recuperar senha
  3. Usuário escolhe opção
  4. Sistema redireciona adequadamente

4b. Senha não atende requisitos

  1. Sistema exibe validação inline dos requisitos
  2. Sistema sugere senha forte
  3. Usuário corrige senha
  4. Retorna ao passo 4

7a. Usuário menor de 14 anos

  1. Sistema não permite cadastro
  2. Sistema exibe mensagem "Idade mínima: 14 anos"
  3. Sistema sugere contato com arena para cadastro especial
  4. Termina caso de uso

Fluxos de Exceção ​

E1. Serviço de email indisponível

  1. Sistema completa cadastro normalmente
  2. Sistema registra envio pendente em fila
  3. Sistema tenta reenviar periodicamente
  4. Sistema alerta usuário: "Confirme seu email quando receber"

E2. Provedor SSO indisponível

  1. Sistema exibe erro "Serviço temporariamente indisponível"
  2. Sistema sugere cadastro com email/senha
  3. Termina caso de uso

Regras de Negócio ​

  • RN-AUTH-007: Email deve ser único por tenant
  • RN-AUTH-008: Usuário menor de 14 anos não pode se cadastrar sozinho
  • RN-AUTH-009: Usuário entre 14-17 anos requer responsável vinculado
  • RN-AUTH-010: Cadastro via SSO dispensa verificação de email
  • RN-AUTH-011: Senha deve ter mínimo 8 caracteres com complexidade média

Requisitos Relacionados ​

  • RF-USER-001 (Cadastro de Usuários)
  • RNF-SEC-003 (Proteção de dados - LGPD)
  • RNF-USAB-001 (Cadastro em < 2 minutos)

UC-AUTH-03: Recuperar Senha ​

Prioridade: MVP
Ator Principal: Player, Instructor, Staff
Atores Secundários: Notification Service
Pré-condições:

  • Usuário deve estar cadastrado
  • Email deve estar verificado

Pós-condições:

  • Token de recuperação gerado
  • Email enviado
  • Senha alterada (se fluxo completo)

Trigger: Usuário clica em "Esqueci minha senha" no login

Fluxo Principal ​

  1. Usuário acessa tela "Esqueci minha senha"
  2. Sistema solicita email
  3. Usuário informa email
  4. Sistema valida se email existe no tenant
  5. Sistema gera token de recuperação (válido por 1 hora)
  6. Sistema envia email com link de recuperação
  7. Sistema exibe mensagem: "Email enviado, verifique sua caixa de entrada"
  8. Usuário clica no link do email
  9. Sistema valida token:
    • Não expirado
    • Não utilizado
    • Pertence ao tenant correto
  10. Sistema exibe formulário de nova senha
  11. Usuário informa nova senha (2x para confirmar)
  12. Sistema valida senha conforme políticas
  13. Sistema atualiza PasswordCredential
  14. Sistema adiciona hash anterior ao histórico (evitar reuso)
  15. Sistema invalida token de recuperação
  16. Sistema envia email de confirmação
  17. Sistema exibe mensagem de sucesso
  18. Sistema redireciona para login

Resultado: Senha alterada com sucesso

Fluxos Alternativos ​

4a. Email não encontrado

  1. Sistema NÃO revela que email não existe (segurança)
  2. Sistema exibe mesma mensagem de sucesso
  3. Sistema registra tentativa suspeita em logs
  4. Termina caso de uso

9a. Token expirado

  1. Sistema exibe mensagem "Link expirado, solicite novo"
  2. Sistema oferece botão "Reenviar email"
  3. SE usuário clica:
    • Retorna ao passo 4
  4. SENÃO:
    • Termina caso de uso

9b. Token já utilizado

  1. Sistema exibe "Link já utilizado"
  2. Sistema sugere fazer login ou solicitar novo link
  3. Termina caso de uso

12a. Nova senha igual à anterior

  1. Sistema exibe erro "Senha não pode ser igual à anterior"
  2. Retorna ao passo 11

12b. Nova senha no histórico de senhas antigas

  1. Sistema exibe erro "Senha já utilizada anteriormente"
  2. Retorna ao passo 11

Fluxos de Exceção ​

E1. Múltiplas solicitações em curto período

  1. Sistema detecta > 3 solicitações em 10 minutos para mesmo email
  2. Sistema aplica rate limiting
  3. Sistema exibe: "Aguarde alguns minutos antes de nova tentativa"
  4. Sistema registra possível ataque em logs
  5. Termina caso de uso

E2. Serviço de email indisponível

  1. Sistema registra erro
  2. Sistema adiciona envio à fila de retry
  3. Sistema exibe erro genérico ao usuário
  4. Termina caso de uso

Regras de Negócio ​

  • RN-AUTH-012: Token de recuperação válido por 1 hora
  • RN-AUTH-013: Token só pode ser usado uma vez
  • RN-AUTH-014: Sistema não revela se email existe (proteção contra enumeração)
  • RN-AUTH-015: Nova senha não pode ser igual às 3 últimas
  • RN-AUTH-016: Rate limit: 3 solicitações por email a cada 10 minutos

Requisitos Relacionados ​

  • RF-USER-001 (Gestão de Usuários)
  • RNF-SEC-004 (Recuperação segura de senha)

UC-AUTH-04: Configurar MFA ​

Prioridade: MVP
Ator Principal: Player, Instructor, Arena Manager
Atores Secundários: Notification Service
Pré-condições:

  • Usuário deve estar autenticado
  • Email deve estar verificado

Pós-condições:

  • MFA habilitado na conta
  • Método de MFA configurado
  • Códigos de backup gerados

Trigger: Usuário acessa configurações de segurança ou sistema força MFA

Fluxo Principal ​

  1. Usuário acessa "Configurações de Segurança"
  2. Sistema exibe status atual de MFA
  3. Usuário clica em "Habilitar MFA"
  4. Sistema exibe métodos disponíveis:
    • SMS
    • Authenticator App (TOTP)
    • Email
  5. Usuário seleciona método
  6. SE método = SMS:
    • Sistema valida se telefone está cadastrado e verificado
    • Sistema envia código de teste
    • Usuário informa código
    • Sistema valida código
  7. SE método = Authenticator App:
    • Sistema gera secret TOTP
    • Sistema exibe QR Code
    • Usuário escaneia QR Code no app (Google Authenticator, Authy)
    • Sistema solicita código de verificação
    • Usuário informa código gerado pelo app
    • Sistema valida código
  8. SE método = Email:
    • Sistema usa email já verificado
    • Sistema envia código de teste
    • Usuário informa código
    • Sistema valida código
  9. Sistema marca MFA como habilitado no UserAccount
  10. Sistema gera 10 códigos de backup
  11. Sistema exibe códigos e solicita que usuário salve em local seguro
  12. Usuário confirma que salvou códigos
  13. Sistema registra habilitação de MFA em audit log
  14. Sistema exibe mensagem de sucesso

Resultado: MFA habilitado com sucesso

Fluxos Alternativos ​

6a. Telefone não cadastrado ou não verificado

  1. Sistema exibe erro "Cadastre e verifique telefone primeiro"
  2. Sistema oferece link para "Adicionar Telefone"
  3. Usuário é redirecionado para UC-USER-05 (Atualizar Perfil)

7a. Usuário não consegue escanear QR Code

  1. Sistema oferece opção "Inserir código manualmente"
  2. Sistema exibe secret em texto
  3. Usuário digita secret no app authenticator
  4. Retorna ao passo 7 do fluxo principal

7b. Código TOTP inválido

  1. Sistema exibe erro "Código inválido ou expirado"
  2. Sistema solicita novo código
  3. SE usuário informa código correto:
    • Continua no passo 9
  4. SENÃO após 3 tentativas:
    • Sistema cancela configuração
    • Retorna ao passo 4

12a. Usuário perde códigos de backup

  1. Usuário pode solicitar "Regenerar códigos de backup"
  2. Sistema invalida códigos anteriores
  3. Sistema gera novos 10 códigos
  4. Sistema exibe novos códigos

Fluxos de Exceção ​

E1. Usuário Admin é forçado a habilitar MFA

  1. Sistema detecta papel Admin sem MFA
  2. Sistema exibe modal obrigatório ao login
  3. Usuário não pode prosseguir sem configurar
  4. Executa fluxo principal

E2. Serviço SMS indisponível

  1. Sistema detecta falha no envio de SMS
  2. Sistema oferece métodos alternativos (Email, Authenticator)
  3. Usuário seleciona alternativa
  4. Retorna ao passo 6

Regras de Negócio ​

  • RN-AUTH-017: MFA obrigatório para perfis Admin, Arena Manager e Instructor
  • RN-AUTH-018: Código TOTP tem validade de 30 segundos
  • RN-AUTH-019: Códigos de backup são de uso único
  • RN-AUTH-020: Sistema gera 10 códigos de backup
  • RN-AUTH-021: Após usar 7 códigos de backup, sistema alerta para regenerar

Requisitos Relacionados ​

  • RF-USER-002 (Gestão de Perfis)
  • RNF-SEC-005 (MFA obrigatório para papéis críticos)

UC-AUTH-05: Fazer Logout ​

Prioridade: MVP
Ator Principal: Todos os usuários autenticados
Atores Secundários: -
Pré-condições:

  • Usuário deve estar autenticado

Pós-condições:

  • Sessão encerrada
  • Token invalidado
  • Dispositivo desvinculado (se aplicável)

Trigger: Usuário clica em "Sair" ou "Logout"

Fluxo Principal ​

  1. Usuário clica em opção "Sair"
  2. Sistema exibe confirmação: "Deseja realmente sair?"
  3. Usuário confirma
  4. Sistema invalida token JWT atual
  5. Sistema marca Session como TERMINATED
  6. Sistema registra timestamp de logout
  7. Sistema remove dados em cache/local storage
  8. Sistema redireciona para tela de login
  9. Sistema exibe mensagem "Logout realizado com sucesso"

Resultado: Usuário desconectado

Fluxos Alternativos ​

3a. Usuário cancela logout

  1. Sistema mantém sessão ativa
  2. Usuário permanece autenticado
  3. Termina caso de uso

5a. Logout de todas as sessões

  1. Usuário seleciona "Sair de todos os dispositivos"
  2. Sistema lista todas Session ativas do usuário
  3. Sistema invalida todas as sessões
  4. Sistema envia notificação aos outros dispositivos
  5. Continua no passo 7

Fluxos de Exceção ​

E1. Logout automático por inatividade

  1. Sistema detecta inatividade > 24h
  2. Sistema invalida sessão automaticamente
  3. Ao próximo acesso, usuário vê mensagem "Sessão expirada"
  4. Sistema redireciona para login

E2. Logout forçado por administrador

  1. Administrador força logout de usuário específico
  2. Sistema invalida todas sessões do usuário
  3. Sistema envia notificação ao usuário
  4. Usuário deve fazer login novamente

Regras de Negócio ​

  • RN-AUTH-022: Sessão expira após 24h de inatividade
  • RN-AUTH-023: Token JWT invalidado não pode ser reativado
  • RN-AUTH-024: Logout deve limpar todos dados sensíveis em cache

Requisitos Relacionados ​

  • RF-USER-002 (Gestão de Sessões)
  • RNF-SEC-006 (Logout seguro)

UC-ARENA: Gestão de Arena ​

UC-ARENA-01: Cadastrar Arena ​

Prioridade: MVP
Ator Principal: System Admin, Arena Owner
Atores Secundários: -
Pré-condições:

  • Usuário deve ter permissão arena:create:tenant
  • Tenant deve estar ativo

Pós-condições:

  • Arena cadastrada no sistema
  • Configurações padrão aplicadas
  • Arena vinculada ao tenant

Trigger: Admin acessa "Nova Arena" no painel administrativo

Fluxo Principal ​

  1. Admin acessa módulo de gestão de arenas
  2. Sistema exibe botão "Cadastrar Nova Arena"
  3. Admin clica no botão
  4. Sistema exibe formulário:
    • Nome da arena
    • Nome fantasia
    • CNPJ
    • Endereço completo
    • Telefone
    • Email de contato
    • Horário de funcionamento (por dia da semana)
    • Timezone
    • Capacidade total de pessoas
    • Upload de logo
    • Upload de fotos da arena
  5. Admin preenche formulário
  6. Sistema valida dados:
    • CNPJ válido e único
    • Endereço completo
    • Telefone e email válidos
    • Horários consistentes
  7. Sistema cria registro de Arena no Arena Context
  8. Sistema cria ArenaTenant vinculando ao tenant
  9. Sistema aplica configurações padrão:
    • Tempo de partida: 50 minutos
    • Tolerância de atraso: 5 minutos
    • Política de cancelamento: até 2h antes
    • Modo operacional: RESERVADO
  10. Sistema cria zonas de acesso padrão:
    • LOBBY
    • COURTS
    • LOCKER_ROOMS
    • BAR
    • OFFICE
  11. Sistema exibe mensagem de sucesso
  12. Sistema redireciona para configuração de quadras (UC-COURT-01)

Resultado: Arena cadastrada e pronta para configuração de quadras

Fluxos Alternativos ​

6a. CNPJ já cadastrado

  1. Sistema exibe erro "CNPJ já cadastrado"
  2. Sistema sugere editar arena existente
  3. Retorna ao passo 4

6b. Endereço não encontrado

  1. Sistema tenta validar endereço via API (ViaCEP, Google Maps)
  2. SE não encontrado:
    • Sistema exibe alerta mas permite prosseguir
    • Admin confirma endereço manualmente
  3. Continua no passo 7

12a. Admin opta por configurar depois

  1. Sistema salva arena
  2. Sistema exibe mensagem: "Configure quadras para começar a operar"
  3. Sistema redireciona para lista de arenas

Fluxos de Exceção ​

E1. Upload de logo/fotos falha

  1. Sistema salva arena sem mídia
  2. Sistema permite adicionar mídia posteriormente
  3. Sistema exibe alerta: "Adicione logo e fotos na edição"

E2. Limite de arenas do plano atingido

  1. Sistema detecta limite de arenas do tenant
  2. Sistema exibe erro "Limite de arenas atingido. Faça upgrade do plano"
  3. Sistema oferece link para upgrade
  4. Termina caso de uso

Regras de Negócio ​

  • RN-ARENA-001: CNPJ deve ser único no sistema
  • RN-ARENA-002: Arena deve ter ao menos 1 quadra para operar
  • RN-ARENA-003: Horário de funcionamento não pode ter gaps (deve cobrir 24h)
  • RN-ARENA-004: Logo recomendado: 500x500px, PNG/JPG
  • RN-ARENA-005: Timezone deve ser configurado conforme localização física

Requisitos Relacionados ​

  • RF-ARENA-001 (Cadastro da Arena)
  • RF-ARENA-002 (Cadastro de Áreas Físicas)
  • RF-ARENA-003 (Cadastro de Zonas de Acesso)

UC-ARENA-02: Configurar Parâmetros Operacionais ​

Prioridade: MVP
Ator Principal: Arena Owner, Arena Manager
Atores Secundários: -
Pré-condições:

  • Arena deve estar cadastrada
  • Usuário deve ter permissão arena:update:tenant

Pós-condições:

  • Parâmetros operacionais atualizados
  • Regras aplicadas em reservas e filas

Trigger: Admin acessa "Configurações Operacionais" da arena

Fluxo Principal ​

  1. Admin acessa detalhes da arena

  2. Sistema exibe aba "Configurações Operacionais"

  3. Admin clica na aba

  4. Sistema exibe formulário com configurações atuais:

    Tempos e Tolerâncias:

    • Duração padrão de partida (minutos)
    • Tolerância de atraso para check-in (minutos)
    • Tempo de preparação entre partidas (minutos)
    • Tempo máximo de permanência na fila (minutos)

    Políticas de Cancelamento:

    • Prazo mínimo para cancelamento sem penalidade (horas)
    • Penalidade por no-show (% do valor ou pontos)
    • Penalidade por cancelamento tardio (% do valor)

    Modo Operacional:

    • LIVRE (sem reserva, por ordem de chegada)
    • RESERVADO (apenas com reserva prévia)
    • MISTO (horários livres + horários reservados)
    • EVENTO (arena dedicada a evento)

    Reservas:

    • Antecedência mínima para reserva (horas)
    • Antecedência máxima para reserva (dias)
    • Limite de reservas simultâneas por usuário
    • Reserva requer pagamento antecipado? (Sim/Não)

    Fila:

    • Fila habilitada? (Sim/Não)
    • Notificação antecipada quando chegar a vez (minutos)
    • Tempo de resposta para aceitar vaga (minutos)

    Check-in:

    • Check-in obrigatório? (Sim/Não)
    • Antecedência mínima para check-in (minutos)
    • Liberação automática de quadra se sem check-in? (Sim/Não)

  5. Admin altera configurações desejadas

  6. Sistema valida valores:

    • Tempos não negativos
    • Percentuais entre 0-100%
    • Lógica consistente (ex: antecedência mín < máx)

  7. Sistema exibe prévia de impacto:

    • "Com essas configurações, reservas podem ser feitas entre 2h e 30 dias de antecedência"
    • "Cancelamentos até 2h antes não terão penalidade"

  8. Admin confirma

  9. Sistema salva configurações em Arena.configuration

  10. Sistema registra auditoria de mudança

  11. Sistema exibe mensagem de sucesso

  12. Sistema aplica novas regras para reservas futuras

Resultado: Configurações operacionais atualizadas

Fluxos Alternativos ​

6a. Valores inválidos

  1. Sistema exibe validação inline
  2. Sistema destaca campos inválidos
  3. Admin corrige valores
  4. Retorna ao passo 6

7a. Admin quer simular impacto

  1. Sistema oferece "Simulador de Configurações"
  2. Sistema mostra exemplos práticos:
    • "Se usuário reservar hoje às 14h para amanhã às 10h: PERMITIDO"
    • "Se usuário cancelar 1h antes: PENALIDADE de 50%"
  3. Admin ajusta configurações conforme simulação
  4. Retorna ao passo 7

12a. Configuração afeta reservas existentes

  1. Sistema detecta reservas futuras afetadas
  2. Sistema exibe aviso: "X reservas serão impactadas"
  3. Sistema oferece opções:
    • Aplicar apenas para novas reservas
    • Aplicar para todas (incluindo existentes)
  4. Admin escolhe
  5. Sistema aplica conforme escolha

Fluxos de Exceção ​

E1. Mudança crítica em horário de alta demanda

  1. Sistema detecta tentativa de mudança radical (ex: reduzir tempo de partida de 60 para 30 min)
  2. Sistema exibe alerta de segurança
  3. Sistema solicita confirmação adicional
  4. Admin deve justificar mudança
  5. Sistema registra justificativa em auditoria
  6. Continua no passo 9

Regras de Negócio ​

  • RN-ARENA-006: Duração de partida deve estar entre 20-120 minutos
  • RN-ARENA-007: Tolerância de atraso máxima: 15 minutos
  • RN-ARENA-008: Penalidade por no-show máxima: 100% do valor
  • RN-ARENA-009: Antecedência máxima para reserva: 90 dias
  • RN-ARENA-010: Configurações não afetam partidas em andamento
  • RN-ARENA-011: Mudanças críticas requerem justificativa e auditoria

Requisitos Relacionados ​

  • RF-ARENA-004 (Configuração Operacional da Arena)
  • RF-AGENDA-004 (Cancelamento, No-show, Atraso)

UC-COURT: Gestão de Quadras ​

UC-COURT-01: Cadastrar Quadra ​

Prioridade: MVP
Ator Principal: Arena Owner, Arena Manager
Atores Secundários: -
Pré-condições:

  • Arena deve estar cadastrada
  • Usuário deve ter permissão court:create:tenant

Pós-condições:

  • Quadra cadastrada e vinculada à arena
  • Quadra disponível para reservas
  • Zona de acesso configurada

Trigger: Admin acessa "Adicionar Quadra" no módulo de quadras

Fluxo Principal ​

  1. Admin acessa módulo de quadras da arena

  2. Sistema exibe lista de quadras existentes (se houver)

  3. Admin clica em "Adicionar Quadra"

  4. Sistema exibe formulário:

    Dados Básicos:

    • Nome/Número da quadra (ex: "Quadra 1", "Central")
    • Descrição
    • Modalidade principal (Beach Tennis, Padel, Tênis, Futsal, Vôlei)

    Características Físicas:

    • Dimensões (comprimento x largura em metros)
    • Cobertura? (Sim/Não)
    • Tipo de piso (Areia, Grama Sintética, Saibro, Cimento, Madeira)
    • Iluminação artificial? (Sim/Não)
    • Qualidade da iluminação (1-5 estrelas)

    Recursos:

    • Placar eletrônico? (Sim/Não)
    • Câmeras de gravação? (Sim/Não) - Quantidade
    • Sonorização? (Sim/Não)
    • Arquibancada? (Sim/Não) - Capacidade
    • Rede divisória central? (Sim/Não)

    Capacidade:

    • Número de jogadores simultâneos (ex: 4 para beach tennis duplas)
    • Capacidade de espectadores

    Operacional:

    • Status inicial (Disponível, Em Manutenção, Inativa)
    • Zona de acesso (selecionar zona)
    • Prioridade de uso (1-10)

  5. Admin preenche formulário

  6. Sistema valida dados:

    • Nome único na arena
    • Modalidade compatível com dimensões
    • Capacidade coerente com modalidade

  7. Sistema cria registro de Court no Courts Context

  8. Sistema vincula quadra à Zone selecionada

  9. Sistema cria CourtSchedule com horários de funcionamento da arena

  10. Sistema pergunta: "Deseja configurar regras específicas desta quadra?"

  11. SE Admin confirma:

    • Sistema redireciona para UC-COURT-03 (Configurar Regras de Quadra)

  12. SENÃO:

    • Sistema aplica regras padrão da arena

  13. Sistema exibe mensagem de sucesso

  14. Sistema atualiza lista de quadras

Resultado: Quadra cadastrada e disponível para uso

Fluxos Alternativos ​

6a. Nome de quadra duplicado

  1. Sistema exibe erro "Quadra com este nome já existe"
  2. Sistema sugere nome alternativo (ex: "Quadra 1.1")
  3. Admin altera nome
  4. Retorna ao passo 6

6b. Dimensões incompatíveis com modalidade

  1. Sistema detecta incompatibilidade (ex: quadra beach tennis com 30x15m)
  2. Sistema exibe aviso: "Dimensões atípicas para Beach Tennis (padrão: 16x8m)"
  3. Sistema pergunta se quer continuar
  4. SE Admin confirma:
    • Sistema registra exceção
    • Continua no passo 7
  5. SENÃO:
    • Retorna ao passo 4

10a. Admin quer cadastrar múltiplas quadras similares

  1. Sistema oferece opção "Duplicar quadra"
  2. Sistema copia configurações da quadra atual
  3. Sistema gera novo nome automaticamente (ex: Quadra 2, 3, 4...)
  4. Admin ajusta apenas diferenças
  5. Retorna ao passo 7 para cada quadra

Fluxos de Exceção ​

E1. Limite de quadras do plano atingido

  1. Sistema detecta limite de quadras do tenant/plano
  2. Sistema exibe erro "Limite de quadras atingido (X/Y quadras)"
  3. Sistema oferece upgrade de plano
  4. Termina caso de uso

E2. Zona de acesso não configurada

  1. Sistema detecta que não há zonas criadas
  2. Sistema oferece criar zona "COURTS" automaticamente
  3. Admin aceita
  4. Sistema cria zona padrão
  5. Retorna ao passo 8

Regras de Negócio ​

  • RN-COURT-001: Nome/número da quadra deve ser único na arena
  • RN-COURT-002: Quadra deve pertencer a exatamente uma zona de acesso
  • RN-COURT-003: Status "Disponível" permite reservas, "Manutenção" e "Inativa" não
  • RN-COURT-004: Dimensões padrão por modalidade:
    • Beach Tennis: 16x8m
    • Padel: 20x10m
    • Tênis: 23,77x10,97m
    • Futsal: 40x20m
    • Vôlei: 18x9m
  • RN-COURT-005: Prioridade influencia alocação automática (maior prioridade = preferência)

Requisitos Relacionados ​

  • RF-QUADRA-001 (Cadastro de Quadras)
  • RF-ARENA-002 (Cadastro de Áreas Físicas)
  • RF-ARENA-003 (Cadastro de Zonas de Acesso)

UC-COURT-02: Alterar Status da Quadra ​

Prioridade: MVP
Ator Principal: Arena Manager, Receptionist
Atores Secundários: Notification Service
Pré-condições:

  • Quadra deve existir
  • Usuário deve ter permissão court:update:tenant

Pós-condições:

  • Status da quadra atualizado
  • Reservas futuras afetadas (se necessário)
  • Usuários notificados (se aplicável)

Trigger: Operador precisa marcar quadra em manutenção ou reativá-la

Fluxo Principal ​

  1. Operador acessa visualização da quadra
  2. Sistema exibe status atual da quadra
  3. Operador clica em "Alterar Status"
  4. Sistema exibe modal com opções:
    • DISPONÍVEL: Quadra operacional e disponível para reservas
    • EM MANUTENÇÃO: Temporariamente indisponível (com data prevista de retorno)
    • INATIVA: Permanentemente desabilitada
    • RESERVADA PARA EVENTO: Bloqueada para evento específico
  5. Operador seleciona novo status
  6. SE status = EM MANUTENÇÃO:
    • Sistema solicita:
      • Motivo da manutenção (goteira, iluminação, piso danificado, etc)
      • Data/hora prevista de retorno
      • Informações adicionais (opcional)
  7. SE status = INATIVA:
    • Sistema solicita:
      • Motivo da desativação
      • Desativação permanente ou temporária?
  8. Sistema valida mudança de status
  9. Sistema verifica se há reservas futuras afetadas
  10. SE houver reservas afetadas:
    • Sistema lista reservas afetadas
    • Sistema exibe opções:
      • Cancelar reservas e reembolsar
      • Realocar para outra quadra disponível
      • Manter e notificar usuários sobre mudança
    • Operador escolhe ação
  11. Sistema atualiza Court.status
  12. Sistema registra em CourtStatusHistory
  13. Sistema executa ações sobre reservas (conforme escolha do passo 10)
  14. Sistema envia notificações aos usuários afetados
  15. Sistema atualiza disponibilidade na agenda
  16. Sistema exibe mensagem de sucesso

Resultado: Status da quadra atualizado

Fluxos Alternativos ​

6a. Manutenção emergencial (sem previsão de retorno)

  1. Operador não informa data de retorno
  2. Sistema marca como "Data a definir"
  3. Sistema envia alerta para gestor
  4. Continua no passo 9

10a. Nenhuma reserva afetada

  1. Sistema confirma que não há impactos
  2. Pula para passo 11

10b. Operador escolhe realocar reservas

  1. Sistema busca quadras alternativas com horários compatíveis
  2. Sistema exibe sugestões de realocação
  3. SE houver quadras disponíveis:
    • Sistema realoca automaticamente
    • Sistema notifica usuários sobre mudança
  4. SENÃO:
    • Sistema força cancelamento
    • Sistema informa usuários e oferece reembolso

16a. Operador reativa quadra após manutenção

  1. Operador muda status de EM MANUTENÇÃO para DISPONÍVEL
  2. Sistema registra data/hora de retorno
  3. Sistema calcula tempo de indisponibilidade
  4. Sistema libera quadra para novas reservas
  5. Sistema notifica usuários em lista de espera

Fluxos de Exceção ​

E1. Tentativa de desativar única quadra operacional

  1. Sistema detecta que é a única quadra disponível
  2. Sistema exibe erro crítico: "Não é possível desativar a única quadra operacional"
  3. Sistema sugere cadastrar mais quadras ou adiar desativação
  4. Termina caso de uso

E2. Falha ao notificar usuários

  1. Sistema completa alteração de status
  2. Sistema registra falha no envio de notificações
  3. Sistema adiciona notificações à fila de retry
  4. Sistema exibe alerta ao operador: "Usuários serão notificados em breve"

Regras de Negócio ​

  • RN-COURT-006: Arena deve ter ao menos 1 quadra DISPONÍVEL ou EM MANUTENÇÃO
  • RN-COURT-007: Quadra INATIVA não aparece em buscas de reserva
  • RN-COURT-008: Quadra EM MANUTENÇÃO bloqueia novas reservas mas pode manter existentes
  • RN-COURT-009: Usuários afetados devem ser notificados em até 5 minutos
  • RN-COURT-010: Mudanças de status são auditadas com timestamp e usuário responsável

Requisitos Relacionados ​

  • RF-QUADRA-008 (Estado da Quadra em Tempo Real)
  • RF-AGENDA-004 (Cancelamento de reservas)
  • RF-COMUN-001 (Notificações)

UC-COURT-03: Configurar Regras de Quadra ​

Prioridade: MVP
Ator Principal: Arena Manager
Atores Secundários: -
Pré-condições:

  • Quadra deve estar cadastrada
  • Usuário deve ter permissão court:update:tenant

Pós-condições:

  • Regras de uso configuradas
  • Restrições aplicadas em reservas
  • Regras exibidas aos usuários

Trigger: Gestor acessa "Configurar Regras" de uma quadra específica

Fluxo Principal ​

  1. Gestor acessa detalhes da quadra

  2. Sistema exibe aba "Regras de Uso"

  3. Gestor clica na aba

  4. Sistema exibe formulário de configuração:

    Regras de Uso Geral:

    • Texto livre com regras obrigatórias (ex: "Proibido uso de chuteira com trava")
    • Aceite de termos obrigatório? (Sim/Não)

    Restrições por Nível de Jogador:

    • Nível recomendado (Iniciante, Intermediário, Avançado, Profissional)
    • Restringir uso por nível? (Sim/Não)

    Restrições por Gênero:

    • Perfil de gênero (Misto, Masculino, Feminino, Horários Específicos)
    • SE Horários Específicos:
      • Configurar grade semanal de horários por gênero

    Tipos de Jogo Permitidos:

    • Simples (1x1)
    • Duplas (2x2)
    • Trio (3x3)
    • Quantidade customizada
    • Aula (professor + alunos)

    Prioridades de Uso:

    • Mensalistas têm prioridade? (Sim/Não)
    • Horários exclusivos para aulas? (Configurar grade)
    • Horários exclusivos para eventos? (Configurar grade)
    • Horários de pico com regras especiais? (Configurar)

    Regras de Permanência:

    • Tempo máximo de jogo contínuo (minutos)
    • Permitir renovação de horário? (Sim/Não)
    • Limite de renovações consecutivas

  5. Gestor configura regras desejadas

  6. Sistema valida configurações:

    • Regras não conflitantes
    • Horários sem gaps
    • Texto de regras não vazio se aceite obrigatório

  7. Sistema exibe prévia de como regras serão exibidas ao usuário

  8. Gestor confirma

  9. Sistema salva regras em CourtRules

  10. Sistema vincula regras à Court

  11. Sistema registra auditoria de configuração

  12. Sistema atualiza motor de validação de reservas

  13. Sistema exibe mensagem de sucesso

Resultado: Regras de quadra configuradas e ativas

Fluxos Alternativos ​

4a. Gestor quer copiar regras de outra quadra

  1. Sistema oferece opção "Copiar regras de..."
  2. Sistema lista outras quadras da arena
  3. Gestor seleciona quadra origem
  4. Sistema copia configurações
  5. Gestor ajusta diferenças
  6. Retorna ao passo 5

7a. Gestor quer testar regras

  1. Sistema oferece "Simulador de Reserva"
  2. Gestor informa cenário:
    • Tipo de usuário (mensalista, avulso)
    • Nível (iniciante, avançado)
    • Gênero
    • Dia/horário desejado
  3. Sistema simula validação
  4. Sistema exibe resultado: PERMITIDO ou BLOQUEADO (com motivo)
  5. Gestor ajusta regras conforme teste
  6. Retorna ao passo 5

12a. Regras conflitam com reservas existentes

  1. Sistema detecta X reservas futuras que violam novas regras
  2. Sistema exibe alerta: "X reservas existentes violam novas regras"
  3. Sistema oferece opções:
    • Manter reservas existentes (exceção)
    • Cancelar reservas conflitantes
  4. Gestor escolhe
  5. Sistema aplica conforme escolha

Fluxos de Exceção ​

E1. Tentativa de criar regra impossível de satisfazer

  1. Sistema detecta regra que tornaria quadra inutilizável (ex: nenhum horário disponível)
  2. Sistema exibe erro crítico: "Configuração tornaria quadra indisponível 100% do tempo"
  3. Sistema bloqueia salvamento
  4. Gestor deve ajustar regras
  5. Retorna ao passo 5

Regras de Negócio ​

  • RN-COURT-011: Regras de uso devem ser claras e objetivas
  • RN-COURT-012: Aceite de termos deve ser rastreável (LGPD)
  • RN-COURT-013: Restrições por gênero devem respeitar legislação vigente
  • RN-COURT-014: Prioridade de mensalistas não pode bloquear 100% dos horários
  • RN-COURT-015: Regras aplicam-se a reservas futuras, não retroativas

Requisitos Relacionados ​

  • RF-QUADRA-005 (Regras de Uso de Quadra)
  • RF-QUADRA-002 (Perfil de Quadra por Nível)
  • RF-QUADRA-003 (Perfil de Quadra por Gênero)
  • RF-QUADRA-006 (Prioridade de Uso por Dia da Semana)

UC-BOOK: Reservas e Agendamento ​

UC-BOOK-01: Buscar Disponibilidade de Quadra ​

Prioridade: MVP
Ator Principal: Player, Receptionist
Atores Secundários: -
Pré-condições:

  • Usuário deve estar autenticado
  • Arena deve ter pelo menos 1 quadra disponível

Pós-condições:

  • Lista de horários disponíveis exibida
  • Filtros aplicados conforme preferências

Trigger: Usuário acessa tela de reservas

Fluxo Principal ​

  1. Usuário acessa módulo de reservas
  2. Sistema exibe interface de busca com filtros:
    • Data (calendário)
    • Período (Manhã, Tarde, Noite, Todos)
    • Modalidade (Beach Tennis, Padel, Tênis, etc)
    • Tipo de quadra (Coberta, Descoberta)
    • Número de jogadores
    • Nível desejado (Iniciante, Intermediário, Avançado)
  3. Sistema pré-preenche filtros com preferências salvas do usuário (se houver)
  4. Usuário ajusta filtros conforme desejo
  5. Usuário clica em "Buscar"
  6. Sistema consulta CourtSchedule e Booking para disponibilidade real
  7. Sistema aplica regras de negócio:
    • Verifica restrições de nível da quadra vs nível do usuário
    • Verifica restrições de gênero
    • Verifica prioridades (mensalista vs avulso)
    • Aplica antecedência mínima/máxima
  8. Sistema agrupa disponibilidade por quadra
  9. Sistema calcula preço por horário (se aplicável)
  10. Sistema exibe grid de disponibilidade:
    • Eixo X: Horários (intervalos de 30min ou 1h)
    • Eixo Y: Quadras
    • Células verdes: Disponível
    • Células amarelas: Quase esgotado (última vaga)
    • Células cinzas: Indisponível
    • Células azuis: Requer autorização (nível incompatível)
  11. Sistema exibe legenda de cores
  12. Usuário pode ajustar filtros e repetir busca

Resultado: Disponibilidade exibida para seleção

Fluxos Alternativos ​

6a. Nenhuma quadra disponível nos critérios

  1. Sistema exibe mensagem "Nenhum horário disponível para os filtros selecionados"
  2. Sistema sugere alternativas:
    • Expandir período de busca
    • Flexibilizar nível de jogador
    • Escolher outra data
    • Entrar na fila de espera
  3. Usuário ajusta filtros ou opta por fila
  4. Retorna ao passo 5

7a. Usuário não atende pré-requisitos de alguma quadra

  1. Sistema exibe quadras mesmo assim mas marca como "Requer Autorização"
  2. Sistema exibe tooltip explicando motivo (ex: "Quadra para nível avançado")
  3. SE usuário tenta reservar:
    • Sistema solicita justificativa ou autorização de gestor
    • Gestor aprova ou nega
    • SE aprovado: prossegue com reserva

10a. Usuário quer visualização em lista (não grid)

  1. Sistema oferece toggle "Visualizar como Lista"
  2. Sistema exibe horários em formato lista:
    • Quadra X - 14:00-15:00 - R$ 100 - [Reservar]
    • Quadra Y - 14:00-15:00 - R$ 120 - [Reservar]
  3. Usuário pode ordenar por preço, quadra, horário

12a. Usuário quer salvar busca como favorita

  1. Sistema oferece "Salvar esses filtros"
  2. Usuário nomeia filtro (ex: "Quinta à noite")
  3. Sistema salva em SavedSearch
  4. Próximas vezes, usuário pode carregar filtro rapidamente

Fluxos de Exceção ​

E1. Sistema sobrecarregado (horário de pico)

  1. Sistema detecta alta concorrência
  2. Sistema exibe aviso: "Muitos usuários buscando, aguarde..."
  3. Sistema implementa fila de requisições (rate limiting)
  4. Sistema processa busca assim que possível
  5. Sistema exibe resultados (pode estar desatualizado)
  6. Sistema sugere atualizar busca

E2. Dados de disponibilidade inconsistentes

  1. Sistema detecta inconsistência (ex: quadra marcada disponível mas com reserva)
  2. Sistema registra erro em logs
  3. Sistema força sincronização
  4. Sistema exibe aviso ao usuário: "Disponibilidade pode estar desatualizada, tente novamente"

Regras de Negócio ​

  • RN-BOOK-001: Busca considera apenas quadras com status DISPONÍVEL
  • RN-BOOK-002: Horários exibidos respeitam antecedência mínima/máxima da arena
  • RN-BOOK-003: Preços podem variar por quadra, horário (pico) e tipo de usuário
  • RN-BOOK-004: Disponibilidade atualizada em tempo real
  • RN-BOOK-005: Mensalistas veem prioridade em horários exclusivos
  • RN-BOOK-006: Busca deve retornar resultado em < 3 segundos

Requisitos Relacionados ​

  • RF-AGENDA-001 (Agenda Unificada)
  • RF-AGENDA-002 (Reserva de Quadra)
  • RNF-PERF-001 (Tempo de resposta < 3s)

UC-BOOK-02: Criar Reserva ​

Prioridade: MVP
Ator Principal: Player, Receptionist
Atores Secundários: Payment Gateway, Notification Service
Pré-condições:

  • Usuário deve estar autenticado
  • Quadra deve estar disponível no horário
  • Usuário deve atender pré-requisitos da quadra

Pós-condições:

  • Reserva criada com status CONFIRMED ou PENDING_PAYMENT
  • Pagamento processado (se aplicável)
  • Quadra bloqueada para o horário
  • Usuário notificado

Trigger: Usuário seleciona horário disponível e clica em "Reservar"

Fluxo Principal ​

  1. Usuário seleciona quadra e horário desejado no grid de disponibilidade
  2. Sistema valida seleção:
    • Horário ainda disponível (revalida em tempo real)
    • Usuário atende requisitos da quadra
    • Usuário não excede limite de reservas simultâneas
  3. Sistema exibe modal de confirmação:
    • Quadra: Quadra 1
    • Data/Hora: 12/01/2026 - 14:00 às 15:00
    • Duração: 60 minutos
    • Modalidade: Beach Tennis - Duplas (2x2)
    • Valor: R$ 120,00
    • Política de cancelamento: Cancelamento gratuito até 2h antes
  4. Sistema oferece opções adicionais:
    • Convidar outros jogadores (para formar dupla/time)
    • Adicionar observações
    • Solicitar equipamentos (bolas, rede, etc) [se disponível]
  5. Usuário confirma reserva
  6. SE reserva requer pagamento antecipado:
    • Sistema exibe opções de pagamento:
      • Cartão de crédito/débito
      • PIX
      • Wallet/Créditos da arena
      • Pacote/Mensalidade
    • Usuário seleciona método
    • Sistema processa pagamento via Payment Gateway
    • Sistema aguarda confirmação (webhook ou polling)
    • SE pagamento confirmado:
      • Continua no passo 8
    • SENÃO:
      • Sistema exibe erro de pagamento
      • Retorna ao passo 6 ou cancela reserva
  7. SENÃO (pagamento não obrigatório):
    • Sistema marca reserva como CONFIRMED
  8. Sistema cria registro de Booking no Scheduling Context
  9. Sistema bloqueia horário na CourtSchedule
  10. Sistema verifica se há usuários na fila para este horário
  11. SE houver e reserva foi cancelada:
    • Sistema notifica próximo da fila
  12. Sistema envia notificação ao usuário:
    • Email com detalhes da reserva
    • Push notification
    • Add to Calendar (iCal)
  13. SE usuário convidou outros jogadores:
    • Sistema envia convites aos convidados
    • Convites podem aceitar/recusar
  14. Sistema exibe mensagem de sucesso
  15. Sistema oferece opções:
    • Ver minha agenda
    • Convidar amigos
    • Compartilhar nas redes sociais

Resultado: Reserva confirmada e quadra bloqueada

Fluxos Alternativos ​

2a. Horário foi reservado por outro usuário (race condition)

  1. Sistema detecta que horário não está mais disponível
  2. Sistema exibe erro: "Ops! Este horário acabou de ser reservado"
  3. Sistema sugere horários próximos disponíveis
  4. Usuário seleciona alternativa ou cancela
  5. Retorna ao passo 1 se selecionar alternativa

2b. Usuário excede limite de reservas simultâneas

  1. Sistema exibe erro: "Você atingiu o limite de X reservas ativas"
  2. Sistema lista reservas ativas do usuário
  3. Sistema oferece cancelar alguma reserva para liberar
  4. SE usuário cancela uma:
    • Sistema libera reserva antiga
    • Retorna ao passo 1
  5. SENÃO:
    • Termina caso de uso

5a. Usuário não quer pagar agora (se pagamento não obrigatório)

  1. Sistema marca reserva como PENDING_PAYMENT
  2. Sistema define prazo para pagamento (ex: até 1h antes do horário)
  3. Sistema envia lembrete de pagamento pendente
  4. SE pagamento não realizado no prazo:
    • Sistema cancela reserva automaticamente
    • Sistema libera horário
    • Sistema notifica usuário

6a. Usuário tem créditos suficientes na Wallet

  1. Sistema detecta saldo em Wallet
  2. Sistema oferece: "Usar saldo da carteira (R$ X disponível)"
  3. Usuário aceita
  4. Sistema debita valor da carteira
  5. Sistema registra transação
  6. Pula para passo 8

6b. Usuário é mensalista com horários inclusos

  1. Sistema detecta que usuário tem plano mensal com X jogos inclusos
  2. Sistema exibe: "Usar crédito do plano? (Y de X jogos restantes)"
  3. Usuário aceita
  4. Sistema debita 1 jogo do pacote
  5. Sistema registra uso
  6. Pula para passo 8

13a. Convidado recusa convite

  1. Convidado clica em "Recusar" no convite
  2. Sistema notifica usuário que criou reserva
  3. Sistema sugere convidar outra pessoa
  4. Reserva continua válida (não requer todos confirmarem)

Fluxos de Exceção ​

E1. Falha no processamento de pagamento

  1. Sistema recebe erro do gateway
  2. Sistema exibe erro específico ao usuário:
    • "Cartão recusado"
    • "Saldo insuficiente"
    • "Erro na transação, tente novamente"
  3. Sistema oferece tentar outro método
  4. SE usuário tenta novamente:
    • Retorna ao passo 6
  5. SENÃO:
    • Sistema cancela reserva temporária
    • Sistema libera horário
    • Termina caso de uso

E2. Sistema fora do ar durante confirmação

  1. Cliente detecta timeout
  2. Cliente tenta reenviar requisição (idempotência via Idempotency-Key)
  3. Sistema verifica se reserva já foi criada (pela chave)
  4. SE já criada:
    • Sistema retorna reserva existente
    • Sistema não duplica reserva
  5. SENÃO:
    • Sistema processa normalmente

E3. Tentativa de reserva fora do horário permitido

  1. Sistema detecta que horário viola antecedência mínima/máxima
  2. Sistema exibe erro: "Reservas devem ser feitas com X horas de antecedência"
  3. Sistema sugere próximo horário válido
  4. Termina caso de uso

Regras de Negócio ​

  • RN-BOOK-007: Reserva só é confirmada após validação de disponibilidade em tempo real
  • RN-BOOK-008: Pagamento obrigatório para avulsos, opcional para mensalistas
  • RN-BOOK-009: Limite de reservas simultâneas: 3 por usuário
  • RN-BOOK-010: Reserva sem pagamento expira 1h antes do horário
  • RN-BOOK-011: Reserva inclui 5 minutos de preparação antes e depois
  • RN-BOOK-012: Convidados devem aceitar convite até 1h antes do horário
  • RN-BOOK-013: Idempotência: múltiplas requisições com mesma Idempotency-Key geram 1 reserva

Requisitos Relacionados ​

  • RF-AGENDA-002 (Reserva de Quadra)
  • RF-AGENDA-003 (Reserva Avulsa, Day-use, Eventos)
  • RF-CONSUMO-005 (Mensalidades, Pacotes, Avulso)
  • RF-INTEG-003 (Integração com Pagamentos)
  • RNF-PERF-002 (Reserva em < 5 segundos)
  • RNF-SEC-007 (Idempotência em transações)

UC-BOOK-03: Cancelar Reserva ​

Prioridade: MVP
Ator Principal: Player, Receptionist
Atores Secundários: Payment Gateway, Notification Service
Pré-condições:

  • Reserva deve existir e estar com status CONFIRMED ou PENDING_PAYMENT
  • Usuário deve ser dono da reserva ou ter permissão de cancelamento

Pós-condições:

  • Reserva cancelada
  • Horário liberado para outras reservas
  • Reembolso processado (se aplicável)
  • Penalidade aplicada (se aplicável)
  • Usuário notificado

Trigger: Usuário acessa "Minhas Reservas" e seleciona "Cancelar"

Fluxo Principal ​

  1. Usuário acessa "Minhas Reservas"
  2. Sistema exibe lista de reservas ativas
  3. Usuário seleciona reserva que deseja cancelar
  4. Sistema exibe detalhes da reserva
  5. Usuário clica em "Cancelar Reserva"
  6. Sistema calcula:
    • Tempo restante até início da reserva
    • Política de cancelamento aplicável
    • Valor de reembolso (se houver)
    • Penalidade (se houver)
  7. Sistema exibe modal de confirmação:
    • Reserva: Quadra 2 - 14/01/2026 às 10:00
    • Política: Cancelamento gratuito até 2h antes
    • Situação: Você está cancelando com 3 dias de antecedência
    • Reembolso: R$ 120,00 (100%)
    • Penalidade: Nenhuma
  8. SE houver penalidade:
    • Sistema exibe claramente:
      • Valor pago: R$ 120,00
      • Reembolso: R$ 60,00 (50%)
      • Penalidade: R$ 60,00 (50%)
      • Motivo: Cancelamento com menos de 2h de antecedência
  9. Sistema solicita confirmação: "Deseja realmente cancelar?"
  10. Usuário confirma
  11. Sistema solicita motivo do cancelamento (opcional):
    • Imprevisto
    • Condições climáticas
    • Lesão/saúde
    • Conflito de horário
    • Outro (texto livre)
  12. Sistema valida cancelamento
  13. Sistema atualiza Booking.status para CANCELLED
  14. Sistema registra BookingCancellation com motivo e timestamp
  15. Sistema libera horário na CourtSchedule
  16. SE houve pagamento:
    • Sistema calcula reembolso conforme política
    • SE reembolso > 0:
      • Sistema processa reembolso via Payment Gateway
      • Sistema credita em Wallet (se política da arena)
      • Sistema registra transação de reembolso
  17. SE há penalidade:
    • Sistema debita pontos de gamificação (se aplicável)
    • Sistema registra penalidade em histórico
  18. Sistema verifica fila de espera para este horário
  19. SE há usuários na fila:
    • Sistema notifica próximo da fila: "Quadra liberada!"
    • Sistema oferece reserva automática ao primeiro da fila
  20. Sistema envia notificação ao usuário:
    • Confirmação de cancelamento
    • Detalhes do reembolso (se houver)
    • Penalidade aplicada (se houver)
  21. Sistema exibe mensagem de sucesso
  22. Sistema sugere reservar outro horário

Resultado: Reserva cancelada e horário liberado

Fluxos Alternativos ​

5a. Usuário quer remarcar em vez de cancelar

  1. Sistema oferece opção "Remarcar" ao lado de "Cancelar"
  2. SE usuário clica em Remarcar:
    • Sistema redireciona para UC-BOOK-04 (Remarcar Reserva)
    • Termina caso de uso

7a. Cancelamento fora do prazo (sem reembolso)

  1. Sistema exibe aviso crítico:
    • "Atenção: Cancelamento tardio"
    • "Prazo de cancelamento gratuito expirou"
    • "Reembolso: R$ 0,00 (0%)"
    • "Penalidade: 100% do valor (no-show)"
  2. Sistema enfatiza consequências
  3. Sistema sugere alternativa: "Deseja transferir a reserva para alguém?"
  4. SE usuário aceita transferir:
    • Sistema redireciona para UC-BOOK-05 (Transferir Reserva)
  5. SENÃO:
    • Usuário confirma cancelamento mesmo assim
    • Continua no passo 10

16a. Reembolso via crédito na arena (política)

  1. Sistema detecta que política de reembolso é via crédito
  2. Sistema credita valor na Wallet do usuário
  3. Sistema notifica: "R$ X creditado na sua carteira"
  4. Sistema define validade do crédito (ex: 90 dias)

16b. Falha no processamento de reembolso

  1. Sistema registra erro
  2. Sistema marca reembolso como PENDING
  3. Sistema adiciona à fila de retry
  4. Sistema notifica usuário: "Reembolso será processado em até 5 dias úteis"
  5. Sistema alerta equipe financeira

19a. Nenhum usuário na fila

  1. Sistema apenas libera horário
  2. Horário volta a aparecer como disponível na agenda

Fluxos de Exceção ​

E1. Tentativa de cancelar reserva já iniciada

  1. Sistema detecta que horário da reserva já passou
  2. Sistema exibe erro: "Não é possível cancelar reserva já iniciada"
  3. Sistema sugere: "Entre em contato com a recepção"
  4. Termina caso de uso

E2. Tentativa de cancelamento duplicada (idempotência)

  1. Sistema detecta que reserva já está cancelada
  2. Sistema exibe mensagem: "Esta reserva já foi cancelada anteriormente"
  3. Sistema exibe detalhes do cancelamento anterior
  4. Termina caso de uso

E3. Cancelamento por força maior (sistema)

  1. Sistema detecta que quadra ficou indisponível (ex: manutenção emergencial)
  2. Sistema cancela reserva automaticamente
  3. Sistema processa reembolso integral (100%)
  4. Sistema isenta penalidades
  5. Sistema envia notificação explicando situação
  6. Sistema oferece realocação automática se houver horário similar

Regras de Negócio ​

  • RN-BOOK-014: Cancelamento gratuito até X horas antes (configurável por arena)
  • RN-BOOK-015: Cancelamento tardio implica penalidade de Y% (configurável)
  • RN-BOOK-016: No-show (não cancelar e não comparecer) implica penalidade de 100%
  • RN-BOOK-017: Reembolso processado em até 5 dias úteis (cartão) ou imediato (wallet)
  • RN-BOOK-018: Usuário com 3 no-shows consecutivos pode ser suspenso temporariamente
  • RN-BOOK-019: Cancelamento por força maior (arena) isenta penalidades
  • RN-BOOK-020: Créditos de cancelamento têm validade de 90 dias

Requisitos Relacionados ​

  • RF-AGENDA-004 (Cancelamento, No-show, Atraso)
  • RF-WALLET-003 (Transações de crédito/débito)
  • RF-FILA-001 (Fila de uso de quadra)
  • RF-COMUN-001 (Notificações)

UC-BOOK-04: Fazer Check-in ​

Prioridade: MVP
Ator Principal: Player
Atores Secundários: Access Control System, IoT Device
Pré-condições:

  • Usuário deve ter reserva confirmada para horário próximo
  • Check-in deve estar dentro da janela permitida (ex: 5 min antes até início)

Pós-condições:

  • Check-in registrado
  • Acesso à quadra liberado
  • Contagem de tempo de jogo iniciada
  • Status da reserva atualizado

Trigger: Usuário chega na arena e abre o app ou se aproxima da quadra

Fluxo Principal ​

  1. Usuário chega na arena 5 minutos antes do horário
  2. Sistema detecta proximidade via:
    • GPS/Geofence do app
    • Beacon Bluetooth na quadra
    • QR Code na entrada da quadra
  3. Sistema identifica reservas ativas do usuário para horário atual
  4. Sistema exibe notificação: "Sua reserva está pronta! Faça check-in"
  5. Usuário toca na notificação ou abre o app
  6. Sistema exibe modal de check-in:
    • Reserva: Quadra 2 - Hoje às 14:00
    • Tempo restante: 3 minutos para início
    • Botão: [Fazer Check-in Agora]
  7. Usuário clica no botão
  8. Sistema valida:
    • Horário dentro da janela permitida
    • Reserva está confirmada (não cancelada)
    • Usuário é participante da reserva
    • Quadra está disponível (sem partida em andamento)
  9. Sistema cria registro de Check-in no Access Context
  10. Sistema atualiza Booking.status para CHECKED_IN
  11. Sistema registra timestamp exato do check-in
  12. Sistema libera acesso físico:
    • Envia comando ao Access Control System (Ziggy)
    • Libera catraca/porta para zona da quadra
    • Ativa luz verde ou indicador visual na quadra
  13. Sistema inicia contagem de tempo de jogo
  14. Sistema notifica outros participantes da reserva:
    • "Fulano fez check-in, a partida vai começar!"
  15. SE todos participantes fizeram check-in:
    • Sistema marca partida como READY_TO_START
    • Sistema pode iniciar gravação automática (se câmeras configuradas)
  16. Sistema exibe na tela:
    • "Check-in realizado com sucesso!"
    • "Quadra 2 liberada"
    • "Tempo de jogo: 60 minutos"
    • "Bom jogo! 🎾"
  17. Sistema atualiza dashboard operacional
  18. Sistema registra presença em estatísticas do jogador

Resultado: Check-in confirmado e acesso liberado

Fluxos Alternativos ​

2a. Usuário faz check-in manual via QR Code

  1. Usuário vê QR Code na entrada da quadra
  2. Usuário abre câmera do app e escaneia QR Code
  3. Sistema identifica quadra e horário
  4. Sistema lista reservas do usuário para esta quadra
  5. Usuário seleciona reserva correta
  6. Pula para passo 8

2b. Check-in via tablet na quadra (self-service)

  1. Usuário acessa tablet fixo na quadra
  2. Sistema exibe lista de reservas do horário atual
  3. Usuário busca seu nome ou escaneia pulseira/QR code
  4. Sistema identifica usuário
  5. Pula para passo 8

2c. Check-in assistido pela recepção

  1. Usuário informa na recepção que vai jogar
  2. Recepcionista busca reserva no sistema
  3. Recepcionista confirma check-in no painel operacional
  4. Sistema executa passo 9 em diante

8a. Check-in fora da janela de tempo

  1. Sistema detecta que ainda faltam mais de 15 minutos para o horário
  2. Sistema exibe mensagem: "Check-in permitido a partir das 13:45"
  3. Sistema oferece: "Deseja entrar na fila ou aguardar?"
  4. SE usuário aguarda:
    • Sistema envia notificação quando janela abrir
    • Termina caso de uso
  5. SE usuário quer entrar na fila:
    • Sistema redireciona para UC-QUEUE-01

8b. Atraso além da tolerância

  1. Sistema detecta que horário da reserva já passou + tolerância (ex: 5 min)
  2. Sistema exibe aviso: "Você está atrasado! Sua reserva pode ter sido liberada"
  3. Sistema verifica se quadra foi liberada para fila
  4. SE quadra foi liberada:
    • Sistema exibe: "Quadra já foi alocada para outro jogador"
    • Sistema registra no-show
    • Sistema aplica penalidade
    • Termina caso de uso
  5. SENÃO (quadra ainda está reservada):
    • Sistema permite check-in tardio
    • Sistema ajusta tempo de jogo (reduz conforme atraso)
    • Sistema notifica: "Tempo de jogo reduzido para X minutos devido ao atraso"
    • Continua no passo 9

14a. Outros participantes não chegaram

  1. Sistema detecta que apenas 1 de 4 jogadores fez check-in
  2. Sistema aguarda 5 minutos
  3. Sistema envia lembrete aos ausentes: "Sua partida está começando!"
  4. SE após 5 minutos ninguém mais chegou:
    • Sistema pergunta ao jogador presente: "Deseja jogar sozinho ou cancelar?"
    • SE jogador quer jogar solo:
      • Sistema permite (treino individual)
      • Sistema não marca no-show para quem chegou
    • SE jogador cancela:
      • Sistema cancela partida
      • Sistema registra no-show para ausentes
      • Sistema não penaliza quem fez check-in

Fluxos de Exceção ​

E1. Sistema de controle de acesso offline

  1. Sistema detecta falha na comunicação com Ziggy
  2. Sistema registra check-in normalmente no banco
  3. Sistema envia comando para fila de retry
  4. Sistema notifica recepção: "Liberar acesso manualmente"
  5. Recepcionista libera catraca fisicamente
  6. Sistema sincroniza quando conectividade restaurada

E2. Tentativa de check-in sem reserva

  1. Sistema detecta que usuário não tem reserva ativa
  2. Sistema exibe: "Você não tem reserva para este horário"
  3. Sistema oferece opções:
    • Ver minhas reservas
    • Fazer nova reserva
    • Entrar na fila (se houver vaga)
  4. Usuário seleciona opção
  5. Sistema redireciona conforme escolha

E3. Check-in duplicado (já feito)

  1. Sistema detecta que check-in já foi registrado
  2. Sistema exibe: "Check-in já realizado às 13:58"
  3. Sistema exibe status atual: "Partida em andamento (15 min decorridos)"
  4. Sistema oferece: "Ver tempo restante"
  5. Termina caso de uso

E4. Quadra ocupada por partida anterior

  1. Sistema detecta que partida anterior ainda não terminou
  2. Sistema exibe: "Quadra ainda ocupada, aguarde..."
  3. Sistema estima tempo de liberação
  4. Sistema notifica quando quadra for liberada
  5. Sistema pode ajustar horário de início (sem prejudicar usuário)

Regras de Negócio ​

  • RN-ACCESS-001: Check-in permitido de 15 minutos antes até horário de início
  • RN-ACCESS-002: Atraso tolerado: até 5 minutos após início
  • RN-ACCESS-003: Atraso > 5 minutos libera quadra para fila (se houver)
  • RN-ACCESS-004: Check-in registra presença física e inicia contagem
  • RN-ACCESS-005: Sem check-in = no-show (penalidade aplicada)
  • RN-ACCESS-006: Check-in de todos participantes inicia gravação automática (se disponível)
  • RN-ACCESS-007: Check-in tardio reduz tempo de jogo proporcionalmente

Requisitos Relacionados ​

  • RF-ACESSO-001 (Check-in/Check-out)
  • RF-ACESSO-002 (Check-in por Quadra/Aula)
  • RF-INTEG-001 (Sistema de Acesso - Ziggy)
  • RF-IOT-002 (Tablet de Quadra)
  • RF-VIDEO-001 (Captura de Vídeo)

UC-QUEUE: Fila e Alocação Dinâmica ​

(Continuará com casos de uso de Fila, Usuários, Instrutores, Partidas, Eventos, Comércio, Wallet, Gamificação, Mídia, IoT, Patrocínio, Comunicação e Relatórios...)

Matriz de Rastreabilidade ​

Casos de Uso por Prioridade ​

PrioridadeTotalPercentual
MVP35+~55%
Fase 2 (P2)20+~30%
Fase 3 (P3)10+~15%

Mapeamento RF → UC ​

Requisito FuncionalCasos de Uso
RF-ARENA-001UC-ARENA-01
RF-ARENA-004UC-ARENA-02
RF-QUADRA-001UC-COURT-01
RF-QUADRA-005UC-COURT-03
RF-QUADRA-008UC-COURT-02
RF-AGENDA-002UC-BOOK-01, UC-BOOK-02
RF-AGENDA-004UC-BOOK-03
RF-ACESSO-001UC-BOOK-04
RF-USER-001UC-AUTH-02

(Continua...)

Glossário ​

TermoDefinição
Check-inConfirmação de presença física do usuário
No-showNão comparecimento sem cancelamento
IdempotênciaMúltiplas requisições idênticas produzem mesmo resultado
Race ConditionCondição de corrida quando múltiplos usuários acessam simultaneamente
GeofenceÁrea virtual geográfica que dispara eventos
BeaconDispositivo Bluetooth de proximidade
WebhookNotificação HTTP de evento assíncrono
Rate LimitingLimitação de taxa de requisições

Documentos Relacionados ​

Status do Documento: 🚧 Em construção - 15 casos de uso detalhados de 65+ planejados

Próximas Seções a Detalhar:

  • UC-QUEUE (Fila e Alocação)
  • UC-USER (Gestão de Usuários)
  • UC-INSTRUCTOR (Professores e Aulas)
  • UC-MATCH (Jogos e Partidas)
  • UC-EVENT (Eventos)
  • UC-COMMERCE (Consumo e Cobrança)
  • UC-WALLET (Carteira Digital)
  • UC-GAMIF (Gamificação)
  • UC-MEDIA (Vídeo e Mídia)
  • UC-IOT (Dispositivos IoT)
  • UC-SPONSOR (Patrocínio)
  • UC-COMM (Comunicação)
  • UC-REPORT (Relatórios)

Controle de Versões:

VersãoDataAutorAlterações
0.12026-01-09AtlasEstrutura inicial + 15 UCs detalhados (AUTH, ARENA, COURT, BOOK)

"The value of a use case lies not in its existence, but in its ability to drive shared understanding." - Alistair Cockburn