Feedback Checkpoint 1

1. Investigación y Entrevistas

Los formularios sirven para validar información, pero las entrevistas son esenciales para explorar y descubrir dolencias reales de los usuarios.
No se deben enviar encuestas de forma masiva en esta etapa. Es necesario realizar entrevistas uno a uno (en llamadas) para obtener información de valor y contexto que no surge en un formulario.
Las preguntas diseñadas para la entrevista están muy bien planteadas, en especial la pregunta número 4.
Se debe partir del dominio del problema para llegar a la solución. Hay que evitar el uso de IA para generar requerimientos genéricos que no reflejen un análisis real de las necesidades de los usuarios (como las dinámicas de grupo).

2. Requerimientos Funcionales (RF) y No Funcionales (RNF)

Voz activa: Los requerimientos deben redactarse siempre usando voz activa y de forma específica (por ejemplo: "El sistema debe permitir…" o "El usuario puede…").
Especificidad en RNF: Se deben evitar términos ambiguos como "navegadores web modernos". Se debe detallar exactamente en qué exploradores funcionará la aplicación para que sea un criterio objetivo y medible.
Claridad de conceptos: No se deben incluir tecnologías o siglas que no se comprendan completamente. El profesor corrigió la confusión sobre WCAG, aclarando que refiere a accesibilidad y no a calidad de código.
Detalles funcionales: Se recomendó especificar explícitamente en qué moneda se mostrará el costo de las actividades dentro de los requerimientos.
Persistencia local: Tras una confusión inicial, el profesor validó la decisión del equipo de manejar las preferencias guardadas localmente en el navegador.

3. User Stories (Historias de Usuario)

El enfoque general y la idea de las historias de usuario están muy bien.
Se sugirió mejorar el contexto de algunas redacciones para que tengan más sentido lógico. Por ejemplo, en lugar de plantear que el usuario entra al detalle de una actividad de forma aislada, indicar que lo hace "luego de haber aplicado el filtro".

4. Casos de Uso (Use Cases)

Es estrictamente necesario corregir el formato actual y utilizar la estructura de planilla o cuadro que se enseña en las diapositivas.
Están faltando secciones obligatorias como las precondiciones y las postcondiciones.
La interacción debe estructurarse en columnas para facilitar la lectura. Debe existir una columna para las acciones del "Usuario" y otra en la misma fila para la "Respuesta del sistema".
Este formato interactivo de columnas debe aplicarse tanto para el flujo principal como para los flujos alternativos.

5. Prototipos de UI

Los prototipos actuales están demasiado personalizados e incluyen elementos visuales o funciones que no fueron mencionados en los requerimientos funcionales documentados.
Se debe realizar una nueva iteración de los prototipos asegurando que respeten estrictamente los límites de los requerimientos definidos, sin salirse de ese alcance.

6. Modelo de Dominio

Es correcto y esperable que el equipo aún no tenga el modelo de dominio, ya que este debe elaborarse a partir de los resultados que arrojen las entrevistas.
Cuando se construya el diagrama de clases, debe ser una versión muy simplificada. Solo debe incluir el nombre de la clase, los atributos y las relaciones, omitiendo métodos y tipos de datos.

7. Próximos Pasos y Gestión

Se debe publicar formalmente el issue correspondiente a la entrega del checkpoint en GitHub.
Es indispensable etiquetar (taggear) al profesor en dicho issue para que reciba la notificación y pueda realizar la corrección y dar los puntos de la entrega.