El presente documento constituye la Especificación de Requisitos de Software (SRS) del sistema Minetico, elaborada conforme al estándar IEEE 830-1998 [1]. Su objetivo es describir de forma clara, estructurada y verificable los requisitos funcionales y no funcionales del sistema, estableciendo una base de referencia para el equipo de desarrollo, los evaluadores del proyecto y la comunidad académica involucrada.

El documento está dirigido a los integrantes del equipo de desarrollo, al docente tutor y a todos los actores académicos que participen en la evaluación o mejora del proyecto.

1.2 Alcance

Minetico es una plataforma web interactiva que integra una mascota virtual personalizable con inteligencia artificial basada en modelos de lenguaje de gran escala (LLM), particularmente la familia LLaMA desarrollada por Meta AI [2]. El sistema permite a los usuarios interactuar mediante un chat conversacional y recibir respuestas contextuales sobre el videojuego Minecraft.

Las funcionalidades principales comprenden:

• Interacción conversacional con la mascota virtual a través de un chat inteligente.

• Personalización de la apariencia de la mascota mediante skins desbloqueables.

• Sistema de rachas basado en accesos diarios consecutivos del usuario.

• Sistema de recompensas vinculado al progreso y la actividad del usuario.

• Minijuegos con enfoque educativo relacionados con Minecraft.

• Adaptación del contenido y la dificultad según el nivel acumulado del usuario.

Este documento guarda coherencia con la propuesta conceptual desarrollada en la fase de diseño del proyecto [3], donde Minetico se concibe como una herramienta interactiva orientada al aprendizaje mediante gamificación e inteligencia artificial.

1.3 Personal involucrado

Nombre	Rol	Categoría prof.	Responsabilidades	Contacto
Andrés F. Ardila Neira	Implementador	Est. Ingeniería	Desarrollo e implementación del sistema.	andresf-ardilan@unilibre.edu.co
Duván A. Alarcón Mora	Inv. de recursos	Est. Ingeniería	Búsqueda de información y contactos externos.	duvana-alarconm@unilibre.edu.co
Dilan A. Ayala Lobo	Cohesionador	Est. Ingeniería	Coordinación del equipo y gestión de conflictos.	dilana-ayalal@unilibre.edu.co
Miguel Á. Veloza Soler	Impulsor	Est. Ingeniería	Resolución dinámica de problemas técnicos.	miguela-velozas@unilibre.edu.co
Alonso Pérez Guevara	Docente tutor	Ingeniero / Docente	Supervisión y guía académica del proyecto.	alonso.guevarap@unilibre.edu.co

1.4 Definiciones, acrónimos y abreviaturas

Término	Definición
Minetico	Plataforma web interactiva que integra una mascota virtual inteligente con chat basado en IA, gamificación y personalización orientada al videojuego Minecraft.
Mascota virtual	Representación digital animada que interactúa con el usuario y refleja su actividad dentro del sistema.
LLM (Large Language Model)	Modelo de inteligencia artificial entrenado con grandes volúmenes de texto para comprender y generar lenguaje natural.
LLaMA	Familia de modelos de lenguaje de código abierto desarrollados por Meta AI, utilizados como motor conversacional del sistema [1].
Chat inteligente	Interfaz de comunicación que emplea un LLM para interpretar consultas del usuario y generar respuestas contextuales.
Skin	Apariencia visual personalizable de la mascota virtual; modifica su diseño gráfico sin alterar su funcionamiento.
Gamificación	Aplicación de mecánicas propias de los videojuegos (recompensas, niveles, logros) en entornos no lúdicos para incrementar la motivación del usuario.
Racha	Contador de días consecutivos en los que el usuario accede al sistema; genera recompensas al alcanzar umbrales definidos.
Recompensa	Beneficio virtual otorgado al usuario al cumplir objetivos, mantener rachas o completar actividades.
Minijuego	Actividad interactiva de corta duración integrada en la plataforma con fines educativos o de entretenimiento.
Nivel de usuario	Indicador del progreso acumulado del usuario que puede influir en el contenido o la dificultad presentada por el sistema.
API	Application Programming Interface. Mecanismo que permite la comunicación entre el sistema y el modelo de IA.
SRS	Software Requirements Specification. Documento de Especificación de Requisitos de Software.
IEEE 830	Estándar que define el formato y contenido recomendado para una SRS [4].

1.5 Referencias

Referencias

[1]	IEEE, «IEEE Recommended Practice for Software Requirements Specifications,» IEEE, 1998. [En línea]. Available: https://ieeexplore.ieee.org.
[2]	Meta, «LlamA Documentation: Models and Usage,» Meta, 2025. [En línea]. Available: https://www.llama.com/docs/overview/.
[3]	D. A. A. D. A. A. y. M. Á. V. A. F. Ardila, Diseño Minetico, Bogota D.C: Universidad Libre, 2026.
[4]	G. Aaron, «The Llama 3 Heard of Models,» Meta AI, 2024. [En línea]. Available: https://ai.meta.com/research/publications/the-llama-3-herd-of-models/.
[5]	Minecraft Wiki, «Tutoriales/Términos del juego,» Minecraftt Wiki, 2026. [En línea]. Available: https://minecraft.fandom.com/es/wiki/Tutoriales/Términos_del_juego.
[6]	M. Cifuentes, Papel del Ingeniero de Software, Bogota D.C: Universidad libre, 2026.

