Historias de usuario - NicolasPriVar/ARSW_BackendProyecto GitHub Wiki

🧠 Historias de Usuario – Mente Maestra

🧩 Historia 1: Crear una sesión de juego

Como administrador,
Quiero crear una nueva sesión de juego con un código único,
Para que los jugadores puedan unirse a esa sesión.

Criterios de aceptación:

  • El sistema debe generar un código único de 6 caracteres.
  • El código debe estar disponible durante toda la partida.
  • Los jugadores no pueden unirse a la sesión si ya ha comenzado la primera pregunta.

🧩 Historia 2: Unirse a una sesión como jugador

Como jugador,
Quiero ingresar un código para unirme a una sesión activa,
Para que pueda participar en la trivia.

Criterios de aceptación:

  • El jugador ingresa un nombre visible y el código de sesión.
  • Si el código no existe o expiró, se muestra un mensaje de error.
  • Si el jugador se une exitosamente, debe ver cuántos jugadores están en la sesión.
  • No se requiere autenticación (registro/correo).

🧩 Historia 3: Iniciar la partida desde el lobby

Como administrador,
Quiero iniciar la partida desde el lobby,
Para que los jugadores puedan comenzar a responder las preguntas.

Criterios de aceptación:

  • Solo el administrador ve el botón "Iniciar partida".
  • Al hacer clic, todos los jugadores son redirigidos a la primera pregunta.
  • No se puede volver atrás una vez iniciada.

🧩 Historia 4: Cargar preguntas desde la base de datos

Como sistema,
Quiero obtener las preguntas y respuestas desde la base de datos,
Para que el contenido del juego sea dinámico y configurable.

Criterios de aceptación:

  • Las preguntas se cargan al iniciar la partida.
  • Cada pregunta tiene 4 opciones, con una marcada como correcta.
  • La colección se puede mezclar para cambiar el orden.

🧩 Historia 5: Responder preguntas de selección múltiple

Como jugador,
Quiero seleccionar una opción como respuesta a una pregunta,
Para que se registre mi elección antes del tiempo límite.

Criterios de aceptación:

  • Solo se puede enviar una respuesta por pregunta.
  • El sistema debe confirmar que la respuesta fue recibida.
  • Si el jugador no responde a tiempo, la respuesta se marca como "sin respuesta".
  • Después de responder, no debe poder cambiar su opción.

🧩 Historia 6: Ver resultados de cada pregunta

Como jugador,
Quiero ver cuál era la respuesta correcta
Para que pueda aprender del resultado.

Criterios de aceptación:

  • Se muestra la opción correcta con un color o indicador visual.
  • El jugador puede ver si su respuesta fue correcta o no.

🧩 Historia 7: Finalizar partida y mostrar ganadores

Como sistema,
Quiero mostrar los resultados finales al finalizar la última pregunta,
Para que los jugadores vean su posición y puntaje.

Criterios de aceptación:

  • Se muestra una lista de jugadores ordenada por puntaje.
  • Se destaca al primer, segundo y tercer lugar con medallas.
  • El botón "Volver al inicio" reinicia la experiencia.

🧩 Historia 8: Evitar nombres duplicados

Como sistema,
Quiero evitar que dos jugadores usen el mismo nombre,
Para que no haya confusión durante la partida.

Criterios de aceptación:

  • El sistema verifica si el nombre ya existe al intentar ingresar.
  • Si el nombre ya está en uso, se muestra un mensaje de error.
  • El jugador debe ingresar un nombre diferente.

🧩 Historia 9: Mostrar error si la partida ya comenzó

Como jugador,
Quiero recibir una advertencia si intento ingresar a una partida ya iniciada,
Para que no me quede fuera del flujo del juego.

Criterios de aceptación:

  • Si una partida ya está en curso, no se permite ingresar nuevos jugadores.
  • Se muestra un mensaje claro explicando el motivo.

🧩 Historia 10: Mostrar mensaje de carga al generar código

