¿Cuál es la diferencia entre requisitos funcionales y no funcionales, y por qué importan tanto los no funcionales?

Los requisitos funcionales dicen qué hace el sistema; los no funcionales dicen cómo de bien tiene que hacerlo. Rendimiento, disponibilidad, seguridad, accesibilidad y retención de datos son los típicos. Importan porque son arquitectónicos: no puedes añadir tarde un objetivo de tiempo de respuesta o una traza de auditoría de siete años sin rehacer trabajo. Consigue números pronto, porque aceptable no es un requisito comprobable.

Funcional es qué hace, no funcional es cómo de bien tiene que hacerlo. En la práctica, el segundo grupo es el que me mete en problemas si soy perezoso con él, porque moldean la arquitectura. Si un informe tiene que volver en menos de dos segundos, o el sistema tiene que guardar una traza de auditoría durante siete años, o tiene que funcionar con un lector de pantalla, esas decisiones se toman en las primeras semanas o cuestan una fortuna más tarde. Así que persigo números en vez de adjetivos. Rápido no es un requisito; percentil noventa y cinco por debajo de dos segundos con mil usuarios concurrentes sí lo es. Normalmente tengo que ir a buscar esos números yo mismo, porque cuando le pregunto a un stakeholder de negocio cómo de rápido tiene que ser, la respuesta es rápido, y cuando pregunto qué hace el sistema actual, nadie lo sabe. Así que mido el que ya existe y uso eso para arrancar una conversación de verdad.