1.6 Resumen del documento

El presente documento se organiza en cuatro secciones principales:

• Sección 1 – Introducción: propósito, alcance, equipo, definiciones y referencias.

• Sección 2 – Descripción general: perspectiva del producto, funcionalidades, características de los usuarios, restricciones y dependencias.

• Sección 3 – Requisitos específicos: requisitos funcionales y no funcionales detallados y verificables.

• Sección 4 – Apéndices: glosario ampliado, ejemplos de interacción, mockups, diagramas y referencias bibliográficas.

2. Descripción general

2.1 Perspectiva del producto

Minetico es un sistema independiente basado en una arquitectura cliente-servidor. Se integra con la API del modelo LLaMA [4] para la generación de respuestas conversacionales. La plataforma está concebida como una aplicación web accesible desde cualquier navegador moderno, sin necesidad de instalación adicional por parte del usuario.

El sistema contempla diseño responsivo que garantiza compatibilidad con computadores de escritorio y dispositivos móviles. La comunicación entre cliente y servidor se realiza mediante protocolos seguros (HTTPS y WebSockets).

2.2 Funcionalidad del producto

El sistema ofrece las siguientes capacidades principales:

• Registro e inicio de sesión de usuarios con gestión de perfiles personales.

• Interacción conversacional con la mascota virtual a través de un chat alimentado por un modelo de lenguaje [4].

• Personalización de la mascota mediante selección de skins desbloqueables.

• Sistema de rachas: seguimiento de accesos diarios consecutivos del usuario.

• Sistema de recompensas: otorgamiento de beneficios al alcanzar umbrales de racha o completar actividades.

• Módulo de minijuegos educativos relacionados con el videojuego Minecraft.

• Adaptación del contenido y la dificultad según el nivel acumulado del usuario.

2.3 Características de los usuarios

Atributo	Descripción
Tipo de usuario	Jugadores y aficionados al videojuego Minecraft con interés en aprendizaje interactivo.
Rango de edad	Aproximadamente entre 12 y 25 años.
Nivel educativo	Desde educación básica primaria hasta nivel universitario.
Experiencia tecnológica	Nivel básico a intermedio en uso de navegadores web y aplicaciones interactivas.
Conocimientos previos	Familiaridad básica con Minecraft o alto interés en aprenderlo.
Dispositivos de acceso	Computadores personales y dispositivos móviles con conexión a internet.
Frecuencia de uso	Uso ocasional a diario, con posibilidad de interacción sostenida.
Motivaciones	Aprender mecánicas del juego, mejorar habilidades, entretenimiento y personalización.

2.4 Restricciones

Las siguientes restricciones aplican al sistema en sus versiones iniciales:

• Las respuestas del modelo de IA pueden presentar imprecisiones propias de las limitaciones del modelo LLaMA en entornos con recursos limitados [2].

• En su versión inicial el sistema no incluye generación de imágenes ni análisis de documentos o archivos externos.

• No todas las funcionalidades descritas en este documento estarán disponibles en los primeros prototipos; algunas podrán modificarse o descartarse según avance el desarrollo.

• El módulo de chat con IA requiere conexión a internet para funcionar.

2.5 Suposiciones y dependencias

El correcto funcionamiento del sistema depende de las siguientes condiciones:

• El usuario cuenta con acceso a internet y un navegador web compatible con estándares modernos (HTML5, CSS3, ES6+).

• El modelo LLaMA está correctamente configurado y disponible en el servidor de backend [2].

• El sistema es mantenido y actualizado de forma periódica por el equipo de desarrollo.

• El usuario posee conocimientos básicos de Minecraft o manifiesta interés en aprender sobre el juego.

2.6 Evolución previsible del sistema

Se proyecta que el sistema evolucione de la siguiente manera:

• Incorporación progresiva de las funcionalidades descritas, priorizando las de mayor impacto para el usuario.

• Mejora continua en la calidad y precisión de las respuestas generadas por el modelo de IA [4].

• Implementación de retroalimentación personalizada y adaptativa según el progreso de cada usuario.

• Posible integración de nuevos modelos de IA o servicios externos según los avances tecnológicos disponibles.

3. Requisitos específicos

3.1 Interfaces del sistema

3.1.1 Interfaces de usuario

La interfaz principal presenta la mascota virtual animada como elemento central, acompañada de un indicador de racha diaria, un área de chat interactivo y accesos directos a los módulos del sistema (quiz, personalización, recompensas). El diseño es responsivo y emplea animaciones dinámicas que reflejan el estado de la mascota.

3.1.2 Interfaces de hardware

