Requisitos no funcionales
Los requisitos no funcionales son las cualidades que el sistema debe cumplir de forma transversal —rendimiento, accesibilidad, seguridad, disponibilidad— y que casi nunca caben en una historia individual. Su sitio natural no es una tarjeta que se hace una vez, sino una restricción transversal o un criterio de la Definition of Done, verificado en cada incremento.
Un requisito no funcional (a veces llamado atributo de calidad o, en inglés, non-functional requirement) no describe qué hace el producto, sino cómo debe comportarse mientras lo hace. Un backlog real contiene, además de historias, defectos, trabajo técnico, obligaciones normativas y precisamente estas restricciones; forzarlas al molde de historia produce las ficciones del usuario falso.
Por qué no caben en una historia individual
«Como usuario, quiero que la página cargue rápido» no tiene beneficiario distinguible frente a otra historia ni cabe en un sprint: es una restricción del sistema, no una porción de valor que se pueda priorizar contra otra. Meterla como historia produce dos daños. Por un lado, no se puede ordenar por valor, porque afecta a todo. Por otro, se confirma una sola vez, cuando en realidad el rendimiento o la accesibilidad se degradan con cada cambio y hay que verificarlos continuamente.
Dónde va cada uno según su alcance
El criterio es el alcance de la cualidad:
- Cualidad general del sistema (el rendimiento global, la accesibilidad, el cifrado): pertenece a la Definition of Done o a una restricción transversal, y se verifica en cada incremento.
- Umbral específico de una funcionalidad (un tiempo de respuesta propio de esta pantalla): ahí sí es un criterio de aceptación de esa historia concreta.
La misma lógica separa los criterios de aceptación de la Definition of Done: si algo debe cumplirse en todo lo que se entrega, va a la DoD; si es propio de esta necesidad, es un criterio. Cuando el requisito no funcional es una obligación con evidencia exigible (una norma que pide trazabilidad y aprobación), se trata como cumplimiento normativo, con su responsable identificable.
Error frecuente
Meter los requisitos no funcionales como historias. «Como usuario, quiero que la página cargue rápido» no tiene beneficiario distinguible ni cabe en un sprint. Confirmar una restricción una sola vez es igual de peligroso: el rendimiento y la accesibilidad se degradan con cada cambio, así que su sitio es la Definition of Done o una restricción transversal, verificada en cada incremento; solo un umbral propio de una funcionalidad concreta es un criterio de aceptación de esa historia.
Recursos
🏦 Skill User storiesState of the art y guía de desarrollo · Skill Arena
📄 Historias de usuario v.5.0Descarga gratuita · Scrum Manager · ene 2026
📄 Scrum Master en equipos con IA v.1.0Descarga gratuita · Scrum Manager
Referencias
- Cohn, Mike. (2004). User Stories Applied (capítulo sobre requisitos no funcionales). Addison-Wesley.
- Schwaber, Ken; Sutherland, Jeff. (2020). La Guía de Scrum.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.