EGEL Plus Ingeniería de Software 2027: ejercicios de requisitos y pruebas

Requisito verificable y caso de prueba: no son lo mismo

Soy Rodrigo, de PIXOGUÍAS®. En el EGEL Plus de Ingeniería de Software conviene separar tres cosas que se mezclan fácil: el requisito, que dice qué debe hacer el sistema; el diseño, que dice cómo se construye; y el caso de prueba, que comprueba con datos y pasos que el requisito se cumple. Aquí practicas esa distinción con dos ejemplos originales, con clave y descarte, y una lista para saber si una prueba se puede repetir con el mismo resultado.

Dónde aparece este tema en la guía de Ceneval

Esto es lo que dice la guía para el sustentante de diciembre de 2026 sobre el examen y sobre las áreas donde caen los dos ejemplos de esta página.

Método: cuatro preguntas para clasificar un enunciado

1. ¿Dice qué debe hacer o cumplir el sistema, visto desde fuera? Entonces es un requisito. Debe tener una condición, una respuesta observable y, cuando aplica, un límite medible.
2. ¿Dice cómo está construido por dentro? Tablas, colas, servicios, lenguajes o frecuencias de consulta son decisiones de diseño. El requisito no las impone, salvo que el cliente las exija como restricción.
3. ¿Trae datos de partida, pasos y un resultado esperado? Entonces es un caso de prueba: la evidencia de que el requisito se cumple, no el requisito mismo.
4. ¿Dos personas decidirían lo mismo sin discutir? Si el enunciado usa palabras como «rápido», «fácil» o «con oportunidad» sin cifra ni condición, no es verificable.

Dos ejemplos originales: un requisito y la prueba que lo comprueba

Son ejemplos míos, con tres opciones (A, B y C). No son reactivos oficiales ni reproducen los de la guía de Ceneval. En cada caso aplica las cuatro preguntas; después abre la respuesta.

1. Requisito verificable. ¿Cuál de estos enunciados es un requisito verificable? A) Al registrarse la tercera falta consecutiva de un alumno, el sistema enviará un correo al tutor registrado a más tardar 10 minutos después. B) Registrar tres faltas seguidas de un alumno de prueba y comprobar que su tutor recibe el correo a más tardar 10 minutos después de la tercera. C) El módulo de avisos consultará la tabla de asistencia cada minuto y enviará los correos mediante el servicio de mensajería de la escuela.

Ver respuesta

A. Es un requisito: tiene una condición (la tercera falta consecutiva), una respuesta observable (un correo al tutor registrado) y un límite medible (10 minutos), y no dice cómo se construye. La B es un caso de prueba: trae datos de prueba, pasos y un resultado esperado; sirve para comprobar el requisito, pero no lo sustituye. La C es una decisión de diseño: describe el mecanismo interno (consulta cada minuto, servicio de mensajería) y no dice ante qué condición debe avisarse ni en qué plazo; ese mismo requisito podría cumplirse con otro diseño.

2. Caso de prueba reproducible. ¿Qué caso de prueba verifica ese requisito y puede repetirse con el mismo resultado? A) Estado inicial: cualquier alumno con faltas previas y tutor con correo de prueba. Acción: registrar una falta a las 10:00:00, hora del servidor. Resultado esperado: el aviso llega al correo del tutor a más tardar a las 10:10:00. B) Estado inicial: alumno con 2 faltas consecutivas y tutor con correo de prueba. Acción: registrar la tercera falta cuando el servidor esté disponible. Resultado esperado: el aviso llega al correo del tutor en un plazo razonable. C) Estado inicial: alumno con 2 faltas consecutivas y tutor con correo de prueba. Acción: registrar la tercera falta a las 10:00:00, hora del servidor. Resultado esperado: el aviso llega al correo del tutor a más tardar a las 10:10:00.

Ver respuesta