El sistema no requiere hardware especializado. Opera en cualquier dispositivo (computador o móvil) que cuente con un navegador web moderno y conexión a internet. No se requiere instalación de controladores ni periféricos adicionales.

3.1.3 Interfaces de software

El sistema se apoya en los siguientes componentes de software:

• Base de datos relacional para almacenamiento de usuarios, perfiles y progreso.

• API REST para la comunicación entre frontend y backend.

• API del modelo LLaMA para la generación de respuestas conversacionales [2].

• Framework frontend responsivo para la construcción de la interfaz de usuario.

3.1.4 Interfaces de comunicación

La comunicación entre los componentes del sistema utiliza los siguientes protocolos:

• HTTPS: transferencia segura de datos entre cliente y servidor.

• WebSockets: comunicación en tiempo real en el módulo de chat.

• REST API: intercambio de datos estructurados entre módulos.

3.2 Requisitos funcionales

Los requisitos funcionales describen las capacidades que el sistema debe proveer. Cada requisito es atómico, verificable y corresponde a una única funcionalidad.

3.2.1 Módulo: Gestión de usuario

RF1 – Registro de usuario

Número de requisito	RF1
Nombre del requisito	Registro de usuario
Módulo	Gestión de usuario
Prioridad	Alta
Descripción	El sistema debe permitir al usuario crear una cuenta nueva proporcionando nombre, correo electrónico y contraseña.
Entrada	Nombre, correo electrónico y contraseña ingresados por el usuario.
Proceso	El sistema valida el formato de los datos, verifica que el correo no esté previamente registrado y crea la cuenta.
Salida	Cuenta creada exitosamente; acceso habilitado al sistema.

RF2 – Inicio de sesión

Número de requisito	RF2
Nombre del requisito	Inicio de sesión
Módulo	Gestión de usuario
Prioridad	Alta
Descripción	El sistema debe autenticar al usuario mediante sus credenciales registradas (correo electrónico y contraseña).
Entrada	Correo electrónico y contraseña del usuario.
Proceso	El sistema verifica las credenciales contra la base de datos y, si son válidas, inicia la sesión.
Salida	Sesión iniciada; usuario redirigido a la pantalla principal.

RF3 – Cierre de sesión

Número de requisito	RF3
Nombre del requisito	Cierre de sesión
Módulo	Gestión de usuario
Prioridad	Alta
Descripción	El sistema debe permitir al usuario cerrar su sesión activa de forma explícita.
Entrada	Solicitud de cierre de sesión del usuario autenticado.
Proceso	El sistema invalida el token de sesión y redirige al usuario a la pantalla de inicio de sesión.
Salida	Sesión terminada; acceso a datos del usuario revocado.

3.2.2 Módulo: Sistema de racha

RF4 – Cálculo y actualización de racha diaria

Número de requisito	RF4
Nombre del requisito	Cálculo y actualización de racha diaria
Módulo	Sistema de racha
Prioridad	Alta
Descripción	Al iniciar sesión, el sistema debe comparar la fecha actual con la última fecha de acceso registrada y actualizar el contador de racha: incrementarlo si el acceso es en un día consecutivo, mantenerlo si ya se accedió en el mismo día, o reiniciarlo si se interrumpió la continuidad.
Entrada	Fecha actual del servidor y fecha del último acceso del usuario.
Proceso	El sistema evalúa la diferencia de días: si es 1 día incrementa la racha en una unidad; si es 0 días la mantiene; si es mayor a 1 día la reinicia a 1.
Salida	Contador de racha actualizado y reflejado en la interfaz del usuario.

RF5 – Visualización de racha

Número de requisito	RF5
Nombre del requisito	Visualización de racha
Módulo	Sistema de racha
Prioridad	Alta
Descripción	El sistema debe mostrar al usuario su racha actual en la pantalla principal de manera visible y permanente.
Entrada	Valor actual del contador de racha del usuario.
Proceso	El sistema recupera el valor de racha desde la base de datos y lo presenta en la interfaz.
Salida	Indicador de racha visible en la pantalla principal con el valor numérico actual.

RF6 – Activación de estado especial por racha alta

Número de requisito	RF6
Nombre del requisito	Activación de estado especial por racha alta
Módulo	Sistema de racha
Prioridad	Media
Descripción	Cuando la racha del usuario alcanza o supera un umbral predefinido (por ejemplo, 7 días consecutivos), el sistema debe activar un estado visual especial en la mascota y notificar al usuario.
Entrada	Valor actual de la racha del usuario y umbrales definidos en la configuración del sistema.
Proceso	El sistema evalúa si la racha supera el umbral configurado y, en caso afirmativo, activa el estado especial y genera la notificación.
Salida	Notificación visible al usuario y cambio de estado en la mascota según el umbral alcanzado.

3.2.3 Módulo: Interfaz principal

RF7 – Visualización de la mascota virtual

