La validación de requerimientos en el desarrollo de software es responsabilidad principal del analista de requerimientos o analista de sistemas, aunque también participan otros actores clave como:
-
Clientes o usuarios finales: Aseguran que los requerimientos reflejen sus necesidades reales.
-
Desarrolladores: Validan la viabilidad técnica de los requerimientos.
-
Gerentes de proyecto: Aseguran que los requerimientos estén alineados con los objetivos del proyecto.
-
Testers o QA (Aseguramiento de Calidad): Verifican que los requerimientos sean testables y verificables.
Técnicas de Validación de Requerimientos
Estas técnicas se utilizan para garantizar que los requerimientos sean correctos, completos, consistentes y verificables:
1. Revisiones o Inspecciones
Qué es:
Es un proceso formal en el que se revisan los documentos de requerimientos con la participación de un equipo multidisciplinario (clientes, analistas, desarrolladores, testers, etc.).Objetivo:
Detectar errores, ambigüedades, omisiones, redundancias o contradicciones.Cómo se realiza:
-
Se distribuyen los documentos antes de la reunión.
-
Todos los participantes revisan el contenido.
-
Durante la sesión, se discuten cada requerimiento y se documentan los hallazgos.
-
Se genera un informe con observaciones y correcciones a aplicar.
Ventajas:
-
Mejora la calidad de los requerimientos antes de pasar a la fase de diseño.
-
Involucra a todas las partes interesadas.
2. Prototipos
Qué es:
Son representaciones visuales o funcionales del sistema (mockups, wireframes o prototipos navegables).Objetivo:
Permitir al usuario visualizar cómo funcionará el sistema antes de implementarlo.Cómo se realiza:
-
Se crean maquetas en herramientas como Figma, Balsamiq, Adobe XD, etc.
-
Se presentan al cliente para verificar si cumplen con sus expectativas.
-
Se ajustan los requerimientos en base a los comentarios.
Ventajas:
-
Reduce malentendidos.
-
Aumenta la retroalimentación temprana del cliente.
3. Casos de Uso / Escenarios
Qué es:
Son descripciones detalladas de cómo los usuarios interactúan con el sistema en situaciones específicas.Objetivo:
Asegurar que los requerimientos cubran correctamente las necesidades funcionales desde la perspectiva del usuario.Cómo se realiza:
-
Se define un actor (usuario o sistema externo).
-
Se describe una secuencia de pasos para lograr un objetivo (ej: registrar un alumno).
-
Se revisa con el usuario para validar el flujo.
Ventajas:
-
Facilita la comprensión del sistema por parte del cliente.
-
Ayuda a identificar requerimientos faltantes o mal planteados.
4. Pruebas de Validación (Validación por prueba)
Qué es:
Crear casos de prueba basados en los requerimientos para validar que sean claros, completos y verificables.Objetivo:
Asegurar que cada requerimiento pueda probarse en el sistema real.Cómo se realiza:
-
Se redactan casos de prueba para cada requerimiento.
-
Se identifican criterios de aceptación.
-
Se ejecutan las pruebas y se comparan los resultados con lo esperado.
Ventajas:
-
Confirma que los requerimientos se pueden implementar y verificar técnicamente.
-
Detecta requerimientos vagos o ambiguos.
5. Entrevistas y Encuestas
Qué es:
Consiste en preguntar directamente a los interesados (clientes, usuarios, expertos) para validar los requerimientos.Objetivo:
Obtener retroalimentación directa sobre si los requerimientos satisfacen las necesidades del negocio.Cómo se realiza:
-
Se preparan preguntas abiertas o cerradas.
-
Se realizan entrevistas individuales o en grupo.
-
También se pueden aplicar encuestas por formulario.
Ventajas:
-
Aporta perspectiva real del negocio.
-
Permite detectar requerimientos que no se han documentado.
6. Walkthroughs (Recorridos)
Qué es:
Es una revisión informal donde el autor del documento guía a los participantes a través de los requerimientos, paso a paso.Objetivo:
Detectar posibles errores o dudas mientras se repasan los requerimientos en conjunto.Cómo se realiza:
-
El autor presenta el documento y explica el contenido.
-
Los participantes hacen preguntas o comentarios durante el recorrido.
-
Se registran observaciones.
Ventajas:
-
Buena técnica para equipos pequeños o con recursos limitados.
-
Fomenta la colaboración entre analistas y usuarios.
7. Técnicas de Modelado
Qué es:
Consiste en representar los requerimientos mediante diagramas (como UML, BPMN, ERD, etc.).Objetivo:
Visualizar procesos, entidades y relaciones para facilitar la validación.Cómo se realiza:
-
Se crean diagramas como:
-
Diagramas de casos de uso
-
Diagramas de clases
-
Diagramas de flujo
-
Diagramas de actividades o BPMN
-
-
Se presentan a los interesados para validación visual.
Ventajas:
-
Clarifica estructuras y procesos complejos.
-
Facilita la identificación de errores lógicos.
8. Matrices de Trazabilidad
Qué es:
Es una tabla que relaciona los requerimientos con otros artefactos del proyecto (objetivos del negocio, casos de uso, pruebas, módulos de código).Objetivo:
Asegurar que cada requerimiento esté cubierto en el diseño, desarrollo y pruebas.Cómo se realiza:
-
Se listan todos los requerimientos.
-
Se vinculan con sus correspondientes casos de uso, módulos de sistema y pruebas.
-
Se mantiene actualizada durante todo el proyecto.
Ventajas:
-
-
Ayuda a controlar el alcance.
-
Permite verificar que no se omita ningún requerimiento en el desarrollo o pruebas.
Casos de Uso
Proyecto de ejemplo: Sistema de gestión escolar.
Función a validar: Registro de calificaciones por parte del maestro.
Caso de Uso: Registrar Calificaciones
Nombre del caso de uso:
Registrar calificaciones de los alumnos
Actor principal:
Maestro
Actores secundarios:
Sistema (valida datos y guarda en base de datos)
Precondiciones:
-
El maestro debe estar autenticado en el sistema.
-
El alumno ya debe estar inscrito en el curso.
Flujo principal (escenario básico):
-
El maestro accede a la opción "Registrar Calificaciones".
-
El sistema muestra una lista de sus grupos y asignaturas.
-
El maestro selecciona un grupo y una materia.
-
El sistema muestra la lista de alumnos.
-
El maestro ingresa la calificación para cada alumno.
-
El maestro confirma el registro.
-
El sistema valida que los valores estén en el rango permitido (por ejemplo, 0-10).
-
El sistema guarda las calificaciones.
-
El sistema confirma al maestro que los datos fueron guardados correctamente.
Flujos alternativos:
-
Paso 7A: Si una calificación no es válida, el sistema muestra un mensaje de error y no permite guardar hasta que se corrija.
-
Paso 1A: Si el maestro no está autenticado, el sistema lo redirige a la pantalla de inicio de sesión.
Postcondiciones:
-
Las calificaciones quedan registradas en la base de datos del sistema.
-
El sistema está listo para mostrar estas calificaciones a alumnos y padres según permisos.
¿Cómo se usa este caso de uso para validar requerimientos?
-
Con el usuario (maestro): Se revisa el caso de uso en una reunión. Se le pregunta:
"¿Este flujo cubre lo que tú haces en la vida real al calificar alumnos?"
Si el maestro dice que necesita subir archivos Excel, o que califica por parcial y no final, eso indicaría que faltan requerimientos. -
Con el desarrollador: El caso de uso permite verificar si el proceso es implementable con la tecnología disponible.
-
Con QA (pruebas): Se pueden generar casos de prueba desde este caso de uso, por ejemplo:
-
¿Qué pasa si se ingresa un número fuera del rango?
-
¿Qué pasa si se omite una calificación?
-
Resultado de aplicar la técnica:
-
Validación funcional realista.
-
Se identifican omisiones o ambigüedades.
-
Se ajustan los requerimientos antes de programar.
-
Se mejora la comunicación entre usuarios y desarrolladores.
