[Reporte de Clase] Desarrollo de Sistemas (2.º año) — Semana 33
~ Introducción a la Definición de Requisitos: Poner en palabras “el qué y de quién estamos resolviendo” ~
En la Semana 33 dimos nuestro primer paso serio en el diseño de sistemas como estudiantes de segundo año: definición de requisitos (consolidación de requisitos). Fue una sesión práctica donde los equipos profundizaron en “¿de quién es el problema que estamos resolviendo y qué exactamente, antes de construir nada?”
■ Inicio del profesor: “El diseño comienza con un propósito cristalino”
Sr. Tanaka: “Por muy bueno que sea tu código, si el problema que estás resolviendo es difuso, no obtendrás un buen sistema. Primero, identifica a tus usuarios y stakeholders, y pon en palabras lo que intentas lograr.”
En el pizarrón, el profesor presentó un marco básico para la definición de requisitos usando las preguntas Quién / Qué / Por qué / Cuándo / Cuánto.
■ Calentamiento de hoy: Crear un mapa de stakeholders
Comenzamos haciendo mapas de stakeholders. Cada equipo eligió un objetivo de proyecto (p. ej., mejorar el sistema de la biblioteca escolar, una app de reservas de clubes) y listó personas y organizaciones involucradas.
- Estudiante A: “Los estudiantes lo usarán, pero los profesores y los asistentes de biblioteca también están involucrados.”
- Estudiante B: “A los administradores les preocupará si las actualizaciones y aprobaciones añaden carga de trabajo extra.”
El mapeo de stakeholders sacó a la luz conflictos de interés y prioridades y ofreció pistas para definir la granularidad adecuada de los requisitos.
■ Ejercicio ①: Capturar “lo que quieren los usuarios” con User Stories
Luego escribimos historias de usuario (formato breve, de una sola oración) para expresar solicitudes de funcionalidades desde la perspectiva del usuario. Usamos la plantilla conocida:
“Como (quién), quiero ~, para ~.”
Ejemplos:
- “Como asistente de biblioteca, quiero ver de un vistazo el estado de los préstamos, para poder enviar rápidamente los avisos de retraso.”
- “Como estudiante de primer año, quiero comprobar fácilmente la disponibilidad de los libros populares, para poder encontrar lo que quiero pedir prestado.”
Estudiante C: “Este formato hace que el por qué necesitamos la función quede clarísimo.”
■ Ejercicio ②: Escribir Criterios de Aceptación
Más allá de las historias de usuario, practicamos especificar criterios de aceptación: las condiciones concretas bajo las cuales se considera que una función está completa.
Ejemplo (criterios de aceptación para una historia)
- Al introducir parte de un título en el campo de búsqueda se muestran hasta 10 libros coincidentes.
- Los ítems sin stock muestran “No disponible” en rojo.
- Los administradores pueden descargar el historial de préstamos como CSV.
Estudiante D: “¡Una vez que escribes los criterios, los casos de prueba básicamente saltan solos!”
■ Ejercicio ③: Entrevistas rápidas y creación de Personas
Para profundizar en los requisitos reales, hicimos entrevistas simuladas en cada equipo. Una persona interpretó al usuario; otra, a la entrevistadora que indagaba necesidades y puntos de dolor. Con los resultados, creamos una persona de una página (usuario representativo).
- Ejemplos de persona: edad, rol, rutina diaria, puntos de dolor, mejoras deseadas
- Estudiante E: “¡Tener una persona facilita priorizar funcionalidades!”
■ Reflexión: Priorización de funcionalidades con MoSCoW
Finalmente, clasificamos las solicitudes recopiladas usando el método MoSCoW (Must / Should / Could / Won’t). Esto ayudó al equipo a acordar qué es absolutamente necesario ahora y qué puede esperar.
Estudiante F: “Quieres hacerlo todo, pero aprendí que priorizar es la clave del éxito del proyecto.”
■ Comentario de cierre del profesor
“La definición de requisitos es la elaboración del mapa para el diseño. Cuanto más cuidadosamente caves, menos te perderás después en el diseño y la implementación. Los resultados de hoy serán la base para la próxima semana: UML y diseño de datos.”
■ Tarea (para la próxima vez)
- Entregar el mapa de stakeholders, 3 historias de usuario y 3 criterios de aceptación compilados por su equipo.
- Crear el perfil de una persona (una página A4).
- La persona presentadora del equipo debe preparar una explicación de 2 minutos de su definición de requisitos para la sesión de UML de la próxima semana.
■ Próxima semana: Dibujar “Estructura” y “Comportamiento” con UML
La próxima semana, usando los requisitos de hoy, practicaremos el dibujo de diagramas de clases (atributos/métodos) y diagramas de secuencia (flujo de procesamiento). Cuando los requisitos están sólidos, UML fluye sin tropiezos—¡así que cuiden bien el trabajo de hoy!
En la Semana 33, el alumnado aprendió a poner en palabras los problemas de los usuarios. Al construir consenso en equipo sobre la “razón para construir”, sentaron bases conceptuales sólidas para el diseño.