Número de requisito	RF7
Nombre del requisito	Visualización de la mascota virtual
Módulo	Interfaz principal
Prioridad	Alta
Descripción	El sistema debe presentar la mascota virtual como elemento central de la pantalla principal, con animaciones que reflejen su estado actual.
Entrada	Estado del usuario (racha, actividad reciente) y skin seleccionado.
Proceso	El sistema carga el skin activo y aplica la animación correspondiente al estado de la mascota.
Salida	Mascota visualizada con el skin correcto y animación acorde a su estado.

RF8 – Estado emocional de la mascota

Número de requisito	RF8
Nombre del requisito	Estado emocional de la mascota
Módulo	Interfaz principal
Prioridad	Media
Descripción	La mascota debe reflejar visualmente diferentes estados emocionales (activo, inactivo, feliz, triste) en función de la actividad reciente del usuario y su racha.
Entrada	Racha actual, tiempo desde el último acceso y actividad del usuario.
Proceso	El sistema determina el estado emocional según reglas predefinidas y selecciona la animación correspondiente.
Salida	Animación de la mascota actualizada para reflejar el estado emocional determinado.

RF9 – Navegación entre módulos

Número de requisito	RF9
Nombre del requisito	Navegación entre módulos
Módulo	Interfaz principal
Prioridad	Alta
Descripción	El sistema debe ofrecer al usuario navegación clara entre los módulos disponibles: chat, quiz/minijuego, personalización y perfil.
Entrada	Selección del usuario en la interfaz de navegación.
Proceso	El sistema enruta al usuario al módulo correspondiente según la opción seleccionada.
Salida	Usuario dirigido al módulo seleccionado sin pérdida de estado.

3.2.4 Módulo: Chat con IA

RF10 – Recepción y envío de mensajes al modelo de IA

Número de requisito	RF10
Nombre del requisito	Recepción y envío de mensajes al modelo de IA
Módulo	Chat con IA
Prioridad	Alta
Descripción	El sistema debe capturar el mensaje escrito por el usuario, construir un prompt estructurado con contexto de conversación y enviarlo al modelo LLaMA a través de su API [1].
Entrada	Mensaje escrito por el usuario e historial de conversación activo.
Proceso	El sistema construye el prompt con el mensaje del usuario y el contexto relevante, realiza la solicitud a la API del modelo de IA y espera la respuesta.
Salida	Solicitud enviada correctamente al modelo de IA.

RF11 – Visualización de la respuesta del chat

Número de requisito	RF11
Nombre del requisito	Visualización de la respuesta del chat
Módulo	Chat con IA
Prioridad	Alta
Descripción	El sistema debe procesar la respuesta recibida del modelo de IA y mostrarla al usuario en la interfaz de chat de forma legible y ordenada.
Entrada	Respuesta recibida desde la API del modelo de IA.
Proceso	El sistema extrae el texto de respuesta, lo formatea si es necesario y lo añade al hilo de conversación visible.
Salida	Respuesta del modelo mostrada en el chat con atribución a la mascota.

RF12 – Historial de conversación

Número de requisito	RF12
Nombre del requisito	Historial de conversación
Módulo	Chat con IA
Prioridad	Media
Descripción	El sistema debe mantener el historial de mensajes de la sesión activa visible para el usuario durante toda la conversación.
Entrada	Mensajes enviados por el usuario y respuestas recibidas del modelo.
Proceso	El sistema almacena en memoria los mensajes de la sesión y los presenta cronológicamente en el área de chat.
Salida	Historial de conversación de la sesión actual visible y desplazable por el usuario.

3.2.5 Módulo: Quiz / Minijuego

RF13 – Presentación de preguntas del quiz

Número de requisito	RF13
Nombre del requisito	Presentación de preguntas del quiz
Módulo	Quiz / Minijuego
Prioridad	Alta
Descripción	El sistema debe presentar al usuario una serie de preguntas de selección múltiple relacionadas con Minecraft, una a la vez.
Entrada	Banco de preguntas almacenado y nivel del usuario.
Proceso	El sistema selecciona preguntas según el nivel del usuario y las muestra de forma secuencial.
Salida	Pregunta actual desplegada con opciones de respuesta habilitadas.

RF14 – Evaluación y resultado del quiz

Número de requisito	RF14
Nombre del requisito	Evaluación y resultado del quiz
Módulo	Quiz / Minijuego
Prioridad	Alta
Descripción	El sistema debe comparar las respuestas del usuario con las respuestas correctas y calcular un puntaje al finalizar el quiz.
Entrada	Respuestas seleccionadas por el usuario y respuestas correctas del banco de preguntas.
Proceso	El sistema calcula el puntaje, determina si se alcanza el umbral mínimo de aprobación y genera el resultado.
Salida	Puntaje y retroalimentación mostrados al usuario al finalizar el quiz.

3.2.6 Módulo: Personalización

RF15 – Selección y aplicación de skin