Como administrador,
Quiero ver un mensaje mientras se genera el código,
Para que sepa que el sistema está trabajando.

Criterios de aceptación:

  • Se muestra un mensaje como "Generando..." mientras se procesa la petición.
  • El botón queda deshabilitado durante el proceso.

🧩 Historia 11: Ver puntaje acumulado

Como jugador,
Quiero ver mi puntaje total durante la partida,
Para que sepa cómo voy frente a los demás.

Criterios de aceptación:

  • El puntaje se actualiza después de cada pregunta.
  • Se muestra en pantalla junto con el nombre y código de partida.

🧩 Historia 12: Calcular puntaje por respuesta correcta

Como sistema,
Quiero sumar puntos a los jugadores que respondan correctamente,
Para que puedan competir por el mejor puntaje.

Criterios de aceptación:

  • Cada respuesta correcta suma 5 puntos.
  • Las respuestas incorrectas o vacías no suman puntos.

🧩 Historia 13: Redirigir al jugador a la pantalla final

Como sistema,
Quiero redirigir automáticamente a los jugadores cuando termina la última pregunta,
Para que vean los resultados finales.

Criterios de aceptación:

  • La redirección ocurre solo cuando no hay más preguntas.
  • Se conserva el código de partida para mostrar el ranking.

🧩 Historia 14: Mostrar confeti en la pantalla de resultados

Como jugador,
Quiero ver una animación de celebración al terminar,
Para que la experiencia sea más divertida.

Criterios de aceptación:

  • Se muestra confeti al iniciar la pantalla de resultados.
  • La animación cubre toda la pantalla.

🧩 Historia 15: Proteger rutas privadas del juego

Como desarrollador,
Quiero asegurar que solo los jugadores que ingresaron correctamente puedan acceder a las rutas del juego,
Para que no se salten pasos importantes como el lobby.

Criterios de aceptación:

  • Las rutas como /lobby, /partida, /fin requieren información previa del usuario.
  • Si se accede sin datos, se redirige al inicio.

🧩 Historia 16: Ver lista de jugadores en el lobby

Como jugador,
Quiero ver quiénes están conectados en el lobby,
Para saber con quién voy a competir.

Criterios de aceptación:

  • Se muestra una lista de nombres en tiempo real.
  • La lista se actualiza automáticamente cada pocos segundos.

🧩 Historia 17: Asignar rol de administrador al ingresar

Como administrador,
Quiero ingresar con un rol especial al generar la partida,
Para tener control sobre la gestión del juego.

Criterios de aceptación:

  • El parámetro rol: admin identifica al administrador.
  • Solo el administrador puede iniciar la partida.

🧩 Historia 18: Validar duplicidad de códigos

Como sistema,
Quiero evitar generar códigos duplicados,
Para que cada partida sea única.

Criterios de aceptación:

  • El sistema verifica que el código no exista antes de usarlo.
  • Si está repetido, genera uno nuevo automáticamente.

🧩 Historia 19: Avanzar automáticamente a la siguiente pregunta

Como sistema,
Quiero avanzar a la siguiente pregunta cuando se acabe el tiempo,
Para que el juego fluya sin intervención manual.

Criterios de aceptación:

  • Cada pregunta tiene un temporizador de 15 segundos.
  • Al llegar a 0, se muestra la siguiente pregunta.
  • Si no hay más preguntas, se termina la partida.

🧩 Historia 20: Ver tiempo restante en cada pregunta

Como jugador,
Quiero ver cuánto tiempo queda para responder,
Para poder decidir rápidamente.

Criterios de aceptación:

  • El contador se muestra en segundos.
  • Se actualiza en tiempo real.

🧩 Historia 21: Mezclar aleatoriamente las opciones

Como jugador,
Quiero que las opciones estén en orden aleatorio,
Para que sea más justo.

Criterios de aceptación:

  • Las opciones se mezclan antes de mostrarse.
  • El orden es consistente durante la pregunta.

