Requisitos, criterios de aceptación y trazabilidad
Los requisitos vistos con ojos de gestor: qué los hace verificables, por qué los no funcionales mandan sobre la arquitectura y el coste, y cómo la trazabilidad te dice qué se rompe cuando algo cambia.
- Clasificar un requisito como funcional o no funcional, y un RNF como de producto, de la organización o externo.
- Convertir un requisito vago ("rápido", "seguro") en uno verificable con criterios de aceptación.
- Leer y construir una matriz de trazabilidad y usarla para analizar el impacto de un cambio.
Ya viste requisitos en Ingeniería de Requisitos, así que las definiciones van en una línea. Lo nuevo es el enfoque de gestión: por qué un requisito no verificable es un riesgo de proyecto, por qué los RNF disparan el coste y cómo la trazabilidad controla el alcance. Diapositivas: Tema 1, 26-36.
1. Qué es un requisito (y qué le exige el gestor)
Los requisitos describen necesidades, capacidades o condiciones que debe satisfacer el sistema. Deben ser comprensibles, verificables y trazables. Sus relaciones son tan cruciales como los propios requisitos, y la trazabilidad es esencial.Tema 1, diap. 26.
Para el gestor, cada una de esas tres propiedades tiene una consecuencia concreta:
- Comprensible → si cliente y equipo lo entienden distinto, habrá conflicto en la aceptación.
- Verificable → si no se puede comprobar, nunca sabrás si está terminado; el proyecto no puede cerrarse limpiamente.
- Trazable → si no sabes de dónde viene ni qué lo implementa, no puedes calcular el impacto de cambiarlo.
Ampliación: la norma ISO/IEC/IEEE 29148 añade que un buen requisito es necesario, no ambiguo, completo, singular (una sola cosa), factible, consistente, verificable y trazable.
2. Funcionales frente a no funcionales
| Funcional (RF) | No funcional (RNF) | |
|---|---|---|
| Describe | Capacidades: ¿qué hace? | Cualidades y restricciones: ¿cómo hace lo que hace? |
| Ejemplo | "Registrar pagos" | "Procesar el 95 % de los pagos en < 2 s" |
| TusBus | "Mostrar el tiempo estimado de llegada de cada línea en una parada" | "La estimación tendrá un error medio < 60 s" · "Disponible el 99,5 % del tiempo en horario de servicio" |
Tema 1, diap. 27.
Algunos requisitos mezclan ambos tipos, por ejemplo los de seguridad ("el sistema permitirá iniciar sesión con doble factor" es una función; "resistirá ataques de fuerza bruta" es una cualidad). Para facilitar su tratamiento, en la asignatura se consideran RNF.
Por qué al gestor le importan más los RNF
Las diapositivas dicen tres cosas que son pura gestión:Tema 1, diap. 27 y 30.
- Los RNF son los que más influyen en la complejidad del proyecto. "Mostrar el tiempo de llegada" puede hacerse en una semana. "Con error < 60 s, para 50.000 usuarios simultáneos, el 99,5 % del tiempo" puede costar meses: caché, colas, réplicas, monitorización.
- Son más difíciles de verificar. Comprobar una función es pulsar un botón; comprobar rendimiento o seguridad exige pruebas de carga, auditorías, pentesting.
- Pueden ser más críticos que los funcionales: si no se cumplen, invalidan el sistema, y su cumplimiento tiene gran influencia en la arquitectura. Una app que da tiempos con 5 min de error tiene todas las funciones y es inútil.
Conclusión de gestión: los RNF hay que identificarlos pronto (antes de elegir arquitectura y de estimar) y cuantificarlos. Un RNF descubierto tarde es el ejemplo perfecto del "coste del error creciente" de la lección 1.
Requisitos de usuario y de sistema
Los RF de usuario pueden ser declaraciones de alto nivel ("el usuario podrá consultar cuándo llega su bus"); los RF de sistema deben describir los servicios con detalle ("dada una parada, el sistema calculará para cada línea…").Tema 1, diap. 28. Base: Sommerville, Software Engineering, cap. 4. Los de usuario sirven para negociar con el cliente; los de sistema, para construir y probar.
3. Clasificación de los RNF
Por objeto (de dónde vienen)
| Tipo | Origen | Ejemplos |
|---|---|---|
| Del producto | Especifican el comportamiento del producto | Velocidad de ejecución, tasa aceptable de fallos, "la comunicación usará UTF-16BE", consumo de batería |
| De la organización | Consecuencia de políticas y procedimientos de la propia organización (cliente o desarrolladora) | Estándares de proceso ("conforme con ISO-XXXX"), métodos de diseño, lenguaje de programación obligado, tipo de documentación, herramienta CASE |
| Externos | Factores externos al producto y a su proceso | Legales (RGPD/LOPDGDD, accesibilidad), éticos, de interoperabilidad con otros sistemas, normativa del sector |
Tema 1, diap. 30-32.
Truco para clasificar: pregunta quién lo impone. ¿Lo impone lo que el producto debe hacer bien? Producto. ¿Una norma interna de una empresa? Organización. ¿Alguien de fuera (el legislador, la sociedad)? Externo. "El sistema no revelará datos personales de clientes a usuarios de nivel 3 o inferior" es externo porque nace de la ley de protección de datos, aunque se implemente en el producto.
Por tipo (jerarquía de Sommerville)
La diapositiva 33 muestra el árbol clásico de Sommerville:Tema 1, diap. 33 (figura). Sommerville, 10ª ed., fig. 4.3.
- Producto: usabilidad · eficiencia (rendimiento, espacio) · confiabilidad (dependability) · seguridad (security).
- Organización: de entorno · operacionales · de desarrollo.
- Externos: regulatorios · éticos · legislativos (contables, de seguridad física/safety).
Esta clasificación conecta con el modelo de calidad ISO/IEC 25010, que verás en la lección 15: los RNF de producto son, en el fondo, las características de calidad que se exigen.
4. Requisitos verificables: los criterios de aceptación
Hay que evitar requisitos vagos: "rápido", "seguro", "fácil de usar". Un requisito tiene que ser una condición verificable, y para eso necesita criterios de aceptación. Y la idea más profunda de esta diapositiva: los criterios de aceptación definen realmente el requisito, porque definen cuándo se considera satisfecho.Tema 1, diap. 34.
Piénsalo así: dos personas pueden leer "la app será fácil de usar" e imaginar cosas opuestas. Pero si el criterio es "un usuario nuevo encuentra su parada y consulta el tiempo en menos de 30 s sin ayuda, en 8 de cada 10 pruebas", ya no hay discusión posible. El criterio es el requisito.
| Vago | Verificable |
|---|---|
| "La app será rápida" | "La pantalla de parada muestra los tiempos en < 2 s en el 95 % de las consultas con 4G" |
| "El sistema será seguro" | "Las contraseñas se almacenan con un hash adaptativo (bcrypt/argon2); se bloquea la cuenta tras 5 intentos fallidos en 10 min; sin vulnerabilidades críticas en el análisis SAST antes de cada versión" |
| "Fácil de usar" | "8 de 10 usuarios nuevos consultan su parada en < 30 s sin ayuda" |
| "Preciso" | "Error medio absoluto de la estimación < 60 s, medido sobre una semana de datos reales" |
El formato Dado–Cuando–Entonces
En entornos ágiles los criterios se escriben a menudo en formato Given–When–Then (de BDD, Behaviour-Driven Development):Ampliación. Formato popularizado por Dan North (BDD); se usa con historias de usuario (Tema 3).
Las diapositivas añaden: TDD aplica las pruebas como criterios de aceptación. En Test-Driven Development escribes primero la prueba que debe pasar y luego el código; la prueba automatizada es la definición ejecutable del requisito. El criterio de aceptación pasa de ser texto a ser código que se comprueba solo.
Los criterios de aceptación son lo que el cliente firmará en el cierre ("verificar la aceptación de entregables", lección 11). Si no existen, el cierre se convierte en una negociación sin fin. Y son la base de la estimación: no puedes estimar "rápido", pero sí "< 2 s con 50.000 usuarios".
5. Trazabilidad
La trazabilidad permite seguir la relación entre elementos del proyecto a lo largo de toda la cadena:Tema 1, diap. 35.
Sirve para dos cosas: detectar requisitos sin cobertura y analizar el impacto de los cambios. Se recorre en dos sentidos:
- Hacia delante (requisito → diseño → código → prueba): ¿cada requisito está implementado y probado? Detecta lo que falta.
- Hacia atrás (prueba/código → requisito → objetivo): ¿cada pieza de código existe por algún requisito? Detecta lo que sobra (gold plating, lección 3) y requisitos sin origen.
La matriz de trazabilidad
Ejemplo de la diapositiva: OBJ-02 → REQ-07 → MOD-03 → TEST-21. Las preguntas que la matriz responde son:Tema 1, diap. 36.
- ¿Todos los requisitos tienen origen? (trazabilidad hacia atrás)
- ¿Todos los requisitos tienen pruebas que los verifican? (hacia delante)
- ¿Qué pruebas se ven afectadas por un cambio? (análisis de impacto)
Una matriz de TusBus:
| Objetivo | Requisito | Módulo | Prueba |
|---|---|---|---|
| OBJ-01 Informar del tiempo real de llegada | REQ-03 Mostrar tiempo por línea y parada | MOD-02 Cálculo ETA | TEST-10, TEST-11 |
| OBJ-01 | REQ-04 Error medio < 60 s (RNF) | MOD-02 Cálculo ETA · MOD-05 Ingesta GPS | TEST-30 (precisión con datos reales) |
| OBJ-02 20 % de uso semanal | REQ-07 Paradas favoritas | MOD-03 Perfil de usuario | TEST-21 |
| OBJ-03 Cumplir el RGPD | REQ-12 No guardar la ubicación sin consentimiento | MOD-03 · MOD-06 Consentimientos | — ninguna — |
| — ninguno — | REQ-15 Compartir en redes sociales | MOD-08 Social | TEST-40 |
Léela como un gestor:
- REQ-12 no tiene prueba: un requisito legal sin verificar. Es un riesgo de cumplimiento grave (lección 17). Acción: crear la prueba antes de la próxima versión.
- REQ-15 no tiene objetivo: ¿por qué existe? O falta un objetivo, o es gold plating. Acción: preguntar al cliente y, si no aporta a ningún objetivo, sacarlo del alcance.
- Si el cliente pide cambiar el algoritmo de cálculo (MOD-02), la matriz te dice sin pensar que afecta a REQ-03 y REQ-04 y que hay que repetir TEST-10, 11 y 30. Eso es el análisis de impacto, y es la base para decir cuánto cuesta el cambio.
- "La trazabilidad es documentación burocrática que sólo sirve en proyectos predictivos": falso. En ágil se mantiene ligera (historia → criterios → tests automatizados → commit), pero existe. Y en proyectos regulados (salud, banca, IA de alto riesgo) es obligatoria como evidencia de cumplimiento.
- La matriz de trazabilidad es una herramienta de gestión del alcance (en el PMBOK 6 es una salida de "Recopilar requisitos"), aunque se use mucho en calidad.
- Un requisito sin criterio de aceptación no es verificable aunque esté muy bien redactado.
Los requisitos deben ser verificables y trazables: los criterios de aceptación dicen cuándo están cumplidos, y la trazabilidad dice qué falta, qué sobra y qué se rompe si cambian.Idea clave del Tema 1, diap. 71.
Práctica
Clasifica cada requisito de TusBus.
- El usuario podrá guardar paradas como favoritas
- La pantalla de parada cargará en menos de 2 segundos
- El código se escribirá en Kotlin según la guía de estilo de la empresa
- No se almacenará la ubicación sin el consentimiento del usuario
- El administrador podrá publicar avisos de incidencias en una línea
- La app cumplirá el nivel AA de accesibilidad exigido por ley
Según el temario, ¿qué afirmaciones sobre los requisitos no funcionales son correctas?
- Suelen influir más en la complejidad del proyecto que los funcionales
- Son siempre menos críticos que los funcionales porque son secundarios
- Si no se cumplen pueden invalidar el sistema por completo
- Tienen gran influencia en las decisiones de arquitectura
- Son más fáciles de verificar porque se pueden medir con números
¿Por qué dice el temario que los criterios de aceptación "definen realmente el requisito"?
- Porque sustituyen al requisito, que ya no hace falta escribir
- Porque los escribe el cliente y por eso tienen más autoridad
- Porque definen cuándo se considera satisfecho el requisito
- Porque son obligatorios en todos los contratos de software
¿Cuál de estos requisitos es verificable?
- El sistema responderá de forma rápida y fluida en cualquier situación
- El sistema será seguro frente a todos los ataques conocidos y futuros
- El sistema será intuitivo y agradable para todo tipo de usuarios
- El sistema atenderá 500 peticiones por segundo con latencia p95 < 300 ms
Empareja cada pregunta de la matriz de trazabilidad con lo que detecta.
- ¿Todos los requisitos tienen un objetivo de origen?
- ¿Todos los requisitos tienen pruebas que los verifican?
- ¿Qué pruebas y módulos se ven afectados si cambia REQ-07?
En la matriz de TusBus, el requisito "Compartir en redes sociales" no está vinculado a ningún objetivo. ¿Qué debería hacer el JP?
- Mantenerlo, porque ya está implementado y probado y no cuesta nada
- Preguntar qué objetivo cubre y, si ninguno, plantear sacarlo del alcance
- Añadir un objetivo nuevo al charter para que la matriz quede completa
- Eliminarlo del código sin decir nada para no generar ningún conflicto
Reescribe como requisito verificable, con al menos un criterio de aceptación, este requisito de una app de banca: "El acceso será seguro".
¿Por qué, desde el punto de vista de la gestión, conviene identificar y cuantificar los RNF antes de estimar el proyecto?
Repaso espaciado · lecciones 1-3
"Suponemos que el cliente revisará cada entrega en menos de 3 días." ¿Qué es y qué hay que hacer con ello?
- Una restricción: hay que planificar respetándola como límite fijo
- Un supuesto: hay que verificarlo pronto porque es un riesgo latente
- Un objetivo SMART: hay que medirlo en cada una de las entregas
- Un requisito funcional: hay que añadirlo a la matriz de trazabilidad
¿Cuáles son estándares de gestión de proyectos?
- PRINCE2
- ISO/IEC 25010
- PMBOK Guide
- Métrica 3
- ISO 21500
Para profundizar
Sommerville, Software Engineering, 10ª ed., cap. 4 "Requirements Engineering" (en la biblioteca de la UMA; web del libro con material adicional). Es la base directa de las diapositivas 26-33. Para criterios de aceptación y trazabilidad con enfoque de gestión: Wiegers y Beatty, Software Requirements, 3ª ed., cap. 17 y 29 (citado en las referencias del Tema 1).
Pega un requisito de tu práctica en un asistente (Claude en el móvil) y pídele que lo critique: ¿es verificable?, ¿de qué tipo es?, ¿qué criterio de aceptación le falta? Es el mejor entrenamiento para esta lección.
Resumen imprimible: Referencia · Fundamentos.