Número de requisito	RF15
Nombre del requisito	Selección y aplicación de skin
Módulo	Personalización
Prioridad	Media
Descripción	El sistema debe permitir al usuario visualizar los skins disponibles y aplicar aquel que haya desbloqueado, actualizando la apariencia de la mascota de manera inmediata.
Entrada	Lista de skins disponibles y skins desbloqueados por el usuario.
Proceso	El sistema muestra la galería de skins, indica cuáles están disponibles y, al seleccionar uno desbloqueado, actualiza el skin activo en el perfil.
Salida	Skin seleccionado aplicado a la mascota y estado persistido en el perfil del usuario.

3.2.7 Módulo: Sistema de recompensas

RF16 – Otorgamiento de recompensas

Número de requisito	RF16
Nombre del requisito	Otorgamiento de recompensas
Módulo	Sistema de recompensas
Prioridad	Alta
Descripción	El sistema debe otorgar recompensas al usuario cuando alcance umbrales de racha predefinidos o complete actividades específicas dentro de la plataforma.
Entrada	Valor actual de racha, actividades completadas y tabla de umbrales y recompensas.
Proceso	El sistema evalúa el cumplimiento de condiciones y, al detectar un hito, añade la recompensa correspondiente al inventario del usuario.
Salida	Recompensa añadida al perfil del usuario y notificación mostrada en pantalla.

RF17 – Visualización de recompensas obtenidas

Número de requisito	RF17
Nombre del requisito	Visualización de recompensas obtenidas
Módulo	Sistema de recompensas
Prioridad	Media
Descripción	El sistema debe permitir al usuario consultar el listado de recompensas que ha obtenido hasta el momento.
Entrada	Identificador del usuario autenticado.
Proceso	El sistema recupera el inventario de recompensas del usuario desde la base de datos y lo presenta en pantalla.
Salida	Listado de recompensas obtenidas visible para el usuario.

3.3 Requisitos no funcionales

Los siguientes requisitos establecen criterios de calidad verificables que el sistema debe cumplir.

3.3.1 Rendimiento

RNF1 – Tiempo de respuesta en operaciones comunes

Número de requisito	RNF1
Nombre del requisito	Tiempo de respuesta en operaciones comunes
Categoría	Rendimiento
Prioridad	Alta
Descripción	El sistema debe responder a las acciones del usuario (carga de pantalla, navegación, envío de formulario) en un tiempo máximo de 2 segundos bajo condiciones de red normales.
Criterio de verificación	Prueba de rendimiento con herramienta de monitoreo (p. ej. Lighthouse o JMeter): el 95% de las operaciones comunes deben completarse en ≤ 2 segundos.

RNF2 – Tiempo de respuesta del chat con IA

Número de requisito	RNF2
Nombre del requisito	Tiempo de respuesta del chat con IA
Categoría	Rendimiento
Prioridad	Alta
Descripción	El sistema debe mostrar la respuesta del modelo de IA al usuario en un tiempo máximo de 10 segundos después de enviado el mensaje, bajo condiciones de red normales.
Criterio de verificación	Medición del tiempo entre el envío del mensaje y la recepción de la respuesta completa: el 90% de las consultas deben responderse en ≤ 10 segundos.

RNF3 – Usuarios concurrentes

Número de requisito	RNF3
Nombre del requisito	Usuarios concurrentes
Categoría	Rendimiento
Prioridad	Media
Descripción	El sistema debe mantener comportamiento estable cuando al menos 50 usuarios accedan simultáneamente, sin que el tiempo de respuesta supere los 3 segundos.
Criterio de verificación	Prueba de carga (p. ej. k6 o Locust): simular 50 usuarios concurrentes durante 5 minutos y verificar que el tiempo de respuesta promedio no supere 3 segundos.

3.3.2 Seguridad

RNF4 – Autenticación de usuarios

Número de requisito	RNF4
Nombre del requisito	Autenticación de usuarios
Categoría	Seguridad
Prioridad	Alta
Descripción	El sistema debe verificar la identidad del usuario mediante credenciales (correo y contraseña) antes de permitir acceso a cualquier funcionalidad que requiera perfil. Las contraseñas deben almacenarse cifradas con bcrypt o equivalente.
Criterio de verificación	Verificar que las contraseñas en base de datos no se almacenen en texto plano; confirmar que el sistema rechaza intentos de acceso con credenciales incorrectas.

RNF5 – Protección de datos del usuario

Número de requisito	RNF5
Nombre del requisito	Protección de datos del usuario
Categoría	Seguridad
Prioridad	Alta
Descripción	Toda comunicación entre cliente y servidor debe realizarse mediante HTTPS. Los datos sensibles del usuario no deben exponerse en URLs, logs ni respuestas de la API.
Criterio de verificación	Inspección del tráfico de red: verificar que todas las solicitudes usan HTTPS y que ningún dato sensible aparece en texto plano en las peticiones o respuestas.

RNF6 – Gestión de sesiones

Número de requisito	RNF6
Nombre del requisito	Gestión de sesiones
Categoría	Seguridad
Prioridad	Alta
Descripción	El sistema debe invalidar automáticamente la sesión de un usuario tras 30 minutos de inactividad, requiriéndole autenticarse nuevamente para continuar.
Criterio de verificación	Verificar que tras 30 minutos de inactividad el sistema rechaza solicitudes con token expirado y redirige al usuario a la pantalla de inicio de sesión.