C. Fija el estado inicial (dos faltas consecutivas), la acción exacta (la tercera falta, a una hora tomada del reloj del servidor) y un resultado esperado medible (a más tardar 10 minutos después, es decir, a las 10:10:00), que es justo lo que promete el requisito. Quien la repita en esas condiciones llegará al mismo veredicto. La A deja sin controlar el estado inicial: «cualquier alumno con faltas previas» puede tener cero, una o cinco faltas, así que a veces el aviso debe llegar y a veces no, y dos personas podrían obtener resultados distintos con la misma prueba. La B sí fija el estado, pero «cuando el servidor esté disponible» y «un plazo razonable» no se pueden medir: la prueba nunca podría fallar por tardanza y no verifica el límite de 10 minutos.

Cómo comprobar que una prueba es reproducible

Antes de dar por buena una prueba, revísala con estas cuatro preguntas. No necesitas ninguna herramienta; basta con leerla como si fueras otra persona.

• Estado inicial: ¿está escrito con datos concretos (cuántas faltas, qué tutor, qué versión del sistema)? «Cualquier alumno» no lo es.
• Acción exacta: ¿quien la ejecute sabrá qué hacer sin preguntar? Si importa el tiempo, define una sola referencia de reloj, como la hora del servidor.
• Resultado esperado medible: una cifra, un estado o un mensaje que se pueda comparar. Evita «razonable», «rápido» o «correcto».
• Misma entrada, mismo veredicto: ejecútala dos veces, o pide que otra persona la ejecute, sobre el mismo estado inicial. Si el veredicto cambia, falta controlar algo: los datos previos, la hora, la versión o el orden de ejecución.

Errores frecuentes al escribir requisitos y pruebas

Son fallos comunes al trabajar estos contenidos; no es una lista oficial ni anticipa lo que aparecerá en tu examen. Compara cada error con la forma correcta y con su regla.

Cómo practicar requisitos y pruebas

• Reescribe enunciados vagos: toma una función de una aplicación que uses (el banco, la escuela, una tienda) y escríbela con condición, respuesta y límite medible.
• Clasifica antes de elegir: ante un enunciado, decide primero si es requisito, diseño o prueba; casi siempre eso descarta una o dos opciones.
• Escribe la prueba de cada requisito: con estado inicial, acción y resultado esperado; luego léela como si fueras otra persona.
• Revisa la bibliografía de la guía: para el Área 1, la guía sugiere, entre otras, obras de Sommerville (2016) y de Pressman y Maxim (2020) (p. 16).

Preguntas frecuentes

¿El examen me pide redactar requisitos o pruebas? No. Según la guía de diciembre de 2026, la mayor parte del examen son reactivos de opción múltiple con tres opciones de respuesta (p. 38). Por eso aquí se practica reconocer y descartar, aunque en el trabajo real sí tendrás que redactar ambos.

¿En qué parte de la guía caen los requisitos? En el Área 1, Análisis de Sistemas de Software (subáreas 1.1 a 1.3). La calidad de software es la subárea 4.2, y el descriptor del Área 3 menciona la documentación de pruebas del sistema.

¿Cuántos reactivos tiene el EGEL Plus de Ingeniería de Software? Según la guía, 203: 143 de la sección disciplinar (cuatro áreas y catorce subáreas) y 60 de Lenguaje y Comunicación. La guía aclara además que el examen incluye 15 % de reactivos piloto, que no se consideran para la calificación.

¿Qué puedo llevar al examen? La guía permite calculadora científica no programable y no permite prestarla entre sustentantes (p. 47). Si dudas de algo más, confírmalo con tu institución.

¿Estos ejemplos son del examen real? No. Son originales de PIXOGUÍAS® y no reproducen los ejemplos de la guía de Ceneval; no anticipan reactivos ni resultados.

Sigue leyendo

• Cuántas preguntas tiene el EGEL Plus por carrera (2027)
• Qué puedes llevar al EGEL Plus por carrera: materiales permitidos 2027
• Cuánto tiempo tienes por reactivo en el EGEL Plus (tabla por carrera)

Última actualización del contenido: noviembre de 2026. Ceneval puede actualizar su guía; confirma la vigente en el portal de Ceneval.

PIXOGUÍAS® es una editorial independiente y no está afiliada a Ceneval. Este artículo resume información pública y trae ejemplos originales; no es un documento oficial. Los ejemplos no son reactivos del examen ni anticipan un resultado.