🧩 Historia 22: Ver retroalimentación después de responder

Como jugador,
Quiero saber si respondí bien o mal,
Para aprender y mejorar.

Criterios de aceptación:

  • Se muestra un mensaje visual con ✅ o ❌.
  • El feedback aparece justo después de responder.

🧩 Historia 23: Almacenar puntajes en memoria

Como sistema,
Quiero guardar los puntajes en memoria,
Para calcular los resultados al final.

Criterios de aceptación:

  • Se guarda el puntaje por jugador y código de partida.
  • Se elimina al finalizar la sesión.

🧩 Historia 24: Eliminar jugador si se desconecta antes del inicio

Como sistema,
Quiero quitar al jugador del lobby si se va antes de iniciar,
Para tener una lista actualizada.

Criterios de aceptación:

  • Al hacer clic en “Salir”, se elimina el nombre del jugador.
  • La lista se actualiza para los demás.

🧩 Historia 25: Mostrar mensaje si el código no existe

Como jugador,
Quiero recibir un aviso si el código no es válido,
Para no quedarme esperando.

Criterios de aceptación:

  • Se muestra un error si el código ingresado no está activo.
  • El sistema no permite avanzar si el código es inválido.

🧩 Historia 26: Controlar cantidad de preguntas por partida

Como administrador,
Quiero definir cuántas preguntas se usarán en una partida,
Para que el juego se adapte a la duración deseada.

Criterios de aceptación:

  • El sistema permite configurar la cantidad de preguntas (por ejemplo, 5, 10, etc.) antes de iniciar la partida.
  • Las preguntas seleccionadas se eligen aleatoriamente de la base de datos.
  • No se repiten preguntas dentro de una misma sesión.
  • La partida finaliza automáticamente al responder la última pregunta.

🧩 Historia 27: Notificar a los jugadores que el tiempo ha terminado

Como jugador,
Quiero saber cuándo se acabó el tiempo para responder,
Para que no me quede esperando sin saber qué pasó.

Criterios de aceptación:

  • Cuando el tiempo se agota, se muestra un mensaje como “Tiempo terminado” o “Respuesta no enviada”.
  • Las opciones de respuesta se desactivan automáticamente.
  • Se indica visualmente que no se registró respuesta si no se alcanzó a seleccionar.

🧩 Historia 28: Soportar reconexión del jugador antes del inicio

Como jugador,
Quiero poder volver a ingresar al lobby si me desconecto antes de que comience,
Para que no pierda mi lugar.

Criterios de aceptación:

  • El sistema guarda el nombre del jugador mientras la partida no ha iniciado.
  • Si el jugador recarga la página o se desconecta, puede volver a ingresar con el mismo nombre y código.
  • Si se conecta con un nombre diferente, se crea una nueva entrada.
  • La lista del lobby se actualiza en tiempo real según el estado de conexión.

🧩 Historia 29: Prevenir múltiples respuestas desde el frontend

Como desarrollador,
Quiero evitar que un jugador haga clic muchas veces en diferentes opciones,
Para que no haya respuestas duplicadas o erróneas.

Criterios de aceptación:

  • Una vez que el jugador selecciona una opción, todas las demás se deshabilitan.
  • El botón de enviar respuesta queda inactivo tras el primer envío.
  • El sistema ignora respuestas adicionales si ya se envió una.
  • El frontend impide interacciones extra hasta que llegue la siguiente pregunta.

🧩 Historia 30: Soporte para múltiples partidas activas

Como sistema,
Quiero permitir varias partidas simultáneamente,
Para que diferentes grupos puedan jugar sin interferencias.

Criterios de aceptación:

  • Cada código de partida representa una sesión independiente.
  • Las acciones de una partida no afectan otras sesiones.
  • Los jugadores solo pueden acceder a los datos asociados a su código.
  • El sistema puede manejar múltiples partidas sin errores ni cruces de información.