3.3.3 Disponibilidad

RNF7 – Disponibilidad del sistema

Número de requisito	RNF7
Nombre del requisito	Disponibilidad del sistema
Categoría	Disponibilidad
Prioridad	Alta
Descripción	El sistema debe estar disponible al menos el 95% del tiempo durante los periodos de uso esperado (lunes a domingo, 6:00 a.m. – 11:00 p.m.).
Criterio de verificación	Monitoreo continuo durante 30 días; el tiempo de inactividad no planificado no debe superar el 5% del tiempo total del periodo de medición.

RNF8 – Manejo de errores y estabilidad

Número de requisito	RNF8
Nombre del requisito	Manejo de errores y estabilidad
Categoría	Disponibilidad
Prioridad	Alta
Descripción	El sistema debe manejar errores inesperados (fallo de API de IA, tiempo de espera excedido, error de red) de forma controlada, mostrando un mensaje informativo al usuario sin interrumpir el funcionamiento general.
Criterio de verificación	Prueba de inyección de fallos: simular caída de la API de IA y verificar que el sistema muestra un mensaje de error descriptivo mientras el resto de la plataforma continúa operando.

3.3.4 Mantenibilidad

RNF9 – Arquitectura modular

Número de requisito	RNF9
Nombre del requisito	Arquitectura modular
Categoría	Mantenibilidad
Prioridad	Alta
Descripción	El sistema debe organizarse en módulos independientes (frontend, backend, módulo de IA, módulo de base de datos), de modo que la modificación de uno no requiera cambios en los demás salvo en sus interfaces definidas.
Criterio de verificación	Revisión de la arquitectura del código: cada módulo debe tener una interfaz documentada y la sustitución del módulo de IA no debe requerir cambios en el frontend.

RNF10 – Estándares de codificación

Número de requisito	RNF10
Nombre del requisito	Estándares de codificación
Categoría	Mantenibilidad
Prioridad	Media
Descripción	El código fuente debe seguir convenciones de nomenclatura y formato verificadas mediante herramienta de análisis estático (linter). Al menos el 80% de los módulos principales deben contar con comentarios de documentación.
Criterio de verificación	Ejecución exitosa del linter sin errores críticos; revisión de cobertura de comentarios en módulos principales (mínimo 80%).

3.3.5 Portabilidad y compatibilidad

RNF11 – Compatibilidad con navegadores

Número de requisito	RNF11
Nombre del requisito	Compatibilidad con navegadores
Categoría	Portabilidad
Prioridad	Alta
Descripción	El sistema debe funcionar correctamente en las versiones más recientes de Google Chrome, Mozilla Firefox, Microsoft Edge y Safari.
Criterio de verificación	Ejecución del conjunto de pruebas funcionales en los cuatro navegadores indicados; todas las funcionalidades principales deben operar sin errores.

RNF12 – Diseño responsivo

Número de requisito	RNF12
Nombre del requisito	Diseño responsivo
Categoría	Portabilidad
Prioridad	Alta
Descripción	La interfaz debe adaptarse correctamente a resoluciones de 360px (móvil), 768px (tableta) y 1280px (escritorio) o superiores, sin pérdida de funcionalidad ni contenido.
Criterio de verificación	Pruebas de visualización en las tres resoluciones indicadas (emulación o dispositivos reales); todos los elementos deben ser accesibles y legibles.

3.3.6 Usabilidad

RNF13 – Facilidad de uso

Número de requisito	RNF13
Nombre del requisito	Facilidad de uso
Categoría	Usabilidad
Prioridad	Alta
Descripción	Un usuario sin experiencia previa con el sistema debe ser capaz de completar el registro, iniciar una conversación en el chat y ejecutar el quiz sin ayuda externa, en un tiempo máximo de 5 minutos.
Criterio de verificación	Prueba de usabilidad con al menos 5 usuarios nuevos: medir el tiempo para completar las tareas descritas; el promedio no debe superar 5 minutos.

RNF14 – Retroalimentación visual

Número de requisito	RNF14
Nombre del requisito	Retroalimentación visual
Categoría	Usabilidad
Prioridad	Media
Descripción	El sistema debe proveer retroalimentación visual inmediata (indicadores de carga, mensajes de confirmación o error) ante cada acción relevante del usuario en un tiempo máximo de 500 ms.
Criterio de verificación	Verificar que cada acción del usuario (envío de formulario, inicio de sesión, envío de mensaje al chat) genera una respuesta visual observable en ≤ 500 ms.

3.3.7 Escalabilidad

RNF15 – Extensibilidad funcional

