42. Caso práctico integrador: desde una necesidad hasta una especificación validada
En este tema integraremos los conceptos del curso mediante un caso práctico. Partiremos de una necesidad inicial, identificaremos interesados, delimitaremos alcance, escribiremos requerimientos, definiremos criterios de aceptación y revisaremos la validación.
El objetivo es mostrar cómo las actividades de ingeniería de requerimientos se conectan entre sí. En un proyecto real, estas actividades no siempre ocurren en una secuencia perfecta, pero el razonamiento de fondo es el mismo.
42.1 Introducción
Durante el curso estudiamos necesidades, interesados, alcance, elicitación, análisis, especificación, validación, trazabilidad y gestión de cambios. Ahora aplicaremos esas ideas a un ejemplo completo.
El caso será simple para que pueda seguirse con claridad, pero incluirá situaciones habituales: reglas de negocio, usuarios con necesidades distintas, criterios de aceptación y decisiones de alcance.
42.2 Contexto del caso
Una pequeña empresa de capacitación recibe inscripciones a cursos mediante llamadas, mensajes y correos. La información se registra en planillas y se confirma manualmente con cada alumno.
El proceso funciona cuando hay pocas inscripciones, pero se vuelve lento y propenso a errores cuando se abren varios cursos al mismo tiempo.
42.3 Necesidad inicial
La necesidad inicial expresada por la dirección es: "queremos un sistema para administrar inscripciones a cursos y evitar errores en cupos, pagos y confirmaciones".
Esta frase todavía no es una especificación. Es un punto de partida que debe analizarse para entender problemas, objetivos, restricciones y expectativas.
42.4 Problemas observados
Al revisar el proceso actual se detectan errores en datos de alumnos, inscripciones duplicadas, cupos superados, pagos no asociados correctamente y confirmaciones enviadas tarde.
También se observa que distintos empleados usan criterios diferentes para reservar cupos o cancelar una inscripción.
42.5 Objetivos del sistema
Los objetivos principales son registrar inscripciones de forma ordenada, controlar cupos disponibles, asociar pagos, emitir confirmaciones y permitir seguimiento del estado de cada alumno.
Además, se busca reducir trabajo manual, mejorar la información disponible y evitar decisiones contradictorias entre empleados.
42.6 Interesados identificados
Los interesados incluyen dirección, personal administrativo, docentes, alumnos, responsable de pagos, soporte técnico y eventualmente el área contable.
Cada interesado aporta una mirada distinta. La dirección prioriza control y reportes; administración necesita operación diaria; alumnos necesitan confirmación clara; pagos requiere conciliación.
42.7 Técnicas de elicitación usadas
Para obtener información se realizan entrevistas con dirección y administración, observación del proceso actual, revisión de planillas existentes y un taller breve para acordar reglas principales.
También se prepara un prototipo simple de pantalla de inscripción para validar si los datos solicitados son suficientes.
42.8 Alcance incluido
El alcance inicial incluye registro de cursos, registro de alumnos, inscripción a cursos, control de cupos, estados de inscripción, registro de pagos y envío de confirmación.
También se incluye un reporte básico de inscriptos por curso y estado.
42.9 Alcance excluido
Se excluyen por ahora la facturación electrónica, integración con plataformas externas de videoconferencia, aula virtual completa y campañas de marketing.
Registrar exclusiones evita que esas expectativas aparezcan como obligaciones implícitas durante el desarrollo.
42.10 Supuestos y restricciones
Se asume que la empresa ya cuenta con un medio externo para cobrar pagos y que el sistema solo registrará la información del pago. También se asume que cada curso tiene un cupo máximo definido.
Como restricción, el sistema debe poder usarse desde navegadores modernos y estar disponible para el personal administrativo durante el horario laboral.
42.11 Reglas de negocio
Una regla indica que no puede confirmarse una inscripción si el curso no tiene cupo disponible. Otra regla indica que una reserva sin pago vence después de cuarenta y ocho horas.
También se define que un alumno no puede tener dos inscripciones activas al mismo curso.
42.12 Datos principales
Los datos principales son curso, alumno, inscripción, pago y estado. Para el alumno se registran nombre, documento, correo y teléfono. Para el curso se registran nombre, fecha de inicio, modalidad, precio y cupo.
Para la inscripción se registran curso, alumno, fecha, estado, vencimiento de reserva y observaciones.
42.13 Estados de inscripción
Se acuerdan los estados: reservada, confirmada, cancelada, vencida y en lista de espera. Cada estado tiene condiciones de entrada y consecuencias operativas.
Definir estados evita ambigüedades sobre qué significa estar inscripto y qué acciones puede realizar el personal administrativo.
42.14 Requerimiento funcional 1
RF-001: El sistema debe permitir registrar una inscripción de un alumno a un curso, indicando alumno, curso, fecha de inscripción y estado inicial.
El estado inicial será reservada si existe cupo disponible y el pago todavía no fue registrado.
42.15 Criterios de aceptación de RF-001
Al registrar una inscripción con datos válidos y cupo disponible, el sistema debe crear la inscripción en estado reservada. Si falta un dato obligatorio, debe informar el campo faltante.
Si el alumno ya tiene una inscripción activa al mismo curso, el sistema debe impedir el registro e informar la situación.
42.16 Requerimiento funcional 2
RF-002: El sistema debe controlar el cupo disponible de cada curso considerando las inscripciones confirmadas y reservadas vigentes.
Las inscripciones canceladas o vencidas no deben ocupar cupo.
42.17 Criterios de aceptación de RF-002
Si el cupo máximo del curso es veinte y existen veinte inscripciones confirmadas o reservadas vigentes, el sistema no debe permitir una nueva reserva común.
Si una inscripción reservada vence o se cancela, el cupo debe volver a estar disponible para otra inscripción.
42.18 Requerimiento funcional 3
RF-003: El sistema debe permitir registrar un pago asociado a una inscripción y cambiar el estado de la inscripción a confirmada cuando el pago sea válido.
El pago debe registrar fecha, importe, medio de pago, referencia y usuario que realizó la carga.
42.19 Criterios de aceptación de RF-003
Si se registra un pago válido para una inscripción reservada vigente, el sistema debe cambiar el estado a confirmada. Si el importe es menor al precio requerido, debe impedir la confirmación automática.
Si la inscripción está cancelada o vencida, el sistema debe solicitar una acción administrativa antes de confirmar.
42.20 Requerimiento no funcional
RNF-001: El sistema debe mostrar el listado de inscripciones de un curso en menos de tres segundos cuando existan hasta mil inscripciones registradas.
Este requerimiento es verificable porque define operación, límite de datos y tiempo esperado.
42.21 Interfaz externa
En esta primera versión no se integrará automáticamente con la plataforma de pagos. El sistema solo registrará manualmente la referencia del pago emitida por el medio externo.
Esta decisión reduce alcance inicial y deja una posible integración futura como cambio o mejora posterior.
42.22 Trazabilidad del caso
La necesidad de evitar cupos superados se relaciona con RF-002 y sus pruebas. La necesidad de evitar pagos no asociados se relaciona con RF-003. La necesidad de reducir errores de datos se relaciona con validaciones de RF-001.
Esta trazabilidad permite comprobar que los problemas iniciales tienen respuesta dentro del alcance definido.
42.23 Validación con interesados
La especificación se revisa con dirección, administración y responsable de pagos. Se muestran ejemplos de inscripción, curso lleno, pago válido, pago insuficiente y reserva vencida.
Durante la validación se corrige una regla: las reservas vencen en cuarenta y ocho horas solo para cursos con alta demanda; en otros cursos pueden mantenerse manualmente.
42.24 Ajuste de requerimientos
Después de la validación, RF-002 se ajusta para contemplar cursos con política de vencimiento automática y cursos con vencimiento manual. También se agrega una regla de negocio para definir esa política por curso.
Este ajuste muestra por qué la validación no es un trámite final, sino una actividad que mejora la especificación.
42.25 Ejemplo de caso de prueba
Caso de prueba para RF-002: dado un curso con cupo máximo de dos y dos inscripciones reservadas vigentes, cuando se intenta registrar una tercera inscripción, entonces el sistema debe impedirla e informar que no hay cupo disponible.
Si una de las reservas se cancela, al intentar nuevamente la inscripción, el sistema debe permitir crear una nueva reserva.
42.26 Línea base inicial
Una vez revisados los requerimientos, se establece una línea base inicial para la primera versión. Esa línea base incluye alcance, exclusiones, reglas, requerimientos, criterios y trazabilidad básica.
A partir de esa línea base, cualquier cambio relevante debe evaluarse por impacto y registrarse.
42.27 Cambio posterior
Luego de iniciar el desarrollo, dirección solicita integrar cobro automático con la plataforma de pagos. El cambio tiene valor, pero afecta alcance, seguridad, pruebas, tiempos y dependencias externas.
El equipo registra la solicitud, analiza impacto y decide dejar la integración para una segunda versión, manteniendo la carga manual en la primera entrega.
42.28 Resultado de la especificación
El resultado no es solo una lista de requerimientos. Es un conjunto coherente que incluye problema, objetivos, interesados, alcance, exclusiones, reglas, datos, requerimientos, criterios, pruebas, trazabilidad y decisiones.
Esta información permite que análisis, diseño, desarrollo, pruebas y gestión trabajen con una comprensión compartida.
42.29 Qué debes recordar
Un buen proceso de requerimientos transforma una necesidad inicial en información clara, verificable y acordada. Para lograrlo se necesita preguntar, analizar, priorizar, escribir, validar y controlar cambios.
La calidad de los requerimientos se nota cuando el equipo puede construir y probar con menos dudas, y cuando los interesados reconocen que la solución responde a sus necesidades.
42.30 Conclusión del curso
La ingeniería de requerimientos es una disciplina práctica para comprender problemas, ordenar necesidades y guiar la construcción de software útil. No se limita a escribir documentos: implica conversación, análisis, negociación, validación y aprendizaje continuo.
A lo largo del curso vimos cómo pasar de necesidades generales a requerimientos claros, completos, verificables y trazables. Esa capacidad es esencial para reducir incertidumbre y mejorar la calidad de cualquier proyecto de software.