| RQ1 |
El sistema deberá permitir al estudiante crear un grupo de estudio ingresando obligatoriamente el nombre y la descripción del grupo. Antes de guardar la información, el sistema deberá verificar que ambos campos contengan datos. Si los dos campos son válidos, deberá registrar el grupo y mostrarlo en el listado de grupos disponibles. Si alguno de los campos está vacío, el sistema no deberá registrar el grupo y deberá indicar al estudiante cuál información debe completar. |
@mmolinae |
Estudiante |
| RQ2 |
El sistema deberá permitir al estudiante consultar la información de un grupo de estudio existente. Al seleccionar un grupo, deberá mostrar su nombre, descripción, integrantes y reuniones asociadas. Los integrantes y reuniones mostrados deberán corresponder exclusivamente al grupo seleccionado. Si el grupo no existe o no tiene información asociada, el sistema deberá mostrar un mensaje indicando la situación correspondiente. |
@bgarcias1 |
Estudiante, Docente |
| RQ3 |
El sistema deberá permitir al estudiante agregar y retirar integrantes de un grupo de estudio. Para agregar un integrante, deberá permitir seleccionar un estudiante y verificar que no pertenezca previamente al grupo; si no pertenece, deberá crear la relación entre el estudiante y el grupo. Si ya pertenece, no deberá crear una relación duplicada y deberá informar la situación. Para retirar un integrante, deberá permitir seleccionarlo entre los integrantes actuales y solicitar confirmación antes de eliminar su relación con el grupo. Después de cada operación, deberá actualizar la lista de integrantes. |
@mmolinae |
Estudiante |
| RQ4 |
El sistema deberá permitir al estudiante modificar el nombre y la descripción de un grupo de estudio existente. Al seleccionar un grupo para editar, deberá mostrar los valores actualmente registrados y permitir modificarlos. Antes de guardar los cambios deberá verificar que el nombre y la descripción contengan información. Si los datos son válidos, deberá actualizar el grupo y mostrar la información modificada; si algún dato obligatorio está vacío, deberá rechazar la modificación e indicar el campo que debe completarse. |
@cvalenciac |
Estudiante |
| RQ5 |
El sistema deberá permitir al estudiante eliminar un grupo de estudio existente. Para eliminarlo, deberá seleccionar el grupo y confirmar explícitamente la operación. Si cancela la confirmación, el grupo deberá permanecer sin modificaciones. Si confirma, el sistema deberá eliminar el grupo y las relaciones y registros que dependan exclusivamente de él, incluyendo sus integrantes, reuniones y asistencias, sin dejar referencias a un grupo inexistente. Una vez finalizada la operación, el grupo eliminado no deberá aparecer en el listado de grupos. |
@mmolinae |
Estudiante |
| RQ6 |
El sistema deberá permitir al estudiante crear una reunión asociada a un grupo de estudio existente. Para crearla, deberá permitir seleccionar el grupo y registrar la fecha, hora, lugar o modalidad y descripción de las actividades realizadas. Antes de guardar la reunión deberá verificar que exista un grupo seleccionado y que la fecha haya sido diligenciada. Si los datos son válidos, deberá registrar la reunión asociándola al grupo seleccionado; si falta alguno de los datos obligatorios, no deberá crearla y deberá informar al estudiante qué dato debe completar. |
@bgarcias1 |
Estudiante |
| RQ7 |
El sistema deberá permitir al estudiante modificar una reunión existente. Al seleccionar una reunión deberá mostrar su fecha, hora, lugar o modalidad y descripción actuales y permitir modificar estos datos. Antes de guardar los cambios deberá verificar que la reunión exista, pertenezca a un grupo existente y que la fecha se encuentre diligenciada. Si los datos son válidos, deberá actualizar la reunión; de lo contrario, deberá rechazar la modificación e informar el dato que debe corregirse. |
@bgarcias1 |
Estudiante |
| RQ8 |
El sistema deberá permitir al estudiante eliminar una reunión existente. Para realizar la operación deberá seleccionar la reunión y confirmar explícitamente su eliminación. Si cancela la confirmación, la reunión deberá permanecer registrada. Si confirma, el sistema deberá eliminar la reunión y los registros de asistencia asociados exclusivamente a ella, evitando que queden asistencias relacionadas con una reunión inexistente. La reunión eliminada no deberá aparecer posteriormente en el listado del grupo. |
@bgarcias1 |
Estudiante |
| RQ9 |
El sistema deberá permitir al estudiante consultar el historial de reuniones de un grupo. Al seleccionar un grupo, deberá mostrar todas las reuniones asociadas, indicando para cada una la fecha, hora, lugar o modalidad, descripción de las actividades y estudiantes que registraron asistencia. Las reuniones deberán mostrarse ordenadas cronológicamente por fecha y hora. Si el grupo no tiene reuniones registradas, deberá informar que no existen reuniones disponibles. |
@bgarcias1 |
Estudiante, Docente |
| RQ10 |
El sistema deberá permitir al estudiante registrar la asistencia de uno o varios integrantes a una reunión existente. Al seleccionar una reunión, deberá mostrar únicamente los estudiantes que pertenecen al grupo asociado a ella. Antes de registrar una asistencia, deberá verificar que el estudiante pertenezca al grupo y que no exista previamente una asistencia para la combinación del estudiante y la reunión. Si no existe una asistencia previa, deberá crear el registro; si ya existe, no deberá crear un duplicado y deberá informar que la asistencia ya está registrada. |
@mmolinae |
Estudiante |
| RQ11 |
El sistema deberá permitir consultar las estadísticas de asistencia de un estudiante perteneciente a un grupo. La consulta deberá mostrar el nombre del estudiante, el número total de reuniones registradas para el grupo, el número de reuniones a las que asistió y el porcentaje de asistencia. El porcentaje deberá calcularse dividiendo las reuniones asistidas entre el total de reuniones del grupo y multiplicando el resultado por 100. Si el grupo no tiene reuniones registradas, el sistema deberá mostrar cero reuniones y un porcentaje de asistencia de 0 %. |
@cvalenciac |
Estudiante, Docente |
| RQ12 |
El sistema deberá permitir consultar en una misma vista las estadísticas de asistencia de todos los integrantes de un grupo. Para cada integrante deberá mostrar su nombre, el número total de reuniones del grupo, el número de reuniones a las que asistió y su porcentaje de asistencia. Todos los integrantes deberán aparecer aunque tengan cero asistencias. Si el grupo no tiene reuniones registradas, el porcentaje de asistencia de todos sus integrantes deberá mostrarse como 0 %. |
@cvalenciac |
Estudiante, Docente |
| RQ13 |
El sistema deberá permitir buscar grupos de estudio y estudiantes utilizando una parte de su nombre. El usuario deberá ingresar un texto de búsqueda y seleccionar si desea buscar grupos o estudiantes. El sistema deberá mostrar los registros cuyo nombre contenga el texto ingresado sin exigir coincidencia exacta y sin diferenciar entre mayúsculas y minúsculas. Si no existen coincidencias, deberá informar que no se encontraron resultados. |
@mmolinae |
Estudiante, Docente |
| RQ14 |
El sistema deberá permitir consultar las reuniones de un grupo utilizando una fecha específica o un rango de fechas. Para una fecha específica deberá mostrar únicamente las reuniones realizadas en esa fecha. Para un rango deberá mostrar las reuniones cuya fecha se encuentre entre la fecha inicial y la fecha final, incluyendo ambas. El sistema deberá verificar que la fecha inicial no sea posterior a la fecha final y deberá informar un error cuando el rango sea inválido. Si no existen reuniones que coincidan con el criterio, deberá informar que no se encontraron resultados. |
@bgarcias1 |
Estudiante, Docente |
| RQ15 |
El sistema deberá permitir consultar las reuniones a las que ha asistido un estudiante. Para realizar la consulta, el usuario deberá seleccionar o buscar un estudiante y el sistema deberá mostrar las reuniones que tengan un registro de asistencia asociado a dicho estudiante. Cada resultado deberá indicar como mínimo el grupo, fecha, hora, lugar o modalidad y descripción de la reunión. Si el estudiante no tiene asistencias registradas, deberá informar que no existen reuniones asociadas a su historial. |
@cvalenciac |
Estudiante, Docente |
| RQ16 |
El sistema deberá permitir consultar el historial de asistencia de un estudiante. Al seleccionar un estudiante, deberá mostrar todos sus registros de asistencia y, para cada registro, indicar el grupo, la reunión, la fecha y hora de la reunión y el momento en que fue registrada la asistencia. Los registros deberán corresponder únicamente a asistencias existentes y deberán mostrarse en orden cronológico. Si el estudiante no tiene registros, deberá informar que no existe historial de asistencia. |
@cvalenciac |
Estudiante, Docente |
| RQ17 |
El sistema deberá permitir que un usuario con rol docente consulte los grupos de estudio, sus integrantes, reuniones, registros de asistencia y estadísticas de participación. El docente deberá tener acceso a las funcionalidades de consulta definidas para este rol y no deberá poder crear, modificar ni eliminar información de grupos, integrantes, reuniones o asistencias. Si intenta ejecutar una operación no permitida, el sistema deberá rechazarla e informar que no tiene permisos suficientes. |
@cvalenciac |
Docente |
| RQ18 |
El sistema deberá permitir que estudiantes y docentes registrados inicien sesión mediante correo electrónico y contraseña. El backend deberá verificar las credenciales antes de permitir el acceso y deberá identificar el rol del usuario autenticado. Si las credenciales son incorrectas, deberá rechazar el inicio de sesión e informar que no son válidas. Las funcionalidades disponibles deberán depender del rol asignado al usuario. |
@cvalenciac |
Estudiante, Docente |
| RQ19 |
El sistema deberá almacenar de forma persistente la información de usuarios, grupos, relaciones entre integrantes y grupos, reuniones y asistencias en una base de datos relacional. Cada registro deberá poseer un identificador único y las relaciones entre las entidades deberán mantener integridad referencial. La base de datos deberá impedir que exista más de un registro de asistencia para la misma combinación de estudiante y reunión. La información deberá permanecer disponible después de reiniciar el backend. |
@mmolinae |
Estudiante, Docente |
| RQ20 |
El backend deberá ser desarrollado utilizando Quarkus y deberá centralizar la lógica de negocio, las validaciones, el acceso a la base de datos y el control de permisos. El backend deberá proporcionar una API REST para que la aplicación Flutter pueda realizar las operaciones de consulta, creación, modificación y eliminación. La aplicación móvil no deberá conectarse directamente a la base de datos. |
@mmolinae |
Estudiante, Docente |
| RQ21 |
La aplicación cliente deberá ser desarrollada utilizando Flutter y deberá comunicarse con el backend mediante la API REST. La aplicación deberá permitir al usuario ejecutar las funcionalidades del sistema, mostrar los datos obtenidos del backend y presentar mensajes cuando una operación sea exitosa, inválida, no autorizada o no pueda completarse por un error de comunicación. |
@bgarcias1 |
Estudiante, Docente |
| RQ22 |
Cuando el sistema registre correctamente una asistencia, el backend deberá generar un evento que contenga como mínimo el identificador de la asistencia, del estudiante, de la reunión y del grupo. El evento deberá ser enviado mediante Kafka o RabbitMQ a un consumidor encargado de procesarlo. El consumidor deberá utilizar la información recibida para actualizar las estadísticas de asistencia correspondientes y deberá evitar que un mismo evento incremente más de una vez el número de asistencias de un estudiante. |
@mmolinae |
Estudiante |
| RQ23 |
El código fuente del backend Quarkus y de la aplicación Flutter deberá mantenerse en un repositorio de GitHub. El repositorio deberá contener el código necesario para ejecutar el sistema y un archivo de documentación que indique las tecnologías utilizadas, los requisitos para ejecutar el proyecto, la configuración de la base de datos, la configuración de Kafka o RabbitMQ y los pasos necesarios para iniciar el backend y la aplicación móvil. Los cambios realizados durante el desarrollo deberán quedar registrados en el historial de versiones del repositorio. |
@bgarcias1 |
Equipo de desarrollo |