Número de requisito	RNF15
Nombre del requisito	Extensibilidad funcional
Categoría	Escalabilidad
Prioridad	Media
Descripción	La arquitectura debe permitir incorporar nuevos módulos funcionales (nuevos minijuegos, modelos de IA alternativos) sin refactorización de los módulos existentes.
Criterio de verificación	Revisión de diseño: verificar la existencia de al menos un mecanismo de extensión documentado (p. ej. interfaz de plugin o patrón de estrategia) que permita añadir nuevos módulos sin modificar el código de los existentes.

4. Apéndices

A.1 Glosario ampliado de términos de Minecraft

Los siguientes términos son propios del videojuego Minecraft y son relevantes para la comprensión del dominio de conocimiento que Minetico gestiona [5]:

Término	Definición
AFK	Away From Keyboard. Estado en que un jugador permanece inactivo durante un tiempo prolongado.
Aldeano	Entidad pasiva que habita en aldeas y puede comerciar con el jugador.
Bioma / Biome	Región del mundo con características geográficas, climáticas, de flora y fauna específicas.
Chunk	Unidad de 16 × 16 × 384 bloques en la que se divide y carga el mundo del juego.
Comando	Instrucción de texto que modifica el comportamiento del juego (p. ej. /give, /tp).
Creeper	Criatura hostil que explota al acercarse al jugador, causando daño y destrucción de bloques.
Dragón del End	Jefe final del juego; debe derrotarse para completar la historia principal.
Elytra / Élitros	Alas que permiten planear al jugador tras saltar desde gran altura.
Encantamiento	Mejora aplicada a herramientas, armas o armaduras mediante una mesa de encantamientos.
End (El End)	Dimensión final del juego donde reside el dragón del End.
Enderman	Criatura neutral que se teletransporta; ataca al jugador si este lo mira directamente a los ojos.
Granja	Construcción diseñada para obtener recursos de forma automática o semiautomática.
Mob	Criatura o entidad viva del juego; puede ser hostil, pasiva o neutral.
Netherite	Material más resistente del juego, obtenible en el Nether.
Nether (El Nether)	Dimensión infernal caracterizada por lava, fuego y criaturas únicas.
Overworld	Dimensión principal del juego; es donde el jugador inicia su partida.
Pociones	Bebidas con efectos especiales elaboradas mediante el sistema de alquimia del juego.
Redstone	Sistema de circuitos que permite crear automatizaciones y máquinas dentro del juego.
Seed	Valor numérico que determina la generación procedural de un mundo específico.
Wither	Jefe volador creado por el jugador que lanza cráneos explosivos.

A.2 Ejemplos de interacción con el chat de Minetico

Ejemplo 1 – Consulta básica

Usuario: ¿Cómo construyo una granja de hierro automática?

Minetico: Para una granja de hierro necesitas 3 aldeanos, un zombie para asustarlos, bloques de hierro para generar un gólem y trampillas para controlar el flujo. Te explico el proceso paso a paso...

Ejemplo 2 – Consulta avanzada

Usuario: ¿Cuál es la mejor seed para encontrar un stronghold cerca del spawn en la versión 1.21?

Minetico: En la versión 1.21 existen seeds documentadas que ubican strongholds muy cerca del spawn. Puedo indicarte cómo usar un ojo de ender para localizarlo con precisión. ¿Quieres que te explique el procedimiento?

Ejemplo 3 – Interacción con sistema de racha

Usuario: Llevo 7 días de racha, ¿qué recompensa obtengo?

Minetico: ¡Felicitaciones! Por mantener 7 días consecutivos de racha has desbloqueado la skin "Creeper Glow". Puedes aplicarla desde la sección de personalización. ¿Deseas verla ahora?

A.3 Capturas de pantalla – Interfaz de Minetico

Las siguientes figuras corresponden a capturas de pantalla del prototipo funcional de Minetico, mostrando el chat en funcionamiento.

Figura A.1 – Pantalla principal: mascota, racha y chat (conversación inicial)

Figura A.2 – Chat en funcionamiento: consulta sobre biomas y dimensiones

Figura A.3 – Chat en funcionamiento: respuesta con contexto de rol de la mascota

A.4 Logo del proyecto

Figura A.4 – Logo oficial de Minetico

A.5 Diagrama de flujo – Inicio en la web

La siguiente figura ilustra el flujo general de navegación del usuario desde su ingreso a la plataforma hasta la elección de acción.

Figura A.5 – Diagrama de flujo: inicio y navegación general del sistema

A.6 Diagrama de flujo – Chat + IA

La siguiente figura describe el flujo interno del módulo de chat con inteligencia artificial, desde la escritura del mensaje hasta la presentación de la respuesta [2].

Figura A.6 – Diagrama de flujo: procesamiento de mensajes en el chat con LLaMA

A.7 Base de conocimiento de Minecraft soportada por Minetico

El sistema está entrenado para responder consultas sobre los siguientes temas del videojuego Minecraft [5]:

• Mecánicas básicas y avanzadas de supervivencia.

• Construcción y automatización con Redstone.

• Dimensiones: Overworld, Nether y The End.

• Criaturas (mobs), jefes y estrategias de combate.

• Biomas, estructuras generadas y exploración.

• Actualizaciones recientes (1.20, 1.21 y posteriores).

• Seeds, comandos y trucos documentados.

• Información sobre mods populares (solo orientativa; no ejecutable).

1. Privacidad y protección de datos

• Minetico recopila únicamente los datos necesarios para el funcionamiento del sistema: nombre, correo electrónico y progreso del usuario.

• Las contraseñas se almacenan cifradas y toda la comunicación se realiza mediante HTTPS, evitando filtraciones de información personal.

• El usuario es informado claramente sobre qué datos se recopilan y con qué fin, especialmente por tratarse de una plataforma dirigida a menores de edad.

2. Seguridad y calidad

• El sistema implementa autenticación segura, gestión de sesiones con expiración automática y validación de entradas para prevenir vulnerabilidades.

• Las respuestas generadas por el modelo de IA son supervisadas mediante un prompt estructurado que limita el contenido a temas relacionados con Minecraft.

• El código fuente sigue estándares de calidad verificados mediante herramientas de análisis estático, garantizando un producto confiable y mantenible.

3. Propiedad intelectual

• Minetico utiliza el modelo LLaMA de Meta AI bajo su licencia de uso académico y no comercial, respetando los términos establecidos por sus creadores.

• Los assets visuales de la mascota y los skins son de creación propia del equipo o utilizados bajo licencias que permiten su uso en el proyecto.

• El contenido generado por la IA sobre Minecraft se basa en información de dominio público y no reproduce material protegido por derechos de autor.

4. Impacto social

• La plataforma está orientada a jóvenes entre 12 y 25 años, por lo que el contenido generado por la IA está diseñado para ser apropiado, educativo y positivo.

• Minetico fomenta el aprendizaje autónomo y la motivación mediante gamificación, contribuyendo al desarrollo de habilidades digitales en sus usuarios.

• El equipo es consciente del riesgo de uso excesivo de la plataforma y diseña las mecánicas de racha y recompensas de forma que incentiven el uso moderado y constante, no la dependencia.

5. Responsabilidad profesional

• El equipo de desarrollo asume la responsabilidad de mantener el sistema actualizado, corregir errores reportados y garantizar la disponibilidad del servicio.

• Las decisiones de diseño se toman considerando el bienestar del usuario como prioridad, por encima de métricas de engagement o retención.

• El proyecto se desarrolla bajo la guía del docente tutor y siguiendo los estándares académicos de la Universidad Libre, respondiendo éticamente ante la comunidad educativa.

6. Transparencia y explicabilidad

• Minetico informa al usuario que está interactuando con una inteligencia artificial y no con una persona real, evitando cualquier forma de engaño.

• Las respuestas del modelo de IA pueden contener imprecisiones; el sistema advierte al usuario sobre esta limitación para que contraste la información cuando sea necesario.

• Los criterios de otorgamiento de recompensas y desbloqueo de skins son visibles para el usuario, garantizando transparencia en las reglas del sistema.

• Actuar en interés público: Minetico prioriza el bienestar educativo y emocional de sus usuarios por encima de cualquier otro objetivo.

• Ser honesto y confiable: el sistema no manipula al usuario ni genera contenido engañoso o inapropiado.

• Respetar la privacidad: se recopila la mínima información necesaria y se protege con medidas técnicas adecuadas.

• Mejorar continuamente: el equipo se compromete a iterar el producto con base en retroalimentación real de los usuarios.

Conclusiones:

Durante el desarrollo del prototipo y el diseño de Minetico se cambiaron varios aspectos, desde el sieño hasta el planteamiento del proyecto como tal, es decir, se presentaron varios inconvenientes, diferencia de ideas dentro de los integrantes del grupo, sin embargo, luego de varias conversaciones, mejoras y demás llegamos a este documento final donde ya se encontró la propuesta final del proyecto.

Bibliografía

[1]	IEEE, «IEEE Recommended Practice for Software Requirements Specifications,» IEEE, 1998. [En línea]. Available: https://ieeexplore.ieee.org.
[2]	Meta, «LlamA Documentation: Models and Usage,» Meta, 2025. [En línea]. Available: https://www.llama.com/docs/overview/.
[3]	D. A. A. D. A. A. y. M. Á. V. A. F. Ardila, Diseño Minetico, Bogota D.C: Universidad Libre, 2026.
[4]	G. Aaron, «The Llama 3 Heard of Models,» Meta AI, 2024. [En línea]. Available: https://ai.meta.com/research/publications/the-llama-3-herd-of-models/.
[5]	Minecraft Wiki, «Tutoriales/Términos del juego,» Minecraftt Wiki, 2026. [En línea]. Available: https://minecraft.fandom.com/es/wiki/Tutoriales/Términos_del_juego.
[6]	M. Cifuentes, Papel del Ingeniero de Software, Bogota D.C: Universidad libre, 2026.

Minetico - Requisitos de software

Referencias

Bibliografía

Comentarios

Publicar un comentario

Entradas populares